Third-party data access authorization based on attribute-based encryption keys

Abstract

A mechanism for computing resource access security is provided that authenticates user agent credentials to determine whether the user agent is associated with an entity for which an attribute-based encryption (ABE) key is generated. If so, an ABE key corresponding to a set of attributes of the entity is generated and provided. Token issuance logic receives a token request and the ABE key from a relying party computing device and performs a decryption operation on lock metadata associated with at least one attribute value based on the ABE key. In response to the decryption operation successfully decrypting the lock metadata, the token issuance logic issues a generated token to the relying party computing device based on the at least one attribute value. The relying party computing device uses the generated token to access the computing resource.

Description

[Background technology]

[0001] The present application relates generally to improved data processing apparatus and methods, and more particularly to improved computing tools and improved computing tool operations / functionality for providing third-party data access authorization based on attribute-based cryptographic keys.

[0002] Protocols have been developed that allow data owners to grant third parties access to their data for various purposes. For example, Open Authorization 2 (OAuth2) is a protocol that allows users to authorize and control access to data they own on a site to third-party sites for multiple data processing use cases. For example, these use cases range from users printing digital photos stored on a site, such as in the cloud, to running analytics on data stored in a data lake. OpenID Connect (OIDC) is an identity layer that works on top of OAuth2. With OIDC, an additional token, also known as an ID token, is added that identifies the user authorizing access to the data.

[0003] Although OIDC and OAuth2 provide protocols for controlling access to data, these tools still leave the server vulnerable to attack if the authentication server for these protocols is successfully compromised. That is, if compromised by an attacker, the attacker may have access to authentication tokens and authentication server authentication protocols that may grant them access to protected computing resources. This poses a significant computer security problem. Summary of the Invention

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described herein in the Detailed Description. This Summary is not intended to identify key elements or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] In one exemplary embodiment, a method for computing resource access security in a data processing system is provided. The method includes authentication and authorization logic of the data processing system authenticating credentials of a user agent to determine whether the user agent is associated with an entity for which an attribute-based encryption (ABE) key is to be generated. The method further includes, in response to the authentication and authorization logic determining that the user agent is associated with the entity for which an ABE key is to be generated, generating an ABE key and providing the ABE key to the user agent, wherein the ABE key corresponds to a set of attributes of the entity. The method also includes token issuance logic of the data processing system receiving a token request and the ABE key from a relying party computing device, and the token issuance logic performing a decryption operation on lock metadata associated with at least one attribute value based on the ABE key. The method also includes, in response to the decryption operation successfully decrypting the lock metadata, the token issuance logic issuing a generated token to the relying party computing device based on the at least one attribute value. The relying party computing device uses the generated token to access the computing resource. Thus, with this methodology, rather than requiring an authorization code mapping, the ABE key mechanism enables determination of attribute values ​​to be included in an issued token without requiring an explicit mapping between authorization code mappings and attributes maintained by a provider.

[0006] In some exemplary embodiments, the method further includes provisioning attributes and corresponding candidate attribute values ​​as attribute-value pairs to the token issuance logic. Each candidate attribute value of each attribute-value pair is associated with corresponding lock metadata. Thus, in these exemplary embodiments, lock metadata is associated with each candidate attribute value, and if the associated lock metadata for that candidate attribute value can be decoded, that candidate attribute value can be used to generate an issued token.

[0007] In some exemplary embodiments, provisioning the token issuance logic with attributes and corresponding candidate attribute values ​​includes storing, in an attribute-value data structure, a plurality of attribute names; for each attribute name in the plurality of attribute names, storing, in the attribute-value data structure, a list of candidate attribute values ​​for the attribute name; and, for each candidate attribute value in each list of candidate attribute values ​​for each attribute name, storing, in the attribute-value data structure, the corresponding lock metadata encrypted such that only the ABE key of an authorized user agent corresponding to the candidate attribute value can decrypt the corresponding lock metadata. Thus, using these exemplary embodiments, the lock metadata and ABE key mechanism enables uniquely determining which attribute values ​​to include in an issued token based on whether the ABE key can decrypt the lock metadata associated with an attribute-value pair.

[0008] In some exemplary embodiments, the lock metadata is an arbitrary byte sequence that is encrypted such that a valid ABE key can decrypt the lock metadata. In these exemplary embodiments, the lock metadata content is not important to the locking function, since the lock metadata can be successfully decrypted regardless of the specific content of the lock metadata. Thus, the lock metadata can be any arbitrary byte sequence.

[0009] In some exemplary embodiments, the lock metadata is an attribute-value pair corresponding to the lock metadata that has been encrypted so that a valid ABE key can decrypt the lock metadata. In these exemplary embodiments, the attribute-value pair is further obfuscated by encryption and use of the attribute-value pair as the lock metadata. Thus, while other exemplary embodiments may have attribute-value pairs in the clear with the associated lock metadata, in these exemplary embodiments, the attribute-value pairs are also encrypted, providing greater security.

[0010] In some exemplary embodiments, the method further includes provisioning the authentication and authorization logic with multiple master ABE keys, where the ABE keys are generated based on corresponding master ABE keys in the multiple master ABE keys. In some exemplary embodiments, each master ABE key is associated with a different computing resource owner, and an ABE key generated based on a first master ABE key associated with a first provider of computing resources cannot decrypt lock metadata corresponding to an ABE key generated based on a second master ABE key associated with a second computing resource owner. In these exemplary embodiments, different owners of computing resources may maintain their own master ABE keys for issuing ABE keys, so that they may have separate security policies and ensure that their computing resources cannot be accessed using ABE keys issued based on other resource owners' master ABE keys.

[0011] In some exemplary embodiments, the ABE key is a ciphertext, and each lock metadata associated with each attribute value in the at least one attribute value includes a corresponding second ABE key. In some exemplary embodiments, performing the decryption operation includes attempting to decrypt the ABE key ciphertext using each lock metadata associated with each attribute value in the at least one attribute value. In some exemplary embodiments, issuing the generated token includes generating the generated token by incorporating one or more attribute values ​​of the at least one attribute value into the generated token in response to the corresponding second ABE key for the one or more attribute values ​​successfully decrypting the ciphertext. Thus, in these exemplary embodiments, rather than attempting to decrypt the lock metadata based on the issued ABE key, the ciphertext may be provided to a relying party, and the ABE key for the lock metadata may be used to attempt to decrypt the ciphertext.

[0012] In some exemplary embodiments, issuing the generated token includes generating the token by including the at least one attribute value in the token in response to the decryption operation being successful. In some exemplary embodiments, the token is one of an access token or an ID token. The access token or ID token can be used with other OAuth2 / OIDC-based mechanisms to gain access to protected computing resources. In some exemplary embodiments, the token is a JavaScript Object Notation Web Token (JWT), and the at least one attribute value includes at least one claim of the JWT. Thus, in these exemplary embodiments, the security of the token issuance mechanism is improved while still being usable with OAuth2 / OIDC-based mechanisms and JWTs.

[0013] In some exemplary embodiments, the authentication and authorization logic is a first microservice executing on a first computing device of the data processing system, and the token issuance logic is a second microservice executing on either the first computing device or a second computing device different from the first computing device. Thus, in these exemplary embodiments, a microservices architecture facilitates distribution of authentication and authorization logic and token issuance logic functionality across different computing devices, thereby enhancing the security of the system against compromise.

[0014] In some exemplary embodiments, the method includes provisioning the token issuance logic with candidate attribute-value pairs containing attributes and attribute values ​​for inclusion in a token, and provisioning the authentication and authorization logic with a master ABE key for generating an ABE key. In some exemplary embodiments, issuing the generated token to the relying party computing device based on the at least one attribute value includes generating the token to include the at least one attribute value from a subset of the candidate attribute-value pairs, and the ABE key is generated based on the master ABE key. Thus, not all candidate attribute-value pairs are used in each token, and the token issuance logic may be pre-configured with attribute-value pairs in which selected attribute values ​​are used to generate tokens.

[0015] In another exemplary embodiment, a computer program product is provided that includes a computer usable or computer readable medium having a computer readable program that, when executed on a computing device, causes the computing device to perform various ones and combinations of the operations outlined above with respect to the exemplary embodiment of the method.

[0016] In yet another exemplary embodiment, a system / apparatus is provided that may include one or more processors and a memory coupled to the one or more processors. The memory may have instructions that, when executed by the one or more processors, cause the one or more processors to perform various and combinations of the operations outlined above with respect to the exemplary embodiment of the method.

[0017] These and other features and advantages of the present invention will be described or will become apparent to those skilled in the art in view of the following detailed description of exemplary embodiments of the invention. [Brief explanation of the drawings]

[0018] The invention, together with its preferred mode of use, further objects and advantages, will be best understood by reference to the following detailed description of illustrative embodiments when read in conjunction with the accompanying drawings.

[0019] [Figure 1] FIG. 1 illustrates an exemplary distributed data processing system environment in which aspects of the exemplary embodiments may be implemented and in which at least a portion of the computer code involved in performing the methodology of the present invention may be executed.

[0020] [Figure 2] FIG. 1 is an exemplary data flow diagram illustrating the operation of an OAuth2 / OIDC architecture.

[0021] [Figure 3] FIG. 2 is an exemplary data flow diagram illustrating the operation of a distributed authentication system according to one exemplary embodiment.

[0022] [Figure 4] FIG. 2 is an exemplary diagram illustrating an attribute name / key pair attribute value list data structure with corresponding lock metadata according to one exemplary embodiment.

[0023] [Figure 5]1 is a flowchart outlining the operation of an authentication and authorization microservice, according to one example embodiment.

[0024] [Figure 6] 1 is a flowchart outlining the operation of a token issuing microservice in accordance with one example embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0025] As noted above, protocols such as OAuth2 and OIDC have been developed that allow entities to control third-party access to their digital content and other computing resources, acting as both an authentication token-issuing entity and an authentication system. However, if an authentication server is successfully compromised by an attacker, the authentication tokens and authentication protocols may be compromised, allowing unwanted parties to gain access to protected computing resources, resulting in serious computer security issues. It would be beneficial to hide the policies, rules, attributes, etc. used to generate the authorization codes and authentication tokens required to gain access to protected computing resources.

[0026] Exemplary embodiments provide improved computing tools and improved computing tool functionality / operations that implement attribute-based encryption key authorization of third-party access to computer resources, such as applications, data structures, or the like. Attribute-based encryption (ABE), originally called Fuzzy Identity-Based Encryption, is a public-key-based authentication scheme that enables fine-grained access control to encrypted data using security authorization policies in which a user's private key and ciphertext depend on attributes, such as email address, country of residence, and the type of subscription or account the user has. Decryption of a ciphertext in ABE is only possible if the set of attributes in the user key matches the attributes of the ciphertext. Therefore, only users who satisfy a specific access protocol can access the decrypted plaintext of the ciphertext. ABE allows for one-to-many encryption types, i.e., multiple private or secret keys can be generated based on the same public key.

[0027] For example, suppose someone wants to generate a confidential document to be shared with members of a work group within a company. Under identity-based encryption, that person would need to create multiple encrypted versions of the document for each potential recipient. However, using ABE, the document can be encrypted with a public key generated based on a set of attribute values ​​and a key issuance policy implemented by a key generator can be specified so that anyone with a specific set of attribute values ​​can be provided with a secret or private key to decrypt the encrypted confidential document. For example, suppose the attributes are location, department, and work group, and the policy specifies that only individuals with attribute values ​​where location is "United States," department is "Cloud Computing Solutions," and work group is "XYZ Platform" can access the confidential document. The confidential document is encrypted using these specific attribute values ​​to generate a public-key-encrypted confidential document. When a user wants to access the encrypted document, the user requests a key from the key generator and presents their credentials, including the user's location, department, and work group. The key generator implements one or more security policies defined for the encrypted document and determines whether to issue a decryption key to the user. If the attribute values ​​of the user's credentials match the conditions of the security policy, the user is presented with a decryption key that the user can use to decrypt the encrypted sensitive document.

[0028] In an exemplary embodiment, ABE is implemented to provide an ABE key as part of a mechanism for authorization that replaces opaque authorization codes in computer resource access flows. The ABE key is used to decrypt metadata associated with attributes that will be placed in tokens used to authenticate parties as part of computer resource access operations, such as in the case of Internet web applications. The ABE key mechanism embeds one or more authorization policies into the ABE key itself by virtue of the entity (or party) having the ABE key; i.e., the ABE key is issued only to entities (parties) that meet the requirements of a security policy defined in a key generator, which requires the entity (or party) to have one or more specific attribute values ​​defined in the one or more policies. In an exemplary embodiment, the attribute values ​​that will be included in an authentication token for use in authenticating a user may themselves be encrypted with the encrypted metadata, so that the ABE key can be used to decrypt the attribute values. Because of the ABE mechanism, if a party can decrypt the metadata associated with an attribute value, the fact that the metadata was successfully decrypted indicates that the corresponding attribute value will be included in the authentication token. Thus, by using ABE keys and mechanisms to determine which attribute values ​​to include in an access token rather than using opaque authorization codes, the provider does not need to maintain and map attribute values ​​to authorization codes. Instead, the work of determining which attribute values ​​to include in an authentication token can be offloaded to a microservice according to an example embodiment.

[0029] For example, the authentication token may be a JavaScript Object Notation (JSON) Web Token or the like, where JSON is a language-independent, open-standard file and data interchange format that uses human-readable text to store and transmit data objects composed of attribute-value pairs and arrays or other serializable values. For purposes of the following description, we will assume that the computer resources accessed are data structures, although this is not intended to be limiting and the mechanisms of the exemplary embodiments may be used to control access to any computer resources suitable for a particular implementation, such as an application or the like.

[0030] Using JSON Web Token (JWT) as an example, the attribute associated with the metadata can be any attribute defined in the JWT, such as a claim or a scope. The claims of a JWT are use-case specific but generally specify characteristics of the entity requesting access to a computing resource, such as the issuing party's identity, a validity period, and what permissions the entity is granted, where the entity can be a user, application, or organization, or any other entity that may request access to a computing resource and whose identity and authorization can be authenticated through a cryptographic security mechanism. A JWT's scope is a grouping of claims. JWTs are an open standard used to share security information between parties, such as a server and a client, where the claims of a JWT cannot be altered because the JWT is cryptographically signed. While JSON and JWT are used herein as examples, it should be understood that other electronic data interchange (EDI) standards using other types of tokens for sharing security information between parties can be used with the exemplary embodiments without departing from the spirit and scope of the present invention. Other formats of tokens may be used, including, for example, comma-separated string format, Extensible Markup Language (XML) format, etc.

[0031] The ABE key-based authentication mechanism of the exemplary embodiments provides a secure microservices environment where the policies and rules used to create tokens / authorization codes are embedded in the ABE key mechanism and do not necessarily need to be shared through any other flows. Microservices are a cloud-native architectural approach in which a single application is composed of many loosely coupled, independently deployable, smaller components or services. These services have their own technology stacks, including databases and data management models, communicate with each other through a combination of application programming interfaces (APIs), event streaming, and message brokers, and are organized by business function; the lines separating the services are often referred to as bounded contexts.

[0032] According to one or more example embodiments, the authentication mechanism is separated into an authentication microservice and a token issuance microservice. These two microservices are provisioned with data for token issuance, but they do not necessarily need to be connected to the same database to securely issue tokens. The two microservices are provisioned with data and rules for issuing access tokens (intended to be read by a computing resource server to identify permissions granted to a protected computing resource) and ID tokens (intended to be read by an OIDC client and used to identify the resource owner). In a first provisioning operation, the token issuance microservice is provisioned with attributes and attribute values ​​to include in the access token and ID token. The attributes and attribute values ​​may be stored as attribute-value pair metadata, where the attributes may be JWT attributes and the values ​​may be any suitable values ​​for their corresponding attributes, such as subscriber=admin, applicationname=app1, version=1.0.0, tier=top, etc.

[0033] An attribute-value pair may have associated metadata, which may be any small encrypted data structure that will be used to test whether a provided ABE key contains one or more attribute values ​​that allow the presenter of the ABE key to obtain an access token and ID token. This metadata may be, for example, any arbitrary byte sequence, since the content of the metadata is unrelated to the “locking” function it serves as part of the ABE key mechanism. That is, to the extent that the metadata can be decrypted using the ABE key, the fact that the decryption itself was successful is an indication that the corresponding attribute value should be included in the corresponding issued access token or ID token. In some cases, the encrypted metadata may not be an arbitrary byte sequence, but rather the attribute value itself, or the attribute-value pair itself. For the purposes of this description, this encrypted metadata used to lock an attribute value or attribute-value pair is referred to herein as “locking metadata.”

[0034] The contents of the lock metadata are discarded after an attempt to decrypt the lock metadata has been made. It is used only as an access control method for adding attribute-value pairs to tokens, e.g., JWTs. In some example embodiments, an attribute name may point to a list of values ​​with accompanying lock metadata, which is a test used for which attribute value or whether the attribute should contain multiple values. That is, an ABE key can be used to decrypt one or more lock metadata in the list of values, and the corresponding values ​​associated with the decrypted lock metadata may be included in the issued token.

[0035] In a second provisioning operation, a master ABE key is provisioned to the authentication and authorization microservice (AAM). The master ABE key is provisioned to the AAM so that the AAM can generate ABE keys (see step 7 in Figure 3). Multiple AAMs may exist and operate with the token issuance microservice, and each instance of an AAM is associated with a corresponding resource owner or the resource owner's user agent. Each resource owner may protect the master ABE key on their AAM according to their own security policy. Each resource owner may issue ABE keys that can be consumed by a single token issuance microservice that supports all resource owners. Each resource owner's token issuance security policy or rules, as well as the resource owner's attribute-value pairs, may still be protected with appropriate encryption, where these data can only be unlocked using the lock metadata and the ABE key from the resource owner that owns the master ABE key. Since ABE keys are generated using different master ABE keys, an ABE key issued by a resource owner cannot decrypt lock metadata of other resource owners.

[0036] In some exemplary embodiments, the ABE key sent by the relying party may be replaced with a ciphertext. In these exemplary embodiments, the lock metadata itself may be replaced with an ABE key. Thus, in these exemplary embodiments, the test becomes an attempt to decrypt the ciphertext using each ABE key associated with each of the attribute values, although the general mechanics described above are similar.

[0037] As mentioned above, in some exemplary embodiments, the token issuing microservice is provisioned with a list of encrypted lock metadata, where in some cases the encrypted lock metadata may include an encrypted key-value pair for the access token. If the encrypted lock metadata can be decrypted using the ABE key presented by the relying party, the key-value pair is added to the access token, e.g., JWT. Thus, unlike exemplary embodiments in which the encrypted lock metadata is an arbitrary byte string, the encrypted lock metadata in these exemplary embodiments is an encrypted version of the key-value pair (attribute name / value). This approach has the advantage of hiding both the attribute key (name) and its value from an attacker who may compromise the authentication server. The access token (e.g., JWT) attributes can be anything from claims, scopes, or any other data that an implementer desires to include in an access token, e.g., JWT, without departing from the spirit and scope of the present invention.

[0038] In OAuth2 and OIDC, opaque authorization codes, which require each provider to maintain a mapping of authorization codes, provide proof of authentication and are exchanged by OIDC clients for actual authentication tokens, which contain any cryptographically signed claims asserted about identity. Opaque authorization codes are essentially meaningless and do not contain any metadata within them. Arbitrary rules / policies are mapped to token-issuing services.

[0039] The mechanism of the exemplary embodiment replaces authorization codes in data access flows with an ABE key / ciphertext mechanism. The exemplary embodiment has the following advantages: First, the mechanism of the exemplary embodiment improves the ability to move token issuance functionality to a computing service separate from the authentication and authorization service, reducing the load on user authentication mechanisms and facilitating migration of monolithic authentication server applications to a microservices architecture for scalability and security. Second, the mechanism of the exemplary embodiment allows enterprise rules and attributes, such as identity or group membership, to be anonymized and hidden in the ABE key that is used in place of the authentication code.

[0040] Third, the mechanism of the exemplary embodiment allows parties to hide enterprise rules from the token issuing computing service itself, enhancing the security of the authentication system in the event that the token issuing computing microservice is compromised. With ABE keys, the token issuing service does not need to know the rules / policies at all. Thus, if the token issuing service is compromised, the mechanism of the exemplary embodiment ensures that those rules / policies remain hidden. When the token issuing computing microservice makes a decision about which JWT claims (e.g., attributes / values) to add to the token, the token issuing computing microservice simply attempts to decrypt the lock metadata associated with the JWT claims (attribute values) instead of requiring a complex database query to find the JWT attributes for the presenter, as is the case with authorization codes used by an authentication server, e.g., an OAuth2 / OIDC authentication server.

[0041] Thus, exemplary embodiments provide improved computing tools and improved computing tool functionality / operations that provide ABE keys (or ciphertext in some exemplary embodiments described below) instead of opaque authorization codes. ABE keys have embedded rules / policies in which attributes associated with the ABE keys are specified as part of a well-defined set of cryptographic functions that provide a high level of security while enabling a clear separation of token issuance and authentication services. That is, ABE keys are issued to authorized entity user agents based on those attributes. Lock metadata is encrypted using a set of rules / security policies that specify criteria for the entity's attributes, such that an ABE key for an entity that possesses those attributes can be used to decrypt the corresponding lock metadata. For example, assume the set of attributes is {A, B, C, D}, and a first entity receives an ABE key corresponding to attributes {A, B}. Also assume a second entity receives an ABE key corresponding to attributes {C, D}. If the lock metadata is encrypted with a security policy of "(A and C) or D," the ABE key of the second entity will be able to decrypt the lock metadata, but the ABE key of the first entity will not be able to decrypt the lock metadata. Thus, the ABE key mechanism implicitly implements security policies without the need to have an explicit mapping of authentication codes. Furthermore, by associating lock metadata with specific candidate attribute-value pairs, the corresponding attribute-value pairs whose lock metadata is decrypted by the ABE key can be automatically integrated into issued tokens.

[0042] While the exemplary embodiments are described with reference to JWT and OAuth2 / OIDC as examples, it should be understood that the exemplary embodiments are not limited to such. Rather, the mechanisms of the exemplary embodiments may be implemented using any token issuance protocol and any suitable type of token and corresponding token attributes and attribute values, represented in any suitable manner for implementation; for example, the present invention is not limited to attribute-value pair data structures. The exemplary embodiments are provided as examples, and those skilled in the art will recognize that many modifications to these examples can be made in light of this specification without departing from the spirit and scope of the present invention.

[0043] Before continuing with the discussion of exemplary embodiments and various aspects of the improved computer operations performed thereby, it should first be understood that the term "mechanism" is used throughout this description to refer to elements of the present invention that perform various operations, functions, and the like. A "mechanism," as the term is used herein, may be an implementation of a function or aspect of an exemplary embodiment in the form of an apparatus, a procedure, or a computer program product. In the case of a procedure, the procedure is implemented by one or more devices, apparatuses, computers, data processing systems, or the like. In the case of a computer program product, the logic represented by computer code or instructions embodied in or on the computer program product is executed by one or more hardware devices to implement the functionality associated with, or perform the operations associated with, a particular "mechanism." Thus, the mechanisms described herein may be implemented as specialized hardware, software that executes on the hardware and thereby configures the hardware to implement specific functionality of the invention that the hardware cannot otherwise perform, software instructions stored on a medium such that the instructions are readily executable by the hardware and thereby specifically configure the hardware to perform the functions recited and specific computer operations described herein, procedures or methods for performing functions, or any combination of the above.

[0044] The present specification and claims may utilize the terms "one," "at least one of," and "one or more of" in reference to particular features and elements of exemplary embodiments. It should be understood that these terms and phrases are intended to state that there is at least one of a particular feature or element present in a particular exemplary embodiment, but that more than one may also be present. That is, these terms / phrases are not intended to limit the present specification or claims to the presence of a single feature / element or to require the presence of a plurality of such features / elements. To the contrary, these terms / phrases require only at least a single feature / element, and a plurality of such features / elements may be present within the scope of the present specification and claims.

[0045] Furthermore, the use of the term “engine,” when used herein in connection with describing embodiments and features of the present invention, is not intended to limit any particular technical implementation for realizing and / or performing the actions, steps, processes, etc. resulting from and / or performed by the engine, but it should be understood that “engine” is limited in that it is implemented in computer technology and its actions, steps, processes, etc. are not performed as mental processes or performed manually, even if the engine may operate in conjunction with manual input or provide output intended for manual or mental consumption. An engine is implemented as one or more of software running on hardware, dedicated hardware, and / or firmware, or any combination thereof, specifically configured to perform specified functions. Hardware may include, but is not limited to, the use of a processor in combination with appropriate software that is loaded or stored in machine-readable memory and executed by the processor, thereby specifically configuring the processor for a specific purpose, including one or more of the functions of one or more embodiments of the present invention. Furthermore, any name associated with a particular engine, unless otherwise specified, is for convenience of reference and is not intended to limit a particular implementation. Additionally, any functionality attributed to one engine may be equally performed by multiple engines, incorporated and / or combined with the functionality of another engine of the same or different type, or distributed across one or more engines in various configurations.

[0046] Additionally, it should be understood that the following description uses multiple different examples of various elements of the exemplary embodiments to further explain exemplary implementations of the exemplary embodiments and to aid in understanding the mechanisms of the exemplary embodiments. These examples are intended to be non-limiting and do not exhaust the various possibilities for implementing the mechanisms of the exemplary embodiments. In light of this specification, it will be apparent to those skilled in the art that there are many other alternative implementations of these various elements that could be utilized in addition to or in place of the examples provided herein without departing from the spirit and scope of the present invention.

[0047] Various aspects of the present disclosure are illustrated by text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, depending again on the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0048] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media"), collectively contained in one or more storage devices, that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as a punch card or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals communicated through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device temporary because the data is not temporary while it is stored.

[0049] It is to be understood that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination.

[0050] Exemplary embodiments provide improved computing tools and improved computing tool functionality / operations specifically directed to solving problems arising in the computer field, particularly the above-identified problems associated with attackers compromising monolithic authentication server architectures and gaining access to protected computing resources. Exemplary embodiments provide a specific solution to these problems in the form of an attribute-based encryption (ABE) key system for token issuance and authentication of entities that enables separation of authentication services and token issuance services, as well as obfuscation of security policies and attributes used in those security policies. Exemplary embodiments may be implemented as part of a computer security system that protects computing resources, and may be implemented in a distributed data processing system for controlling access by multiple entities to a set of protected computing resources over one or more data networks. Thus, an exemplary distributed data processing system, e.g., a cloud computing environment, in which aspects of the exemplary embodiments are implemented in one or more computing devices of the distributed data processing system will be described first, followed by a description of specific improved computing tool components and functionality.

[0051] The present invention may be a specifically configured computing system, which itself is comprised of hardware and / or software specifically configured to implement particular mechanisms and functions described herein, a method implemented by a specifically configured computing system, and / or a computer program product including software logic that is loaded into a computing system to specifically configure the computing system to implement the mechanisms and functions described herein. Whether recited as a system, method, or computer program product, it should be understood that the exemplary embodiments described herein are particularly directed to improved computing tools and methodologies implemented by the improved computing tools.

[0052] In particular, the improved computing tool of the exemplary embodiment provides an authentication server computing tool, which may specifically be a distributed authentication server computing tool, in which attribute-based encryption (ABE) replaces authentication codes in a manner that obfuscates security policies and attributes used to authenticate users to access computing resources, distributing functionality to prevent attacks on the system from accessing protected computing resources. The improved computing tool implements mechanisms and functions such as an authentication server in which authentication and authorization logic (which may include, but is not limited to, a microservice implementation) is separated from token issuance logic (which may also be, but is not required to be, a microservice implementation). These mechanisms provide specific computer logic that cannot actually be executed by a human, either outside of or with the assistance of a technical environment, such as a mental process or the like. The improved computing tool provides a practical application of the present methodology, at least in that the improved computing tool encodes rules / policies related to authentication within an ABE key that obfuscates the rules / policies from the token issuance computing function. Additionally, the improved computing tool provides a practical application of the methodology, at least in that the improved computing tool separates authentication and authorization computer functions from token-issuing computer functions, thereby enabling a distributed authentication server rather than using a monolithic authentication server that is susceptible to compromise. Additionally, the improved computing tool provides a practical application and does so by using attribute-based cryptography to obfuscate policies and attributes used to authenticate third parties accessing protected computing resources.

[0053] FIG. 1 is an exemplary diagram of a distributed data processing system environment in which aspects of exemplary embodiments may be implemented and in which at least a portion of the computer code involved in performing the methods of the present invention may be executed. That is, computing environment 100 includes an example environment for the execution of at least a portion of the computer code involved in performing the methods of the present invention, such as a distributed authentication system 150 having microservices, e.g., an authentication and authorization microservice 152 and a token issuance microservice 154. While FIG. 1 depicts these microservices 152, 154 as being provided on the same computing device 101, it should be understood that these microservices may be distributed across different physical and / or virtual machines having different hardware / software resources so that a compromise of one microservice does not affect the other microservices. In some exemplary embodiments, components of distributed authentication system 150 may be distributed across other remote computing devices, such as a remote server 104 or another computing device, which may be accessible via one or more data networks 102 (as represented by dashed lines). For example, authentication and authorization microservice 152 may be provided on computer 101, which may be, for example, a server computing device, while token issuance microservice 154 may be provided on remote server 104 or another server computing device coupled to WAN 102. The operation of distributed authentication system 150 is described in further detail below with respect to Figures 3-5.

[0054] It should be understood that distributing these services across physical / virtual machines is an optional element of the exemplary embodiments. Because any mapping between authentication and token issuance mechanisms is embedded in the ABE key mechanism, combined code and token issuance services can still benefit from the improved computing capabilities of providing ABE keys as described herein. When these services are distributed, an additional benefit is that rules / policies do not need to be shared across AAMs and token issuance services. Thus, if the authentication server and token issuance service would otherwise need some way to record how authorization codes are mapped to claims that will be inserted into tokens, the exemplary embodiments provide a clear and secure way to solve that problem with ABE keys / ciphertexts, distributed or not.

[0055] In addition to block 150, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a set of processors 110 (including processing circuitry 120 and cache 121), a communications fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 150, as identified above), a set of peripheral devices 114 (including a user interface (UI), a set of devices 123, storage 124, and a set of Internet of Things (IoT) sensors 125), and a network module 115. Remote server 104 includes a remote database 130. Public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0056] Generally, computer 101 may take the form of a server computer, a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 130. That is, various types of computing devices that communicate over one or more data networks may be provided in distributed computing environment 100. For purposes of describing exemplary embodiments, computer 101 is assumed to be a server computing system that provides a distributed authentication system 150 having authentication and authorization microservice 152 and token issuance microservice 154 (again, a microservice architecture is not required, but is used herein as an example). As a server computing system, computer 101 need not implement all of the illustrated elements, but these elements are provided herein to illustrate components of computing systems in which aspects of exemplary embodiments may be implemented in some exemplary embodiments. The server computer 101 provides a distributed authentication system 150 for performing authentication and authorization computer functions and token issuance functions between end user devices and various other services available through one or more data networks, e.g., the cloud, such as providing end user-to-service and service-to-service authorization functions.

[0057] As is well understood in the field of computer technology, and depending on the technology, performance of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this presentation of computing environment 100, in order to keep the presentation as concise as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown in the cloud in FIG. 1, it may be located in the cloud. However, computer 101 is not required to reside in the cloud except to any extent that may be expressly indicated.

[0058] Processor set 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple tailored integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all caches for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0059] Computer-readable program instructions are typically loaded onto computer 101 and cause processor set 110 of computer 101 to execute a series of operational steps, thereby enabling a computer-implemented method, such that the instructions so executed instantiate the methods specified in the computer-implemented method flowcharts and / or descriptions contained herein (collectively referred to as the "methods of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the methods of the present invention. In computing environment 100, at least some of the instructions for executing the methods of the present invention may be stored in block 150 in persistent storage 113.

[0060] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as switches and conductive pathways that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0061] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory is characterized by random access, although this is not required unless expressly indicated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0062] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or to persistent storage 113 directly. Persistent storage 113 can be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be erased, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, including various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that employ a kernel. The code contained in block 150 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0063] The peripheral device set 114 includes a set of peripheral devices of the computer 101. Data communication connections between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cable (such as a Universal Serial Bus (USB)-type cable), insertion-type connections (e.g., a Secure Digital (SD) card), connections made through a local area communication network, and even connections made through a wide area network such as the Internet. In various embodiments, the UI device set 123 can include components such as a display screen, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. The storage 124 can be external storage such as an external hard drive or insertable storage such as an SD card. The storage 124 can be persistent and / or volatile. In some embodiments, the storage 124 can take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., where computer 101 stores and manages a large database locally), this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple, geographically distributed computers. IoT sensor set 125 is made up of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0064] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101 from an external computer or external storage device, typically through a network adapter card or network interface included in network module 115.

[0065] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances using any technology for communicating computer data now known or later developed. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0066] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise that operates computer 101) and may take any of the forms described above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to the end user, the recommendations would typically be communicated from network module 115 of computer 101 over WAN 102 to EUD 103. In this manner, EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, and the like.

[0067] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on past data, then this past data may be provided to computer 101 from remote database 130 of remote server 104.

[0068] A public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of public cloud 105 computing resources is performed by computer hardware and / or software in cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented by virtual computing environments running on various computers comprising host physical machine set 142, which is the universe of physical computers within and / or available in public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 143 and / or containers from container set 144. It is understood that these VCEs can be stored as images and can be transferred among and between various physical machine hosts, either as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCE, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0069] Some further discussion of virtualized computing environments (VCEs) is now provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0070] A private cloud 106 is similar to a public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0071] As described below, the distributed authentication system 150 provides an authentication and authorization microservice 152 and a token issuance microservice 154. These mechanisms operate using attribute-based encryption (ABE) and ABE keys instead of opaque authorization codes. This allows the authentication and authorization service to implement security policies embedded in ABE keys by the ABE mechanism. The authentication and authorization service can determine whether to generate and issue ABE keys to any requesting entity, assumed to be a user below, but which may be an application or a specific device based on established security policies. The ABE keys are used to decrypt lock metadata associated with attribute values ​​to determine which attribute values ​​to include in an access token / ID token. The ABE keys are submitted to the token issuance microservice along with a token request to obtain access tokens and ID tokens with attribute values ​​corresponding to the attribute values ​​for which the lock metadata can be decoded. Access to protected computing resources can then be requested using the access tokens and ID tokens.

[0072] Such message exchanges to perform this ABE-based authentication and authorization involve multiple different parties, including a requesting entity (e.g., a user), a relying party (e.g., an application delegating authentication services to an authentication server), an authentication system, and a protected computing resource provider (e.g., a resource server or the like). These entities may be associated with different computing devices that communicate with each other via data communication channels over one or more data networks, such as WAN 102. Thus, for example, a user agent (e.g., a user's computing device, an application running on the user's computing device, or the like) may be provided as part of end-user device 103, a relying party may be provided as part of remote server 104 or other server computing device (not shown, but indicated by dashed lines), distributed authentication system 150 may be part of computer 101 or may be distributed across multiple computing devices, and a protected computing resource provider may be provided as part of remote server 104 or other server computing device, providing computing resources such as hardware / software computing resources or data structures, e.g., database 130.

[0073] As shown in FIG. 1 , one or more of the computing devices, e.g., computer 101 and / or remote server 104, may be specifically configured to implement a distributed authentication system 150, which may be distributed, having separate authentication and authorization microservice 152 and token issuance microservice 154. Configuring the computing devices may include providing special-purpose hardware, firmware, or the like to facilitate performing the operations and generating output described herein with respect to the exemplary embodiments. Configuring the computing devices may also, or alternatively, include providing software applications stored in one or more storage devices and loaded into memory of a computing device, such as computing device 101 or remote server 104, to cause one or more hardware processors of the computing device to execute the software applications that configure the processors to perform the operations and generate output described herein with respect to the exemplary embodiments. Furthermore, any combination of special-purpose hardware, firmware, software applications running on hardware, or the like, may be used without departing from the spirit and scope of the exemplary embodiments.

[0074] It should be understood that once a computing device is configured in one of these ways, the computing device becomes a specialized computing device specifically configured to implement the mechanisms of the exemplary embodiments, and not a general-purpose computing device. Furthermore, as described below, implementation of the mechanisms of the exemplary embodiments provides useful and tangible results that enhance the functionality of computing devices and facilitate attribute-based encryption (ABE) key-based token issuance for authentication of third-party entities accessing protected computing resources that support the distribution of authentication and token issuance microservices and obfuscation of security policies and attributes used to authenticate third-party entities.

[0075] The data flows implemented and orchestrated by distributed authentication system 150 are now described, thereby illustrating the improved computer functionality of the improved computing tool. To better understand this improved computer functionality, it is beneficial to first understand the data flows of an OAuth2 / OIDC monolithic authentication server-based architecture so that the differences between this OAuth2 / OIDC architecture and the architecture of the exemplary embodiment can be seen.

[0076] 2 is an exemplary data flow diagram illustrating the operation of the OAuth2 / OIDC architecture. The architecture includes four major parties: a user agent 210, a relying party 220, an authentication server 230, and a resource server 240. The user agent 210, sometimes referred to as a resource owner, may be an application user or an end user who owns a protected computing resource. For example, if the protected computing resource is a data structure, the data structure stores the resource owner's personal data, such as a user profile or the like. The resource owner can grant or deny access to the protected computing resource it owns; for example, an application can call an application programming interface (API) of an external system to obtain a user's personal information from the user profile. The profile data is a protected computing resource owned by the resource owner on the external system, and the resource owner can grant or deny an application's request to access its user profile.

[0077] Relying party 220, which may also be referred to as a client, is an application that requests access to protected computing resources on resource server 240. For example, a client may be a web application running on a server, an application running on a web browser on a client computing device, a web API that invokes another web API, or the like. Resource server 240 provides access to the resource owner's protected computing resources, e.g., a protected data structure. Resource server 240 may be, for example, a web API or application that provides an interface for access to a data store, e.g., a database, or the like. Resource server 240 controls access to these protected computing resources by performing authentication of the request with authorization server 230 and providing security tokens to grant / deny access to the protected computing resources.

[0078] Authorization server 230 is a computing platform that securely handles protected computing resources for resource owners (user agents 210). Authorization server 230 is responsible for issuing security tokens that applications and APIs use to grant, deny, or revoke access to resources after resource owners are authenticated and signed in. Security tokens issued by authorization server 230 include access tokens and ID tokens (collectively referred to as bearer tokens). Access tokens are issued by the authorization server to relying parties 220, which use these tokens with resource server 240 to access protected computing resources. Access tokens contain the permissions granted to relying party 220 by authorization server 230. ID tokens are issued by authorization server 230 to relying parties 220, which use these ID tokens when signing in users to obtain information about those users, e.g., user agent 210.

[0079] When registering with authentication server 230, user agent 210 is provided with a unique identifier, such as an application ID or client ID, that identifies user agent 210 to authentication server 230. Additionally, authorization server 230 uses a redirect Uniform Resource Identifier (URI) to direct user agent 210 to resource server 240 to complete access to the protected computing resource.

[0080] 2, operation begins with a user agent 210, e.g., an application running on a computing device, such as a user's application, web browser, mobile application, etc., sending a user login request (step 1) to a relying party 220. Because data flows between computing devices, it should be understood that references in this description to a "single party" or "multiple parties" are intended to refer to the computing devices used by those parties. Relying party 220 responds with an authentication redirect to user agent 210 (step 2), and user agent 210 then submits a user login request to authentication server 230 based on the authentication redirect, which redirects user agent 210 to authentication server 230 (step 3).

[0081] Authentication server 230 sends a user credential challenge to user agent 210 (step 4), which then responds with the user credential (step 5). Based on the user credential, authentication server 230 determines whether to issue an authorization code to user agent 210. This determination may be based on a set of stored rules and a determination of whether the credentials submitted by user agent 210 satisfy those rules. When an authorization code is generated (step 7) and issued by authentication server 230, authentication server 230 stores the authorization code as part of a mapping between the authorization code and attributes of user agent 210 that may be provided by a user when registering with authentication server 230. For example, attributes may be username, phone number, email, address, or any other data that may be asserted about an identity. Authentication server 230 needs to be able to map the authorization code it previously issued back to an identity upon successful authentication if the relying party exchanges the authorization code for a token. Thus, the authorization code is mapped to a set of attributes that represent the identity. Authorization codes are typically used only once to prevent replay attacks.

[0082] Thus, authentication server 230 stores this mapping, so that if authentication server 230 is compromised by an attacker, the attacker can access this mapping and impersonate the identity of an authorized third-party entity, such as user agent 210, to gain access to protected computing resources. The authentication code is referred to herein as "opaque" because it is intended specifically for use by authentication server 230 and requires authentication server 230 to maintain a mapping between the authentication code and attributes of user agent 210 (or the user) so that it can subsequently authenticate the authentication code and provide access tokens and ID tokens for accessing protected computing resources. The authentication code is also "opaque" in that the structure of the token is determined per provider.

[0083] If authentication server 230 successfully authenticates user agent 210 based on the user credentials, it sends a request for resource access authorization to user agent 210 (step 6). Assuming authentication server 230 successfully authenticates the user credentials, authentication server 230 generates and stores an authorization code in mapping with user agent 210 (or user) attributes (step 7) and sends a redirect to user agent 210 redirecting user agent 210 to relying party 220 and providing the generated authorization code (step 8).

[0084] User agent 210 then sends the authorization code to relying party 220 based on the redirection URI (step 9). Relying party 220 sends the request token with the authorization code to authentication server 230 (step 10), which authenticates the authorization code based on its stored mapping data structure and returns an access token and an ID token (step 11). Relying party 220 then sends an access request, along with the access token and the ID token, to resource server 240 (step 12). Resource server 240 then returns the requested resource to the relying party (step 13), and the relying party may then perform its operation against the protected computing resource provided to relying party 220.

[0085] That is, resource server 240 accepts the access token as a valid credential for accessing protected resources. In OIDC, which adds identity to OAuth2, an ID token asserts claims about an individual. To access protected resources on third-party resource server 240, only an access token is required. The ID token is intended to be processed by relying party 220 so that it can identify on whose behalf it is requesting resources. A real-world example of why this is necessary is when a first application wants to analyze a user's messages in another, second application. When a user logs into the first application, the first application delegates authentication to the second application, and the second application may indicate that the first application is requesting to retrieve the user's messages and request authorization for this access. Both the access token and the ID token from the second application are then returned to the first application. The first application uses the ID token to present a personalized look and feel (and possibly show a profile page for the user) and the access token to the second application's resource server to retrieve the user's messages.

[0086] 2, authentication server 230 provides a monolithic authentication / authorization and token issuance server. Thus, if this server is compromised, an attacker can gain access to the authorization codes, tokens, permissions, security rules, etc. that are utilized to access protected computing resources. Thus, if an attacker can compromise the authentication server, they can gain access to protected computing resources.

[0087] Figure 3 is an exemplary data flow diagram illustrating the operation of a distributed authentication system according to one exemplary embodiment. Figure 3 has similar parties and data flows as Figure 2, which are indicated by similar reference numbers and descriptive text labels. However, among other things, authentication server 230 is replaced by distributed authentication system 310, in which authentication and authorization functions and token issuance functions are distributed to authentication and authorization microservice (AAM) 312 and token issuance microservice 314, which may be implemented on different computing hardware and software on the same or different computing devices. Microservices 312 and 314 are distributed so that a compromise of one does not result in a compromise of the other; for example, these microservices do not share security policies or rules, and attributes used by such policies and rules are not accessible from encrypted objects and ABE keys. While Figure 3 depicts a microservices architecture and a distributed architecture, again, exemplary embodiments are not limited to such, and other architectures implementing the ABE key mechanism of the exemplary embodiments may be used without departing from the spirit and scope of the present invention.

[0088] In addition to the distributed authentication system 310, the data flow shown in Figure 3 replaces the authorization code mechanism used in step 7 and thereafter with attribute-based encryption keys and corresponding operations that operate based on ABE keys, to be discussed below. Thus, steps 1-6 of Figure 3 are performed in a similar manner to the OAuth2 / OIDC architecture-based data flow of Figure 2. Furthermore, steps 12-13 for accessing protected computing resources on resource server 240 are similar to steps 12-13 of Figure 2.

[0089] As shown in FIG. 3 , after step 6, in step 7, the authentication and authorization microservice (AAM) 312 applies security policies and determines whether to issue an ABE key to the user agent 210. These security policies operate based on the user credentials provided by the user agent in step 5, causing the AAM 312 to generate an ABE key corresponding to a particular set of attribute values ​​of the entity associated with the user credentials. That is, for example, if the set of attributes includes {A, B, C, D} and the user credentials are associated with a user with attributes {A, B}, a corresponding ABE key for the user with attributes {A, B} is generated for the request. For example, if a user has attributes Department=Accounting (A) and Project=Audit Project XYZ (B), ABE Key 1 is generated based on these attributes and a master ABE key. Thus, multiple users, e.g., users who are part of the Accounting department and Audit Project XYZ, can use the same ABE Key 1 if they have the same set of attribute values.

[0090] AAM 312 implements ABE to provide ABE keys that replace opaque authorization codes such as those used in step 7 of FIG. 2, such that AAM 312 does not need to maintain a mapping between authorization codes and attributes of user agent 210 or a user. Instead, this mapping is embedded in the ABE mechanism, which issues ABE keys based on attributes of an entity. The ABE keys are used to decrypt lock metadata encrypted according to predefined security rules / policies, where the lock metadata is associated with attributes that will be placed in access tokens and / or ID tokens used to authenticate a party, such as user agent 210. The ABE keys themselves embed one or more authorization policies, with the entity (or party) having the ABE key decrypting the corresponding lock metadata. That is, ABE keys are issued to authorized entities (parties) based on their credentials and are associated with a specific set of attribute values ​​corresponding to those credentials. Only ABE keys can decrypt lock metadata that has been encrypted using predefined security rules / policies that specify attribute criteria for an entity / party. That is, if an ABE key is used to decrypt lock metadata and the ABE key corresponds to an entity that has attributes that meet the criteria of the security rules / policies that correspond to the lock metadata, the ABE key will be able to decrypt the lock metadata and the corresponding attribute-values ​​will be included in the issued token.

[0091] The attributes used to generate the ABE key for each user can be different, and each user is given different access to the attribute-value pairs that can be added to tokens, such as access and / or ID tokens. This is the responsibility of the AAM 312 and is assigned as described above in step 7. One attribute might be that a user belongs to department X, and only attribute-value pairs for department X need to be allowed. Similarly, another user belongs to department Y, and only attribute-value pairs for that department can be added to the token. Another user, for some reason, belongs to both departments X and Y, and attribute-value pairs for both departments can be added in the token. By giving users different attributes during ABE key generation, it is possible to give users different sets of attribute-value pairs for their tokens. This allows implementers to make various combinations as they see fit and does not require a one-to-one mapping between ABE keys and the rules / policies they satisfy. In a microservices architecture, this allows the AAM microservice 312 to be the only service with knowledge of enterprise rules / policies.

[0092] The AAM 312 is provisioned, either manually or through an automated process, by the owner of the AAM 312 with a master ABE key for each computing resource owner that is used to generate ABE keys for individual user agents 210 requesting access to the computing resource owner's protected computing resources. It should be understood that each AAM 312 may be individually provisioned by their respective owner with a corresponding master key. The ABE key generated by the AAM 312 is provided to the user agent 210 along with a redirect to the relying party 220. The user agent 210 submits an access request to the relying party 220 using the redirect URI along with the ABE key. The relying party 220 sends a token request along with the ABE key to the token issuance microservice 314. The ABE key is used in the token issuance microservice 314 to determine which attribute values ​​to include in the access token and / or ID token issued to the relying party 220 for use by the relying party 220 in authenticating the user agent 210 to the resource server 240.

[0093] That is, lock metadata may be associated with each attribute value for each attribute (sometimes referred to as an attribute name or attribute key), such as an attribute-value pair. This lock metadata is encrypted data, e.g., an arbitrary byte sequence or the attribute-value pair itself. The lock metadata may be encrypted according to a security rule / policy that specifies that a specific ABE key corresponding to a particular attribute value pattern can decrypt the lock metadata, e.g., "(A and B) or C," where A, B, and C are attribute values. Only requests with an ABE key corresponding to the particular pattern of attribute values ​​can successfully decrypt the lock metadata, i.e., gain access to the plaintext of the ciphertext.

[0094] Thus, the ABE key is used to decrypt the lock metadata. If an attribute-value pair's associated lock metadata can be successfully decrypted using the ABE key, that attribute-value pair can be included in the access token and / or ID token that the token issuance microservice 314 generates and sends back to the relying party 220. In some example embodiments, the attribute-value pairs can themselves be encrypted, and the encrypted attribute-value pairs can be considered lock metadata.

[0095] An access / ID token, also referred to as an authentication token, can be generated with content that includes attribute-value pairs whose lock metadata can be successfully decrypted using an ABE key. Thus, the token issuance microservice 314 does not need to maintain a mapping of authorization codes with attributes; instead, through the ABE mechanism itself, it can identify which attribute-value pairs to include in the authentication token based on which attribute-value pairs' lock metadata was decrypted. Thus, neither the AAM 312 nor the token issuance microservice 314 maintains a mapping of attributes and authentication codes. Instead, the AAM 312 implements ABE security rules to determine whether to issue an ABE key, and separately, the token issuance microservice 314 uses the ABE key to decrypt the lock metadata associated with the attribute-value pairs and determine which attributes to include in the issued token. Thus, even if an attacker is able to compromise one of the microservices 312, 314 of the distributed authentication system 310, the attacker cannot gain access to any mapping between credentials and ABE keys, ABE keys and attribute values, or ultimately to protected computing resources. Thus, by using ABE keys and mechanisms to determine which attribute values ​​to include in authentication tokens, such as access tokens and ID tokens, rather than using opaque authorization codes that require providers to maintain a mapping, providers do not need to maintain attribute values ​​and map attribute values ​​to authorization codes. Instead, the work of determining which attribute values ​​to include in authentication tokens can be offloaded to the token issuance microservice 314, which does so automatically based on the ABE keys and what lock metadata can be decrypted.

[0096] The ABE key-based authentication mechanism, e.g., AAM 312 and token issuance microservice 314 in an exemplary embodiment, can separate a monolithic authentication server, such as 230 in FIG. 2, into separate microservices 312 and 314, making it much more difficult for an attacker to compromise authentication mechanisms provided by other microservices. AAM 312 is provisioned with a master ABE key for issuing ABE keys to requesters based on credential authentication according to predefined security policies or rules. Again, token issuance microservice 314 is provisioned by the owner of token issuance microservice 314, either manually or through an automated process, with data and logic for issuing authentication tokens, e.g., access tokens and ID tokens, having attribute-value pairs determined based on ABE key-based decryption of lock metadata.

[0097] In a first provisioning operation, the token issuance microservice 314 is provisioned with attributes for inclusion in access tokens and ID tokens. The attributes may be stored as attribute-value pairs that may be associated with lock metadata, where the attributes may be JWT attributes and the values ​​may be any suitable values ​​for their corresponding attributes. The lock metadata may be this encrypted data structure or any small encrypted data structure that embeds rules / policies within the ciphertext. The ability to decrypt the lock metadata proves that the ABE key contains one or more attribute values ​​that satisfy the rules / policies for adding attribute values ​​to the obtained access tokens and ID tokens. The content of the metadata may be considered independent of the “lock” function it serves as part of the ABE key mechanism in some example embodiments, and therefore this metadata may be, for example, any arbitrary byte sequence. That is, to the extent that the lock metadata can be decrypted using the ABE key, the fact that the decryption itself was successful is an indication that the corresponding attribute values ​​should be included in the corresponding issued authentication token, e.g., access token and / or ID token.

[0098] In some cases, the encrypted lock metadata may not be an arbitrary string of bytes, as described above, but rather the attribute value or attribute-value pair itself. The contents of the lock metadata are discarded after an attempt to decrypt the lock metadata by the token issuance microservice 314 and are used only as access control to add key-value pairs to the authentication token issued by the token issuance microservice and returned to the relying party 220 as part of step 11. In this case, the attribute-value pairs encrypted in the ABE key are the attributes added to the token.

[0099] In a second provisioning operation, AAM 312 is provisioned with a master ABE key. The master ABE key is provisioned to AAM 312 so that AAM 312 can generate ABE keys (see step 7 in FIG. 3). As mentioned above, although only one AAM 312 is shown in FIG. 3, there can be more than one AAM 312. Each AAM 312 can be associated with a different corresponding resource owner or resource owner's user agent and can operate with a token issuance microservice 314, or there can be a different pair of AAM 312 and token issuance microservice 314 for each resource owner. Each resource owner can protect the master ABE key maintained in the corresponding AAM 312 according to their own security policy. Each resource owner can issue an ABE key through AAM 312, which is then used with the corresponding token issuance microservice 314 to issue the appropriate authentication token, e.g., an access token and / or an ID token whose lock metadata has content corresponding to an attribute-value pair that can be decrypted using the ABE key. Each resource owner's token issuance security policy or rules, as well as the resource owner's attribute-value pairs, can still be protected with appropriate encryption, where these data can only be unlocked with an ABE key from the resource owner who owns the lock metadata and master ABE key. Because the ABE keys are generated by a different master ABE key and possibly a different AAM 312, an ABE key issued by one resource owner cannot decrypt another resource owner's lock metadata.

[0100] Assuming that in step 5 the user agent provided authenticated credentials and the corresponding AAM 312 generated an ABE key based on the master ABE key for the resource owner (step 7), the ABE key is returned to the user agent 210 along with a redirect to the relying party, e.g., a redirect URI (step 8). The user agent 210 sends the ABE key to the relying party 220 using the redirect URI (step 9), and the relying party 220 then sends a request for a token along with the ABE key to the token issuance microservice 314 (step 10). The token issuance microservice 314 attempts to use the ABE key to decrypt the lock metadata for each attribute-value pair maintained in the token issuance microservice 314. For attribute-value pairs whose lock metadata can be decrypted by the provided ABE key, the attribute-value pair is included in the contents of the returned authentication token, e.g., access token and ID token (step 11). The access token and ID token with the attribute-value pair whose lock metadata can be decrypted are returned to the relying party 220 (step 11). Next, relying party 220 requests access to the protected computing resource, and resource server 240 returns the requested computing resource, performing steps 12 and 13 similar to Figure 2. The use of attribute-value pairs by the relying party is implementation-dependent based on the specific resource server. For example, these attribute-value pairs may be used to determine whether the token is scoped for access to the resource or any other functionality the resource server deems appropriate. Locking metadata may be created by a policy owner for a particular enterprise and attached to the token-issuing microservice out-of-band.

[0101] In some exemplary embodiments, the ABE key sent from the relying party 220 can also be replaced with a ciphertext. In these exemplary embodiments, the lock metadata itself can be replaced with an ABE key if that attribute is an entity that meets the requirements of the security rules / policies. Thus, in these exemplary embodiments, the test becomes an attempt to decrypt the ciphertext using each ABE key associated with each of the attribute values, but the general mechanics described above are similar. If the ciphertext sent from the relying party 220 to the token issuance microservice 314 can be decrypted by the ABE key (lock metadata in this exemplary embodiment), the corresponding attribute-value pair can be added to the token issued by the token issuance microservice 314.

[0102] As mentioned above, in some exemplary embodiments, an attribute name may refer to a list of attribute values ​​with accompanying lock metadata that is a test used for which attribute value or whether the attribute should contain multiple values. That is, an ABE key can be used to decrypt one or more lock metadata in the list of attribute values, and the corresponding attribute values ​​associated with the decrypted lock metadata may be included in the issued token. Figure 4 is an exemplary diagram showing an attribute name / key vs. attribute value list data structure with corresponding lock metadata, according to one exemplary embodiment.

[0103] As shown in FIG. 4, an encrypted attribute name / key-attribute value list data structure 400 can be maintained by the token issuance microservice 314. The encrypted attribute name / key-attribute value list data structure 400 includes a list of attribute names or attribute keys 410 with an associated list of one or more potential attribute values ​​420 for the corresponding attribute name / key 410. Each potential attribute value 420 has associated lock metadata 430 that can be decrypted by a corresponding ABE key 440. It should be understood that in some implementations, any given lock metadata can be unlocked using multiple ABE keys. According to the ABE mechanism, an ABE key only needs the correct attribute to unlock the lock metadata.

[0104] The security policies and master ABE keys implemented by the AAM 312 cause the AAM 312 to issue ABE keys only to user agents 210 whose credentials satisfy the security policies / rules, and the issued ABE keys depend on the specific attributes associated with the entity corresponding to the authenticated credentials. These ABE keys can be used to decrypt one or more of the lock metadata 430. Successfully decrypting the lock metadata 430 associated with a potential attribute value 420 results in that potential value being included in the issued token as part of an attribute name / key-value pair in the issued token's content. This can be done for each attribute name / key 410 such that multiple attribute name / key-value pairs are included in the issued token; in some cases, the same attribute name / key 410 can have multiple potential attribute values ​​420 that can be included due to those lock metadata 430.

[0105] In some exemplary embodiments, encrypted lock metadata 430 may include encrypted versions of the attribute name / key-attribute value pairs themselves. That is, potential attribute values ​​420 are not separate data from lock metadata 430; rather, potential attribute values ​​420 may be encrypted or encrypted along with attribute name / key 410 to generate encrypted lock metadata 430. Thus, if lock metadata 430 can be decrypted using ABE key 440, token issuance microservice 314 can access the decrypted attribute name / key-value pairs, which can then be added to issued tokens. Thus, unlike exemplary embodiments in which encrypted lock metadata 430 is an arbitrary string of bytes, encrypted lock metadata 430 in these exemplary embodiments is an encrypted version of the attribute name / key-value pairs (attribute name / value), which has the advantage of hiding both the attribute name / key and its value from an attacker who may gain access to token issuance microservice 314 of distributed authentication system 310.

[0106] As described above, the exemplary embodiment's mechanism of replacing the opaque authorization codes of the OAuth2 / OIDC architecture, which requires a specific mapping of attributes to authorization codes, with the ABE key mechanism has the advantage of offloading token issuance to a microservice separate from authentication and authorization services and functions, making it more difficult for attackers to gain access to protected computing resources. The exemplary embodiment also provides a mechanism for obfuscating security policies and rules by embedding them in the ABE keys, such that the ABE mechanism issues ABE keys only to entities whose attributes satisfy the security policies and rules. That is, if an attacker gains access to the ABE keys, they still cannot determine the security policies and rules that led to the issuance of the ABE keys. Furthermore, the exemplary embodiment obfuscates the attribute values ​​that can access computing resources by implementing locking metadata on the attribute values ​​that can only be decrypted using the appropriate ABE key. Thus, again, without the appropriate ABE keys that are issued only to entities with the correct combination of attributes, an attacker cannot determine which attribute values ​​are authorized to access protected computing resources, even if they gain access to the token issuance microservice 314. Additionally, when the token issuance microservice 314 makes a decision regarding which attribute name / key-value pairs (e.g., claims) to add to an issued token, the token issuance microservice 314 simply attempts to decrypt the lock metadata associated with the potential attribute value (claim) instead of requiring a complex database query to find the attribute, as is the case with authentication codes used by monolithic authentication servers.

[0107] It should be understood that the operational components of the distributed authentication system 310 shown in FIG. 3 can be implemented as dedicated computer hardware components, computer software running on the computer hardware and configured to perform the specific computer operations attributed to the component, or any combination of dedicated computer hardware and computer software. It should be understood that these operational components perform the associated operations automatically, without human intervention. That is, even when a "user" is referenced in FIG. 3 , this merely refers to the authenticated entity. The actual data messages transmitted between the depicted entities are automatically generated by the associated computing devices as data messages potentially in response to user input, but are otherwise automatically generated and transmitted. The present invention is particularly directed to automatically operating computer components directed to improving the way entity authentication is performed so as to improve the security of authentication systems and provide a specific solution to the problems of monolithic authentication services described above. The improved computing tool mechanisms and improved computing tool functions of the exemplary embodiments are not actually executable by humans as mental processes and are not directed to orchestrating any human activity.

[0108] Figures 5-6 present flowcharts outlining exemplary operations of elements of the present invention in accordance with one or more exemplary embodiments. It should be understood that the operations outlined in Figures 5-6 are, among other things, automatically performed by the improved computing tools of the exemplary embodiments and are not intended to be, and indeed cannot be, performed by humans, either as mental processes or by orchestrating human activity. To the contrary, while humans may, in some cases, initiate the performance of the operations described in Figures 5-6 and may, in some cases, utilize results produced as a result of the operations described in Figures 5-6, the operations in Figures 5-6 themselves are, among other things, performed in an automated manner by the improved computing tools.

[0109] FIG. 5 is a flowchart outlining the operation of the authentication and authorization microservice (AAM) according to one exemplary embodiment. As shown in FIG. 5, operation begins by receiving a login request, such as the login request in step 3 in FIG. 3 (step 510). The AAM challenges the user agent with credentials that identify the entity requesting access to the computing resource (step 520). The received credentials are then authenticated based on established security policies / rules to ensure that the credentials meet the security policies / rules for generating / issuing an ABE key to the user agent (step 530). A determination is made as to whether the credentials are authenticated (step 540). If not, access is denied and an appropriate response is returned to the user agent (step 570). If the credentials are authenticated, an ABE key is generated based on the master ABE key (step 550). A redirect is then returned to redirect the user agent to the relying party with the generated ABE key (step 560). For example, in step 9 of Figure 3, the user agent then performs a redirect to the relying party and provides the ABE key, after which the operation ends.

[0110] FIG. 6 is a flowchart outlining the operation of the token issuance microservice according to one example embodiment. As shown in FIG. 6, for example, in step 10 of FIG. 3 (step 610), the operation begins by receiving a request for a token along with an ABE key, where the request is sent from a relying party. The received ABE key is then used as a decryption key to attempt to decrypt lock metadata for potential values ​​for the attribute name / key (step 620). Next, attribute name / key-value pairs whose lock metadata can be decrypted using the ABE key are selected and included in a token generated by the token issuance microservice (step 630). The generated token is then returned to the relying party (step 640). Thereafter, for example, in steps 12 and 13 of FIG. 3, the relying party uses these tokens to access protected computing resources at the resource server. The operation then ends.

[0111] The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will become apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The embodiments have been chosen and described to best explain the principles and practical applications of the invention and to enable others skilled in the art to understand the invention in various embodiments with various modifications that are suitable for the particular use contemplated. The terms used herein have been chosen to best explain the principles, practical applications, or technical improvements over technologies found in the marketplace of the embodiments, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A method for computing resource access security in a data processing system, comprising: authentication and authorization logic of the data processing system authenticating user agent credentials to determine whether the user agent is associated with an entity for which an attribute-based encryption (ABE) key is to be generated; generating an ABE key and providing the ABE key to the user agent in response to the authentication and authorization logic determining that the user agent is associated with the entity for which an ABE key is generated, wherein the ABE key corresponds to a set of attributes of the entity; receiving, by token issuing logic of the data processing system, a token request and the ABE key from a relying party computing device; the token issuing logic performing a decryption operation on lock metadata associated with at least one attribute value based on the ABE key; and the token issuance logic, in response to the decryption operation successfully decrypting the lock metadata, issuing a generated token to the relying party computing device based on the at least one attribute value, wherein the relying party computing device uses the generated token to access the computing resource.

1. A method for computing resource access security, comprising:

2. 10. The method of claim 1, further comprising: provisioning attributes and corresponding candidate attribute values ​​into the token issuance logic as attribute-value pairs, wherein each candidate attribute value of each attribute-value pair is associated with corresponding lock metadata.

3. Provisioning attributes and corresponding candidate attribute values ​​into the token issuance logic comprises: storing a plurality of attribute names in an attribute-value data structure; storing, for each attribute name in the plurality of attribute names, a list of candidate attribute values ​​for the attribute name in the attribute-value data structure; and storing in the attribute-value data structure, for each candidate attribute value in each list of candidate attribute values ​​for each attribute name, the corresponding lock metadata encrypted such that only the ABE key of an authorized user agent corresponding to the candidate attribute value can decrypt the corresponding lock metadata.

3. The method of claim 2, comprising:

4. The method of any one of claims 1 to 3, wherein the lock metadata is an arbitrary byte sequence encrypted such that a valid ABE key decrypts the lock metadata.

5. The method of any one of claims 1 to 4, wherein the lock metadata is an attribute-value pair corresponding to the lock metadata that is encrypted such that a valid ABE key decrypts the lock metadata.

6. The method of any one of claims 1 to 5, further comprising provisioning a plurality of master ABE keys to the authentication and authorization logic, wherein the ABE keys are generated based on corresponding master ABE keys in the plurality of master ABE keys.

7. 7. The method of claim 6, wherein each master ABE key is associated with a different computing resource owner, and an ABE key generated based on a first master ABE key associated with a first provider of computing resources cannot decrypt lock metadata corresponding to an ABE key generated based on a second master ABE key associated with a second computing resource owner.

8. The ABE key is a ciphertext, each lock metadata associated with each attribute value in the at least one attribute value includes a corresponding second ABE key; performing the decryption operation includes attempting to decrypt the ciphertext of the ABE key using each lock metadata associated with each attribute value in the at least one attribute value; issuing the generated token includes, in response to the corresponding second ABE key for the one or more attribute values ​​successfully decrypting the ciphertext, generating the generated token by incorporating one or more attribute values ​​of the at least one attribute value into the generated token. The method according to any one of claims 1 to 7.

9. 9. The method of claim 1, wherein issuing the generated token comprises generating the token by including the at least one attribute value in the token in response to the decryption operation being successful, wherein the token is one of an access token or an ID token.

10. 10. The method of claim 9, wherein the token is a JavaScript Object Notation Web Token (JWT) and the at least one attribute value comprises at least one claim of the JWT.

11. 11. The method of claim 1, wherein the authentication and authorization logic is a first microservice running on a first computing device of the data processing system, and the token issuance logic is a second microservice running on one of the first computing device or a second computing device different from the first computing device.

12. provisioning attributes and attribute values ​​that are candidates for inclusion in a token as candidate attribute-value pairs into the token issuance logic; provisioning the authentication and authorization logic with a master ABE key for generating ABE keys, wherein issuing the generated token to the relying party computing device based on the at least one attribute value comprises generating the token to include the at least one attribute value from a subset of the candidate attribute-value pairs, and the ABE keys are generated based on the master ABE key. The method of any one of claims 1 to 11, further comprising:

13. 1. A computer program product comprising a computer readable storage medium having stored thereon a computer readable program that, when executed within a data processing system, causes the data processing system to: causing authentication and authorization logic of the data processing system to authenticate user agent credentials to determine whether the user agent is associated with an entity for which an attribute-based encryption (ABE) key is to be generated; causing the authentication and authorization logic to generate the ABE key and provide the ABE key to the user agent in response to determining that the user agent is associated with the entity for which an ABE key is to be generated, wherein the ABE key corresponds to a set of attributes of the entity; receiving, by token issuance logic of said data processing system, a token request and said ABE key from a relying party computing device; causing the token issuing logic to perform a decryption operation on lock metadata associated with at least one attribute value based on the ABE key; and causing the token issuance logic, in response to the decryption operation successfully decrypting the lock metadata, to issue a generated token to the relying party computing device based on the at least one attribute value, wherein the relying party computing device uses the generated token to access the computing resource. Computer program products.

14. 14. The computer program product of claim 13, wherein the computer-readable program further causes the data processing system to provision attributes and corresponding candidate attribute values ​​to the token issuance logic as attribute-value pairs, wherein each candidate attribute value of each attribute-value pair is associated with corresponding lock metadata.

15. The steps for provisioning attributes and corresponding candidate attribute values ​​into the token issuance logic include: storing multiple attribute names in an attribute-value data structure; storing, for each attribute name in the plurality of attribute names, a list of candidate attribute values ​​for the attribute name in the attribute-value data structure; and storing, for each candidate attribute value in each list of candidate attribute values ​​for each attribute name, in the attribute-value data structure, the corresponding lock metadata encrypted such that only the ABE key of an authorized user agent corresponding to the candidate attribute value can decrypt the corresponding lock metadata.

15. A computer program product according to claim 13 or 14, comprising:

16. 16. The computer program product of claim 13, wherein the lock metadata is an arbitrary byte sequence encrypted such that a valid ABE key decrypts the lock metadata.

17. 17. The computer program product of claim 13, wherein the lock metadata is an attribute-value pair corresponding to the lock metadata that is encrypted such that a valid ABE key decrypts the lock metadata.

18. 18. The computer program product of claim 13, wherein the computer-readable program further causes the data processing system to provision a plurality of master ABE keys to the authentication and authorization logic, wherein the ABE keys are generated based on corresponding master ABE keys in the plurality of master ABE keys.

19. 20. The computer program product of claim 18, wherein each master ABE key is associated with a different computing resource owner, and an ABE key generated based on a first master ABE key associated with a first provider of computing resources cannot decrypt lock metadata corresponding to an ABE key generated based on a second master ABE key associated with a second computing resource owner.

20. The ABE key is a ciphertext, each lock metadata associated with each attribute value in the at least one attribute value includes a corresponding second ABE key; performing the decryption operation includes attempting to decrypt the ciphertext of the ABE key using each lock metadata associated with each attribute value in the at least one attribute value; wherein the step of issuing the generated token includes, in response to the corresponding second ABE key of the one or more attribute values ​​successfully decrypting the ciphertext, generating the generated token by incorporating one or more attribute values ​​of the at least one attribute value into the generated token. A computer program product according to any one of claims 13 to 19.

21. 21. The computer program product of claim 13, wherein issuing the generated token comprises generating the token by including the at least one attribute value in the token in response to the decryption operation being successful, wherein the token is one of an access token or an ID token.

22. 22. The computer program product of claim 21, wherein the token is a JavaScript Object Notation Web Token (JWT) and the at least one attribute value comprises at least one claim of the JWT.

23. 23. The computer program product of claim 13, wherein the authentication and authorization logic is a first microservice running on a first computing device of the data processing system, and the token issuance logic is a second microservice running on one of the first computing device or a second computing device different from the first computing device.

24. provisioning attributes and attribute values ​​that are candidates for inclusion in a token as candidate attribute-value pairs into the token issuance logic; provisioning the authentication and authorization logic with a master ABE key for generating ABE keys, wherein issuing the generated token to the relying party computing device based on the at least one attribute value comprises generating the token to include the at least one attribute value from a subset of the candidate attribute-value pairs, and the ABE keys are generated based on the master ABE key. The computer program product of any one of claims 13 to 23, further comprising:

25. at least one processor; and at least one memory coupled to the at least one processor; wherein the at least one memory, when executed by the at least one processor, causes the at least one processor to: causing authentication and authorization logic of the at least one processor to authenticate user agent credentials to determine whether the user agent is associated with an entity for which an attribute-based encryption (ABE) key is to be generated; causing the authentication and authorization logic to generate the ABE key and provide the ABE key to the user agent in response to determining that the user agent is associated with the entity for which an ABE key is to be generated, wherein the ABE key corresponds to a set of attributes of the entity; causing the token issuance logic of the at least one processor to receive a token request and the ABE key from a relying party computing device; causing the token issuing logic to perform a decryption operation on lock metadata associated with at least one attribute value based on the ABE key; and causing the token issuance logic, in response to the decryption operation successfully decrypting the lock metadata, to issue a generated token to the relying party computing device based on the at least one attribute value, wherein the relying party computing device uses the generated token to access the computing resource. A device having instructions.

Images