Third party data access authorization for attribute-based encryption keys

Abstract

Mechanisms are provided for computing resource access security in which credentials of a user agent are authenticated to determine whether the user agent is associated with an entity for which an attribute-based encryption (ABE) key is to be generated. If associated, an ABE key is generated and provided that corresponds to the set of attributes of the entity. The token publishing logic receives a token request and an ABE key from the relying computing device, and performs a decryption operation on lock metadata associated with the at least one attribute value based on the ABE key. The token publishing logic publishes the generated token to the relying computing device based on the at least one attribute value in response to the decryption operation successfully decrypting the lock metadata. The relying computing device uses the generated token to access the computing resource.

Description

Background Art

[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 were developed to allow owners of data to grant access to that data to third parties for various purposes. For example, Open Authorization 2 (OAuth2) is a protocol that allows users to grant access and control access to data they own on one site to third-party sites for several data processing use cases. These use cases range from printing digital photos that a user has stored on a site (e.g., in the cloud) to running analytics on data stored in, for example, a data lake. OpenID Connect (OIDC) is an identity layer that operates on top of OAuth2. With OIDC, additional tokens called ID tokens are added that identify the user who is authorizing access to the data.

[0003] While OIDC and OAuth2 provide protocols for controlling access to data, these tools still suffer from problems if an attacker successfully compromises the authentication servers of these protocols. That is, if compromised, the attacker can access the authentication tokens and the authentication server's authentication protocol, granting them access to protected computing resources. This presents a significant computer security issue. Summary of the Invention

[0004] This Summary is provided to introduce some concepts in a simplified form that are further described herein in the Detailed Description. This Summary is not intended to identify key factors 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 illustrative embodiment, a method for securing access to computing resources in a data processing system is provided. The method includes authenticating the credentials of a user agent by authentication and authorization logic of the data processing system 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 also includes generating, by the authentication and authorization logic, an ABE key in response to determining that the user agent is associated with the entity for which the ABE key is to be generated, 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 receiving, by token issuance logic of the data processing system, a token request and an ABE key from a relying party computing device, and performing, by the token issuance logic, a decryption operation on locking metadata associated with at least one attribute value based on the ABE key. The method also includes issuing, by the token issuance logic, a generated token based on the at least one attribute value to the relying party computing device in response to the decryption operation successfully decrypting the locking metadata. The relying party computing device uses the generated token to access the computing resource. Thus, using this method, unlike requiring an authorization code mapping, the ABE key mechanism allows the determination of attribute values ​​to be included in the issued token without requiring an explicit provider-maintained authorization code mapping with the attributes.

[0006] In some illustrative embodiments, the method further includes publishing the logical provisioning attribute and the corresponding candidate attribute value as an attribute-value pair to the token. Each candidate attribute value of each attribute-value pair is associated with corresponding locking metadata. Thus, for these illustrative embodiments, locking metadata is associated with each candidate attribute value, and if the associated locking metadata for the candidate attribute value can be decrypted, the candidate attribute value can be used to generate the issued token.

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

[0008] In some illustrative embodiments, the locking metadata is an arbitrary sequence of bytes that is encrypted such that a valid ABE key decrypts the locking metadata. In these illustrative embodiments, the locking metadata content is unimportant to the locking functionality, as determining whether the locking metadata can be successfully decrypted is independent of the specific content of the locking metadata. Thus, the locking metadata can be any arbitrary sequence of bytes.

[0009] In some illustrative embodiments, the locking metadata is an attribute-value pair corresponding to the locking metadata, and the locking metadata is encrypted so that a valid ABE key can decrypt the locking metadata. In these illustrative embodiments, the attribute-value pairs are further obfuscated by encrypting and using the attribute-value pairs as the locking metadata. Thus, while other illustrative embodiments may have the attribute-value pairs and associated locking metadata in plain text, in these illustrative embodiments, the attribute-value pairs are also encrypted, resulting in greater security.

[0010] In some demonstrative embodiments, the method further includes supplying a plurality of master ABE keys to the authentication and authorization logic, wherein the ABE keys are generated based on corresponding master ABE keys from the plurality of master ABE keys. In some demonstrative embodiments, each master ABE key is associated with a different computing resource owner, and wherein an ABE key generated based on a first master ABE key associated with a first provider of computing resources cannot decrypt locked metadata corresponding to an ABE key generated based on a second master ABE key associated with a second computing resource owner. In these demonstrative embodiments, different owners of computing resources can maintain their own master ABE keys for issuing ABE keys, allowing them to have separate security policies and ensure that their computing resources cannot be accessed using ABE keys issued based on the master ABE keys of other resource owners.

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

[0012] In some illustrative embodiments, issuing the generated token includes generating the token by at least including at least one attribute value in the token in response to a successful decryption operation. In some illustrative embodiments, the token is an access token or an ID token. The access token or the ID token can be used with other OAuth2 / OIDC-based mechanisms to gain access to protected computing resources. In some illustrative 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 illustrative embodiments, the security of the token issuance mechanism is improved while still being usable with OAuth2 / OIDC-based mechanisms and JWTs.

[0013] In some illustrative embodiments, the authentication and authorization logic is a first microservice executed on a first computing device of the data processing system, and wherein the token issuance logic is a second microservice executed on one of the first computing device or a second computing device different from the first computing device. Thus, in these illustrative embodiments, the microservices architecture facilitates distributing the functionality of the authentication and authorization logic and the token issuance logic to different computing devices, which increases the security of the system from being compromised.

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

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

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

[0017] These and other features and advantages of the present invention will be described in or will become apparent to those skilled in the art in view of the following detailed description of exemplary embodiments of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The invention, its preferred mode of use, and 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 in which:

[0019] Figure 1 is an example diagram of a distributed data processing system environment in which aspects of the illustrative embodiments may be implemented and in which at least some of the computer code involved in performing the methods of the present invention may be executed;

[0020] Figure 2 is an example data flow diagram illustrating the operation of the OAuth2 / OIDC architecture;

[0021] Figure 3 is an example data flow diagram illustrating the operation of a distributed authentication system according to one illustrative embodiment;

[0022] Figure 4 is an example diagram illustrating a property name / key to property value list data structure with corresponding locking metadata according to one illustrative embodiment;

[0023] Figure 5 is a flow chart outlining the operation of an authentication and authorization microservice according to one illustrative embodiment; and

[0024] Figure 6 is a flowchart outlining the operation of a token issuance microservice according to one illustrative embodiment. DETAILED DESCRIPTION

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

[0026] The illustrative embodiments provide improved computing tools and improved computing tool functionality / operations for implementing attribute-based authorization of cryptographic keys for third-party access to computer resources, such as applications and data structures. Attribute-based encryption (ABE) (originally known as Fuzzy Identity-Based Encryption) is a public-key-based authentication mechanism that enables fine-grained access control to encrypted data using security authorization policies in which a user's secret key and ciphertext are dependent on attributes, such as their email address, country of residence, subscription type, or accounts they have. Ciphertext in ABE can only be decrypted if the attribute set of the user's key matches the attributes of the ciphertext. Thus, only users who meet certain access protocols can access the decrypted plaintext of the ciphertext. ABE allows for multiple types of encryption; that is, multiple private or secret keys can be generated based on the same public key.

[0027] For example, suppose a person wishes to generate a confidential document to be shared with members of a workgroup within a company. Under identity-based cryptography, this person would have to create multiple encrypted versions of the document for each potential recipient. However, with ABE, the document can be encrypted using a public key generated based on a set of attribute values. By specifying a key release policy implemented by a key generator, a secret or private key can be provided to anyone with a specific set of attribute values ​​to decrypt the encrypted confidential document. For example, suppose the attributes are location, department, and workgroup, and the policy stipulates that the confidential document can only be accessed by individuals with a location attribute value of "United States," a department of "Cloud Computing Solutions," and a workgroup of "XYZ Platform." The confidential document is encrypted using these specific attribute values ​​to generate a public key-encrypted confidential document. When a user wishes to access the encrypted document, they request a key from the key generator and provide their credentials, which include their location, department, and workgroup. The key generator implements the defined security policy or policies used to encrypt the document and determines whether to release a decryption key to the user. If the user's authenticated attribute values ​​match the conditions of the security policy, the user is presented with a decryption key, which they can use to decrypt the encrypted confidential document.

[0028] According to an illustrative embodiment, ABE is implemented to provide ABE keys as part of a mechanism for authorization, replacing opaque authorization codes in computer resource access flows. The ABE keys are used to decrypt metadata associated with attributes to be placed in a token used to authenticate parties as part of a computer resource access operation, such as an Internet web application. The ABE key mechanism relies on the entity (or party) possessing the ABE key to embed one or more authorization policies within the ABE key itself. Specifically, the ABE key is only issued to entities (or parties) that meet the requirements of a security policy, as defined in a key generator, which requires the entity (or party) to possess one or more specific attribute values, as defined in one or more policies. According to an illustrative embodiment, the attribute values ​​to be included in an authentication token used to authenticate a user can themselves be encrypted using a piece of encrypted metadata, allowing the ABE key to be used to decrypt the attribute values. Due to the ABE mechanism, if a party is able to decrypt the metadata associated with the attribute values, the fact that the metadata was successfully decrypted indicates that the corresponding attribute values ​​will be included in the authentication token. Therefore, by using ABE keys and mechanisms to determine which attribute values ​​to include in an access token, rather than using opaque authorization codes, providers do not need to maintain attribute values ​​and map them to authorization codes. Instead, according to the illustrative embodiments, the work of determining what attribute values ​​to include in the authentication token may be offloaded to a microservice.

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

[0030] Using JSON Web Token (JWT) as an example, the attributes associated with metadata can be any attributes defined in the JWT, such as claims or scopes. A JWT's claims are use case specific, but will generally specify characteristics of the entity requesting access to a computing resource, such as the identity of the issuing party, the validity period, and the access permissions granted to the entity. This entity can be a user, application, or organization, or any other entity that can request access to a computing resource and whose identity and authorization can be authenticated through cryptographic security mechanisms. A JWT's scope is a grouping of claims. JWT is an open standard for sharing secure information between parties, such as a server and a client. Because JWTs are cryptographically signed, the JWT's claims cannot be altered. While JSON and JWT are used as examples herein, it should be understood that other Electronic Data Interchange (EDI) standards that use other types of tokens for sharing secure information between parties can be used for illustrative embodiments without departing from the spirit and scope of the present invention. For example, other token formats can be used, including comma-delimited string format, Extensible Markup Language (XML), and the like.

[0031] The ABE key-based authentication mechanism of the illustrative embodiments provides a secure microservices environment in which policies and rules for creating tokens / authorization codes do not have to be shared via some other flow because they are embedded in the ABE key mechanism. Microservices is a cloud-native architectural approach in which a single application is composed of many smaller components or services that are loosely coupled and independently deployable. 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 streams, and message brokers, and are organized by business capabilities, with rows separating services often referred to as bounded contexts.

[0032] According to one or more illustrative embodiments, the authentication mechanism is divided into an authentication microservice and a token issuance microservice. Both microservices are provided with data for token issuance, but do not necessarily need to be connected to the same database to securely issue tokens. Both microservices are provided with data and rules for issuing access tokens (which are meant to be read by the computing resource server to specify the permissions granted to the protected computing resource) and ID tokens (which are meant to be read by the 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 be included in the access token and the ID token. The attributes and attribute values ​​can be stored as attribute-value pair metadata, where the attributes can be JWT attributes and the values ​​can be any suitable values ​​for those corresponding attributes, for example, subscriber = admin, application name = app1, version = 1.0.0, tier = top level, etc.

[0033] An attribute-value pair may have associated metadata, which can be any small encrypted data structure that will be used to test whether the provided ABE key contains one or more attribute values ​​that allow the presenter of the ABE key to obtain access tokens and ID tokens. This metadata can be, for example, any arbitrary sequence of bytes, as the content of the metadata is unrelated to its "locking" function as part of the ABE key mechanism. That is, as long as the ABE key can be used to decrypt the metadata, the fact that the decryption was successfully performed itself is an indicator that the corresponding attribute value should be included in the corresponding issued access token or ID token. In some cases, the encrypted metadata can be the attribute value itself or the attribute-value pair itself, rather than an arbitrary sequence of bytes. For the purposes of this description, this encrypted metadata used to lock the attribute value or attribute-value pair is referred to herein as "locking metadata."

[0034] After attempting to decrypt the lock metadata, the contents of the lock metadata are discarded. It is used solely as an access control method for adding attribute-value pairs to tokens (e.g., JWTs). In some illustrative embodiments, an attribute name may point to a value list with accompanying lock metadata that is used to test which attribute value a property should contain or whether multiple values ​​should be included. That is, the ABE key can be used to decrypt one or more pieces of lock metadata in the value list, and the corresponding values ​​associated with the decrypted pieces of lock metadata can be included in the issued token.

[0035] In the second provisioning operation, the master ABE key is provisioned to the Authentication and Authorization Microservice (AAM). The master ABE key is provisioned on the AAM so that it can generate ABE keys (see Figure 3 Step 7). Multiple AAMs may exist and operate in conjunction with the token issuance microservice, with each instance of an AAM being associated with a corresponding resource owner or resource owner's user agent. Each resource owner may protect a master ABE key on their AAM according to their own security policy. Each resource owner may issue an ABE key that may be consumed by a single token issuance microservice that supports all resource owners. Each resource owner's token issuance security policy or rules may still be protected with appropriate encryption and attribute-value pairs of the resource owner, which may only be unlocked with an ABE key from the resource owner that owns the locked metadata and the master ABE key. Because the ABE keys are generated from different master ABE keys, an ABE key issued by one resource owner cannot decrypt the locked metadata of another resource owner.

[0036] In some illustrative embodiments, the ABE key sent from the relying party can also be replaced with the ciphertext. In these illustrative embodiments, the locking metadata itself can be replaced with the ABE key. Thus, in these illustrative embodiments, the test becomes an attempt to decrypt the ciphertext using each ABE key associated with each attribute value, but the overall mechanism described above is similar.

[0037] As described above, in some illustrative embodiments, a list of encrypted lock metadata is supplied to the token issuing microservice, 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 proposed by the relying party, the key-value pair is added to the access token, such as a JWT. Thus, unlike the illustrative embodiments where the encrypted lock metadata is an arbitrary sequence of bytes, the encrypted lock metadata of these illustrative embodiments is an encrypted version of the key-value pair (attribute name / value). This approach has the advantage of hiding the attribute keys (names) and their values ​​from attackers who can penetrate the authentication server. Without departing from the spirit and scope of the present invention, access token (e.g., JWT) attributes can be anything from claims, scopes, or any other data that the implementer wishes to include in the access token (e.g., JWT).

[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 the OIDC client for an actual authentication token, which includes any cryptographically signed statements about identity assertions. Opaque authorization codes are inherently meaningless and contain no metadata. Any rules / policies are mapped in the token issuing service.

[0039] The mechanism of the illustrative embodiment replaces the authorization code in the data access flow with an ABE key / ciphertext mechanism. The illustrative embodiment has the following advantages. First, the mechanism of the illustrative embodiment improves the ability to move token issuance functionality from the authentication and authorization service to a separate compute service and reduces the load on the user authentication mechanism, thereby easing the need to migrate monolithic authentication server applications to a microservices architecture for scalability and security. Second, the mechanism of the illustrative embodiment allows enterprise rules and attributes such as identity or group membership to be anonymized and hidden within the ABE key used in place of the authentication code.

[0040] Third, the mechanisms of the illustrative embodiments enable parties to hide enterprise rules from the token issuing compute service itself, thereby improving the security of the authentication system in the event that the token issuing compute microservice is compromised. Utilizing ABE keys, the rules / policies do not need to be known to the token issuing service at all. Therefore, if the token issuing service is compromised, these rules / policies remain hidden using the mechanisms of the illustrative embodiments. When the token issuing compute microservice decides what JWT claims (e.g., attributes / values) to add to the token, the token issuing compute microservice simply attempts to decrypt the locking metadata associated with the JWT claims (attribute values), without requiring complex database queries to find the presenter's JWT attributes, as in the case of authentication codes used by authentication servers (e.g., OAuth2 / OIDC authentication servers).

[0041] Thus, the illustrative embodiments provide improved computing tools and improved computing tool functionality / operations that provide ABE keys (or ciphertext in some illustrative embodiments described below) rather than opaque authorization codes. ABE keys are embedded in rules / policies, where the attributes associated with the ABE keys are specified as part of a set of well-defined cryptographic functions that provide a high degree of security while enabling a clean separation between token issuance and authentication services. That is, ABE keys are issued to the user agent of an authorized entity based on the attributes of the authorized entity. Locking metadata is encrypted using a standard set of rules / security policies specifying the entity's attributes, enabling the ABE keys of entities with these attributes to decrypt the corresponding locking metadata using the ABE keys. For example, assume the attribute set is {A, B, C, D}, and a first entity receives an ABE key corresponding to the attributes {A, B}. Also assume a second entity receives an ABE key corresponding to the attributes {C, D}. If the locking metadata is encrypted using the security policy "(A and C) or D," the second entity's ABE key can decrypt the locking metadata, but the first entity's ABE key cannot. Therefore, the ABE key mechanism implicitly implements the security policy without having to have an explicit mapping of authentication codes. In addition, by associating locking metadata with a specific candidate attribute-value pair, the corresponding attribute-value pair whose locking metadata is decrypted by the ABE key can be automatically integrated into the issued token.

[0042] It will be appreciated that while the illustrative embodiments are described with reference to JWT and OAuth2 / OIDC as examples, the illustrative embodiments are not limited thereto. Rather, the mechanisms of the illustrative embodiments may be implemented using any token issuance protocol and any appropriate type of token, along with corresponding token attributes and attribute values ​​expressed in any appropriate implementation. For example, the present invention is not limited to attribute-value pair data structures. The illustrative embodiments are provided as examples, and those skilled in the art will recognize that many modifications may be made to these examples in light of this description without departing from the spirit and scope of the present invention.

[0043] Before proceeding to discuss various aspects of the illustrative embodiments and the improved computer operations performed by the illustrative embodiments, it should first be understood that, throughout this specification, the term "mechanism" may be used to refer to elements of the present invention that perform various operations, functions, and the like. As used herein, the term "mechanism" may be a device, process, or computer program product that implements a function or aspect of the illustrative embodiments. In the case of a process, the process is implemented by one or more devices, apparatuses, computers, data processing systems, and 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 functions associated with a particular "mechanism" or perform the operations associated with a particular "mechanism." Thus, the mechanisms described herein may be implemented as dedicated hardware, software executed on hardware to thereby configure the hardware to perform the specialized functions of the present invention that the hardware is not otherwise capable of performing, software instructions stored on a medium so that the instructions can be readily executed by hardware to thereby specifically configure the hardware to perform the recited functions and specific computer operations described herein, a process or method for performing the functions, or any combination thereof.

[0044] This specification and claims may use the terms "a," "at least one," and "one or more" with respect to particular features and elements of the illustrative embodiments. It will be understood that these terms and phrases are intended to indicate that at least one of a particular feature or element is present in a particular illustrative embodiment, but more than one may be present. That is, these terms / phrases are not intended to limit the specification or claims to the presence of a single feature / element or to require the presence of a plurality of such features / elements. Rather, these terms / phrases merely require at least a single feature / element, with the possibility of multiple such features / elements being within the scope of the specification and claims.

[0045] Furthermore, it should be understood that if the term "engine" is used herein with respect to describing embodiments and features of the present invention, it is not intended to limit any particular technology implementation for implementing and / or executing the actions, steps, processes, etc. attributable to and / or performed by the engine. Rather, it is intended that the "engine" be implemented using computer technology, and its actions, steps, processes, etc. are not performed as mental processes or through human effort, even though the engine may operate in conjunction with human input or provide output intended for human or mental effort. The engine is implemented as one or more of software, dedicated hardware, and / or firmware executed on hardware, or any combination thereof, specifically configured to perform the specified functions. The hardware may include, but is not limited to, the use of a processor in conjunction with appropriate software 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 functions of one or more embodiments of the present invention. Furthermore, unless otherwise noted, any name associated with a particular engine is for ease of reference and is not intended to limit the engine to a particular embodiment. Furthermore, any functionality attributed to an engine may be equally performed by multiple engines, incorporated into the functionality of another engine of the same or different type and / or combined with another engine of the same or different type, or distributed across one or more engines in various configurations.

[0046] In addition, it will be appreciated that the following description uses a number of various examples of various elements of the illustrative embodiments to further illustrate example implementations of the illustrative embodiments and to aid in understanding the mechanisms of the illustrative embodiments. These examples are intended to be non-limiting and not an exhaustive list of various possibilities for implementing the mechanisms of the illustrative embodiments. In view of this specification, it will be apparent to one of ordinary skill in the art that many other alternative implementations of these various elements may be utilized in addition to or in lieu of the examples provided herein without departing from the spirit and scope of the present invention.

[0047] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time, again depending on the technology involved.

[0048] Computer program product embodiments ("CPP embodiments" or "CPPs") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") that are collectively included in a collection of one or more storage devices, which collectively include 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. Without limitation, a computer-readable storage medium can be 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: magnetic disks, 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 disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing. As the term is used in this disclosure, computer-readable storage media should not be construed as storing data in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at certain occasional points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transitory because the data is not transitory while it is stored.

[0049] It will be appreciated that certain features of the invention described in the context of separate embodiments for clarity may also be provided in combination in a single embodiment. Conversely, various features of the invention described in the context of a single embodiment for brevity may also be provided individually or in any suitable subcombination.

[0050] The illustrative embodiments provide improved computing tools and improved computing tool functionality / operations that are specifically directed to solving problems arising in the computer field, and specifically to the aforementioned problems associated with monolithic authentication server architectures being compromised by attackers and gaining access to protected computing resources. The illustrative embodiments provide specific solutions to these problems in the form of an attribute-based encryption (ABE) key system for token issuance and authentication of entities, which allows for separation of authentication and token issuance services and obfuscation of security policies and attributes used in these security policies. The illustrative embodiments can be implemented as part of a computer security system that protects computing resources, and can be implemented in a distributed data processing system to control access to a protected group of computing resources by multiple entities via one or more data networks. Accordingly, an illustrative distributed data processing system, such as a cloud computing environment, will be described first, in which aspects of the illustrative embodiments are implemented in one or more computing devices of the distributed data processing system, followed by a description of specific improved computing tool components and functionality.

[0051] The present invention may be a specially configured computing system configured with hardware and / or software that is itself specially configured to implement the specific mechanisms and functions described herein, a method implemented by a specially configured computing system, and / or a computer program product comprising software logic that is loaded into a computing system to specifically configure the computing system to implement the mechanisms and functions described herein. Regardless of whether described as a system, method, or computer program product, it is understood that the illustrative embodiments described herein are specifically directed to an improved computing tool and a method implemented by the improved computing tool.

[0052] Specifically, the improved computing tool of the illustrative embodiments specifically provides an authentication server computing tool, which may be a distributed authentication server computing tool, in which attribute-based encryption (ABE) replaces authentication codes in a manner that obscures security policies and attributes used to authenticate users for access to computing resources, and in which system-wide attacks are distributed to prevent access to protected computing resources. The improved computing tool implements mechanisms and functionality, such as an authentication server, in which authentication and authorization logic (which may be, 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 is practically incapable of being executed by humans outside of or with the assistance of a technical environment, such as a mental process. The improved computing tool provides practical application of the method, at least in that the improved computing tool encodes authentication rules / policies within an ABE key, obfuscating the rules / policies from the token issuance computing functionality. Furthermore, the improved computing tool provides practical application of the method, at least in that the improved computing tool is able to separate the authentication and authorization computer functionality from the token issuance computer functionality, thereby distributing the authentication server rather than using a vulnerable monolithic authentication server. Furthermore, the improved computing tool provides practical applications, and it does so using attribute-based encryption that obscures policies and attributes used to authenticate third parties accessing protected computing resources.

[0053] Figure 1 is an example diagram of a distributed data processing system environment in which aspects of the illustrative embodiments may be implemented and at least some of the computer code involved in performing the methods of the present invention may be executed. That is, computing environment 100 includes an example of an environment for executing at least some of the computer code involved in performing the methods of the present invention, such as a distributed authentication system 150 having microservices, such as an authentication and authorization microservice 152 and a token issuance microservice 154. It will be appreciated that while Figure 1 These microservices 152, 154 are shown as being provided on the same computing device 101, but these microservices can be distributed to different physical and / or virtual machines with different hardware / software resources so that the impairment of one microservice does not affect the other microservices. In some illustrative embodiments, components of the distributed authentication system 150 can be distributed to other remote computing devices, such as a remote server 104 or another computing device that can be accessed via one or more data networks 102 (as shown by the dashed lines). For example, the authentication and authorization microservice 152 can be provided on the computer 101, in which case, for example, the computer 101 can be a server computing device, and the token issuance microservice 154 can be provided on the remote server 104 or another server computing device coupled to the WAN 102. Figure 3-5The operation of the distributed authentication system 150 is described in more detail.

[0054] It will be appreciated that the distribution of these services across physical / virtual machines is an optional element of the illustrative embodiments. Because any mapping between the authentication and token issuance mechanisms is embedded in the ABE key mechanism, the combined code and token issuance service can still benefit from the improved computational capabilities of providing ABE keys as described herein. If these services are distributed, an additional benefit is that rules / policies do not have to be shared between the AAM and the token issuance service. Therefore, in the case where the authentication server and token issuance service would otherwise need some way to record how the authorization code maps to the claims to be inserted into the token, whether distributed or not, the illustrative embodiments provide a clear and secure way to solve this problem using ABE keys / ciphertext.

[0055] In addition to box 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 processor group 110 (including processing circuit 120 and cache 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and box 150, as described above), peripheral device group 114 (including user interface (UI), device group 123, storage 124, and Internet of Things (IoT) sensor group 125), and network module 115. Remote server 104 includes remote database 130. Public cloud 105 includes gateway 140, cloud orchestration module 141, host physical machine group 142, virtual machine group 143, and container group 144.

[0056] In general, 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 developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 130. That is, various types of computing devices communicating via one or more data networks may be provided in distributed computing environment 100. For purposes of describing the illustrative embodiments, it may be assumed that computer 101 is a server computing system that provides a distributed authentication system 150 having an authentication and authorization microservice 152 and a token issuance microservice 154 (again, a microservice architecture is not required, but is used as an example here). As a server computing system, computer 101 may not implement all of the elements shown, but these elements are provided here to illustrate the components of a computing system in which various aspects of the illustrative embodiments may be implemented in some illustrative embodiments. Server computer 101 provides distributed authentication system 150 for performing authentication and authorization computer functions and token issuance functions between end-user devices and various other services available via one or more data networks (e.g., the cloud), such as providing service authorization to end users and service-to-service authorization functions.

[0057] As is well known in the art of computer technology, and depending on the technology, the performance of a computer-implemented method can be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of the computing environment 100, the detailed discussion focuses on a single computer, particularly computer 101, to keep the presentation as simple as possible. Computer 101 can be located in the cloud, even in Figure 1 On the other hand, computer 101 need not be in the cloud except to any extent that can be positively indicated.

[0058] Processor complex 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, such as multiple cooperating 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(s) and is typically used for data or code that should be quickly accessed by threads or cores running on processor complex 110. Cache memory is typically organized into multiple levels based on relative proximity to the processing circuitry. Alternatively, some or all of the processor complex's caches may be located "off-chip." In some computing environments, processor complex 110 may be designed to work with quantum bits (qubits) and perform quantum computations.

[0059] Computer-readable program instructions are typically loaded onto the computer 101 to cause the processor group 110 of the computer 101 to execute a series of operating steps to implement the computer-implemented method, so that the instructions so executed will instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively referred to as the "inventive method"). 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 related data are accessed by the processor group 110 to control and direct the execution of the inventive method. In the computing environment 100, at least some of the instructions for performing the inventive method may be stored in the permanent storage device 113 in the box 150.

[0060] Communications fabric 111 is the signaling pathway that allows the various components of computer 101 to communicate with each other. Typically, the fabric is comprised of switches and conductive pathways, such as those that constitute a bus, a bridge, physical input / output ports, etc. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

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

[0062] Permanent storage 113 is any form of non-volatile memory for computers now known or developed in the future. The non-volatility of the storage device means that the stored data is retained regardless of whether power is supplied to the computer 101 and / or directly to the permanent storage device 113. Permanent storage 113 can be a read-only memory (ROM), but typically at least a portion of the permanent storage device allows the writing, deletion, and rewriting of data. Some common forms of permanent storage include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, such as various known proprietary operating systems or operating systems of the open source portable operating system interface type using a kernel. The code included in box 150 typically includes at least some computer code involved in executing the method of the present invention.

[0063] The peripheral device group 114 includes a collection 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 cables (such as universal serial bus (USB) type cables), plug-in connections (e.g., secure digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, the UI device group 123 can include components such as display screens, speakers, microphones, wearable devices (such as goggles and smart watches), keyboards, mice, printers, touchpads, game controllers, and tactile devices. The storage device 124 is an external storage device, such as an external hard drive, or a plug-in storage device, such as an SD card. The storage device 124 can be permanent and / or volatile. In some embodiments, the storage device 124 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where computer 101 requires a large amount of storage (e.g., where computer 101 locally stores and manages a large database), the 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 group 125 consists of sensors that can be used in IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.

[0064] The network module 115 is a collection of computer software, hardware, and firmware that allows the computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data transmitted over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are executed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control function and forwarding function of the network module 115 are executed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for executing the methods of the present invention can typically be downloaded to the computer 101 from an external computer or external storage device via a network adapter card or network interface included in the network module 115.

[0065] WAN 102 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology now known or developed in the future for transmitting computer data. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi network. A WAN and / or LAN typically includes computer hardware, such as copper transmission cables, fiber optic transmission, wireless transmission, 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 operating computer 101), and can take any of the forms discussed above in connection with computer 101. EUD 103 typically receives helpful and useful data from the operation of computer 101. For example, in the hypothetical scenario where computer 101 is designed to provide recommendations to an end-user, the recommendations can typically be transmitted from network module 115 of computer 101 to EUD 103 via WAN 102. In this way, EUD 103 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 can be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, or 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 helpful and useful data for use by other computers, such as computer 101. For example, if computer 101 is designed and programmed to provide recommendations based on historical data, then this historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0068] 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 capabilities, particularly data storage (cloud storage) and computing power, without requiring direct, active management by users. Cloud computing typically leverages the sharing of resources to achieve consistency and economies of scale. Direct and active management of the computing resources of public cloud 105 is performed by computer hardware and / or software of cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented as virtual computing environments running on various computers comprising host physical machine group 142, which is the universe of physical computers in public cloud 105 and / or physical computers available to public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine group 143 and / or containers from container group 144. It will be appreciated that these VCEs can be stored as images and transferred between and among 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 VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows public cloud 105 to communicate over WAN 102 .

[0069] Some further explanation of Virtualized Computing Environments (VCEs) will now be provided. A VCE can be stored as an "image." New, active instances of a VCE can be instantiated from an image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature where the kernel allows the existence of multiple isolated userspace instances, called containers. From the perspective of the programs running in them, these isolated userspace instances typically appear to be actual computers. Computer programs running on a normal operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running within a container may only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0070] 105 . Private cloud 106 is similar to public cloud 105 , except that the computing resources are only available to a single enterprise. Although private cloud 106 is depicted as communicating with 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 combination of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable coordination, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, public cloud 105 and private cloud 106 are both 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 rather than opaque authorization codes. This allows the authentication and authorization service to implement the security policy embedded in the ABE key using the ABE mechanism. Based on the established security policy, the authentication and authorization service can determine whether to generate and issue an ABE key to a third-party entity, which is hereafter assumed to be a user but can be any requesting entity, such as an application or a specific device. The ABE key is used to decrypt the locking metadata associated with the attribute values ​​to determine which attribute values ​​to include in the access token / ID token. The ABE key is submitted to the token issuance microservice along with the token request to obtain an access token and ID token whose attribute values ​​correspond to the attribute values ​​for which the locking metadata can be decrypted. The access token and ID token can then be used to request access to protected computing resources.

[0072] The exchange of messages for performing this ABE-based authentication and authorization involves various parties, including a requesting entity (e.g., a user), a relying party (e.g., an application that delegates authentication services to an authentication server), an authentication system, and a protected computing resource provider (e.g., a resource server, etc.). 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 executing on a user's computing device, etc.) may be provided as part of an end-user device 103, a relying party may be provided as part of a remote server 104 or other server computing device (not shown, but indicated by dashed lines), a distributed authentication system 150 may be part of computer 101 or distributed across multiple computing devices, and a protected computing resource provider may be provided as part of a remote server 104 or other server computing device and provide computing resources, such as hardware / software computing resources or data structures, such as database 130.

[0073] like Figure 1 As shown, one or more computing devices (e.g., computer 101 and / or remote server 104) can be specifically configured to implement a distributed authentication system 150, which can be distributed and have separate authentication and authorization microservices 152 and token issuance microservices 154. Configuration of the computing devices can include providing dedicated hardware, firmware, etc. to facilitate the execution of operations and generation of outputs described herein with respect to the illustrative embodiments. Configuration of the computing devices can also or alternatively include providing a software application 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 application, which configures the processors to perform operations and generate outputs as described herein with respect to the illustrative embodiments. Furthermore, any combination of dedicated hardware, firmware, software applications executed on hardware, etc. can be used without departing from the spirit and scope of the illustrative embodiments.

[0074] It will be appreciated that once a computing device is configured in one of these ways, the computing device becomes a dedicated computing device specifically configured to implement the mechanisms of the illustrative embodiments, rather than a general-purpose computing device. Furthermore, as described below, implementation of the mechanisms of the illustrative embodiments improves the functionality of the computing device and provides useful and specific results, facilitating the issuance of attribute-based encryption (ABE) key-based tokens for authenticating third-party entities to access protected computing resources, which supports the allocation of authentication and token issuance microservices and the obfuscation of security policies and attributes for authenticating third-party entities.

[0075] The data flow implemented and orchestrated by the distributed authentication system 150 will now be described, illustrating the improved computer functionality of the improved computing tool. To better understand this improved computer functionality, it is first helpful to understand the data flow of an OAuth2 / OIDC monolithic authentication server architecture in order to see the differences between this OAuth2 / OIDC architecture and the architecture of the illustrative embodiment.

[0076] Figure 2 2 is an example data flow diagram illustrating the operation of the OAuth2 / OIDC architecture. The architecture includes four main parties: user agent 210, relying party 220, authentication server 230, and resource server 240. User agent 210 is sometimes also referred to as a resource owner and can be an application user or end user that owns a protected computing resource. For example, if the protected computing resource is a data structure, the data structure stores data that is private to the resource owner, such as a user's profile. Resource owners can grant or deny access to protected computing resources they own. For example, an application can call an external system application programming interface (API) to obtain a user's personal information from a user profile. Profile data is protected computing resources 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, sometimes also referred to as a client, is an application that requests access to protected computing resources on resource server 240. For example, a client can be a web application running on a server, an application running in a web browser on a client computing device, a web API calling another web API, etc. Resource server 240 provides access to a resource owner's protected computing resources (e.g., protected data structures). Resource server 240 can be, for example, a web API or an application that provides an interface for accessing a data store (e.g., a database). Resource server 240 uses authorization server 230 to control access to protected computing resources by performing authentication of requests and providing security tokens to grant / deny access to these 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, which applications and APIs use to grant, deny, or revoke access to resources after the resource owner is authenticated and logged in. The 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 in conjunction with resource servers 240 to access protected computing resources. Access tokens include permissions granted by authorization server 230 to relying parties 220. ID tokens are issued by authorization server 230 to relying parties 220, who use these ID tokens to obtain information about logged-in users, such as user agents 210.

[0079] When registering with authentication server 230, user agent 210 is given a unique identifier, such as an application ID or client ID, which identifies user agent 210 to authentication server 230. In addition, authorization server 230 uses a redirection uniform resource identifier (URI) to direct user agent 210 to resource server 240 to complete access to protected computing resources.

[0080] like Figure 2 As shown, the operation begins with user agent 210 (e.g., an application executing on a computing device, such as a user's application, a web browser, a mobile application, etc.) sending a user login request to relying party 220 (step 1). It will be understood that references to "a party" or "parties" throughout this specification are intended to refer to the computing devices used by these parties, as data flows between the computing devices. Relying party 220 responds with an authentication redirect to user agent 210 (step 2). The user agent then submits the user login request to authentication server 230 (step 3), based on the authentication redirect that redirected user agent 210 to authentication server 230.

[0081] Authentication server 230 sends a challenge for the user's credentials to user agent 210 (step 4), which then responds with the user's credentials (step 5). Based on the user's credentials, authentication server 230 determines whether an authorization code should be issued to user agent 210. This determination can be based on a set of stored rules and a determination of whether the credentials submitted by user agent 210 satisfy these rules. If authentication server 230 generates (step 7) and issues an authorization code, authentication server 230 stores the authorization code as part of a mapping between attributes of user agent 210 (which may have been provided by the user when registering with authentication server 230) and the authorization code. For example, an attribute can be a username, phone number, email address, address, or any other data that can be asserted about an identity. Authentication server 230 must be able to map the authorization code it previously issued upon successful authentication back to the identity of the relying party when it exchanges the authorization code for a token. Thus, the authorization code is mapped to a set of attributes representing the identity. Authorization codes are typically single-use to prevent replay attacks.

[0082] Thus, authentication server 230 stores this mapping, and therefore, if an attacker compromises authentication server 230, the attacker can access the mapping and be able to spoof the identity of an authorized third-party entity (e.g., user agent 210) in order to gain access to protected computing resources. The authentication code is referred to herein as "opaque" because it is intended for specific 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 user) in order to be able to later authenticate the authentication code and provide an access token and ID token for accessing protected computing resources. The authentication code is also "opaque" because the structure of the token is determined on a provider-by-provider basis.

[0083] If authentication of user agent 210 is successful based on the user credentials, authentication server 230 sends a request to user agent 210 for resource access approval (step 6). Assuming that authentication server 230 successfully authenticates the user credentials, authentication server 230 generates an authorization code and stores it in a 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 can then perform its operations on the protected computing resources 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 is an identity layered on top of OAuth2, the ID token asserts claims about the individual. Accessing protected resources on third-party resource server 240 only requires the access token. The ID token is intended to be processed by relying party 220 so that relying party 220 can identify who it is requesting resources from. A real-world example of why this is necessary is if a first application wants to parse a user's messages in another, second application. The user can log in to the first application, which defers authentication to the second application. The second application can indicate that the first application is requesting to read the user's messages and request authorization for that 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 perhaps display the user's profile page), and the resource server for the second application uses the access token to read the user's messages.

[0086] like Figure 2 As shown, the authentication server 230 provides an overall authentication / authorization and token issuance server. Therefore, if this server is compromised, an attacker can gain access to the authorization codes, tokens, permissions, security rules, etc. used to access protected computing resources. Therefore, if the authentication server can be compromised, the attacker can gain access to protected computing resources.

[0087] Figure 3 is an example data flow diagram illustrating the operation of a distributed authentication system according to one exemplary embodiment. Figure 3 With Figure 2Similar parties and data flows are indicated by similar reference numerals and descriptive text labels. However, it is noteworthy that the authentication server 230 is replaced by a distributed authentication system 310 in which the authentication and authorization functions and the token issuance functions are distributed to an authentication and authorization microservice (AAM) 312 and a token issuance microservice 314, which can be implemented on different computing hardware and software of the same or different computing devices. The microservices 312 and 314 are distributed so that compromise of one microservice does not result in compromise of the other microservice, for example, the microservices do not share security policies or rules and attributes used by such policies and rules cannot be accessed from cryptographic objects and ABE keys. Although Figure 3 A microservices architecture and a distributed architecture are shown, but the illustrative embodiments are not limited thereto, and other architectures implementing the ABE key mechanism of the illustrative embodiments may be used without departing from the spirit and scope of the invention.

[0088] In addition to the distributed authentication system 310, Figure 3 The data flow shown in replaces the authorization code mechanism used in step 7 and thereafter with attribute-based encryption keys and corresponding operations based on ABE key operations, as will be discussed below. Figure 3 Steps 1 to 6 are the same as Figure 2 In addition, steps 12-13 for accessing protected computing resources on resource server 240 are similar to those of Figure 2 Steps 12-13 are similar.

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

[0090] AAM 312 implements ABE to provide an ABE key that replaces the opaque authorization code, e.g. Figure 2 The opaque authorization code used in step 7 of

[0066] is used so that the AAM 312 does not need to maintain a mapping between the authorization code and the attributes of the user or user agent 210. Instead, the mapping is embedded in the ABE mechanism, which issues ABE keys based on the attributes of the entity. The ABE keys are used to decrypt the locking metadata encrypted according to predefined security rules / policies, where the locking metadata is associated with the attributes to be placed in the access and / or ID token used to authenticate the parties such as the user agent 210. The ABE keys embed one or more authorization policies in the ABE keys themselves by the entity (or party) that has the ABE key to decrypt the corresponding locking metadata. That is, the ABE keys are issued to the authorized entity (party) based on its credentials and are associated with a specific set of attribute values ​​corresponding to these credentials. The ABE keys can only decrypt the locking metadata encrypted using predefined security rules / policies that specify the attribute criteria of the entity / party. That is, if an ABE key is used to decrypt the locking metadata, and the ABE key is an ABE key corresponding to an entity having attributes that meet the criteria of the security rules / policies corresponding to the locking metadata, then the ABE key will be able to decrypt the locking metadata, and the corresponding attribute values ​​will be included in the issued token.

[0091] The attributes used to generate an ABE key for each user can be different, giving each user different access to attribute-value pairs that can be added to tokens, such as access and / or ID tokens. This is the responsibility of AAM 312 and is assigned in step 7 as stated above. One attribute might be that the user is in department X and should only be allowed attribute-value pairs specific to department X. Similarly, another user might be in department Y and only get attribute-value pairs specific to that department added to the token. For some reason, another user might be in both departments X and Y and be given attribute-value pairs specific to both departments in the token. Providing different attributes to users during ABE key generation enables users to be granted a different set of attribute-value pairs for their tokens. This allows implementers to mix and match as they see fit and eliminates the need for 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] AAM 312 is provisioned by its owner, either manually or through an automated process, using a master ABE key for each computing resource owner. This master ABE key is used to generate ABE keys for individual user agents 210 requesting access to the computing resource owner's protected computing resources. It will be appreciated that each AAM 312 may be individually provisioned with a corresponding master key by its respective owner. The ABE key generated by AAM 312 is provided to the user agent 210 and redirected to the relying party 220. The user agent 210 submits an access request to the relying party 220 using the redirection URI and 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 by the token issuance microservice 314 to determine which attribute values ​​to include in the issued access token and / or ID token for use by the relying party 220 when authenticating the user agent 210 with the resource server 240.

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

[0094] Therefore, the ABE key is used to decrypt the lock metadata. If the attribute-value pair's associated lock metadata can be successfully decrypted using the ABE key, the attribute-value pair can be included in the access token and / or ID token generated by token issuance microservice 314 and sent back to relying party 220. In some demonstrative embodiments, the attribute-value pair itself can be encrypted, and the encrypted attribute-value pair can be considered as the lock metadata.

[0095] Access / ID tokens (also known as authentication tokens) can be generated using content that includes attribute-value pairs whose locking metadata can be successfully decrypted using an ABE key. Therefore, the token issuance microservice 314 does not need to maintain a mapping between authorization codes and attributes. Instead, the ABE mechanism itself can identify which attribute-value pairs to include in the authentication token(s) based on which attribute-value pair locking metadata has been decrypted. Therefore, neither the AAM 312 nor the token issuance microservice 314 maintains a mapping between 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 locking metadata associated with the attribute-value pairs to determine which attributes to include in the issued token. Therefore, even if an attacker is able to compromise one of the microservices 312 or 314 of the distributed authentication system 310, the attacker cannot obtain any mapping between credentials and ABE keys, ABE keys and attribute values, or ultimately access protected computing resources. Thus, by using the ABE key and mechanism to determine which attribute values ​​to include in the authentication token(s) (e.g., access token and ID token), rather than using opaque authorization codes that require the provider to maintain a mapping, the provider does not need to maintain and map attribute values ​​to authorization codes. Instead, the work of determining what attribute values ​​to include in the authentication token can be offloaded to the token issuance microservice 314, which does so automatically based on the ABE key and what locking metadata can be decrypted.

[0096] The ABE key-based authentication mechanism of the exemplary embodiment (e.g., AAM 312 and token issuance microservice 314) is capable of integrating authentication mechanisms such as Figure 2 The monolithic authentication server in 230 is separated into separate microservices 312 and 314, making it more difficult for attackers to compromise the authentication mechanisms provided by other microservices. AAM 312 is provisioned with a master ABE key and is used to issue ABE keys to requesters based on credential authentication according to predefined security policies or rules. The token issuance microservice 314 is again provisioned by its owner through a manual or automated process with the data and logic for issuing authentication tokens, such as access tokens and ID tokens, with attribute-value pairs determined based on decryption of the lock metadata using the ABE key.

[0097] In a first provisioning operation, the token issuance microservice 314 is provisioned with attributes to be included in the access token and ID token. Attributes can be stored as attribute-value pairs that can be associated with locking metadata, where the attributes can be JWT attributes and the values ​​can be any suitable values ​​for the corresponding attributes. Locking metadata can be any small encrypted data structure that embeds rules / policies within the encrypted data structure or ciphertext. The ability to decrypt the locking metadata proves that the ABE key includes one or more attribute values ​​that satisfy the rules / policies for adding attribute values ​​to the acquired access token and ID token. For example, because in some illustrative embodiments, the content of the metadata can be considered unrelated to the "locking" functionality used as part of the ABE key mechanism, the metadata can be any byte sequence. That is, as long as the ABE key can be used to decrypt the locking metadata, the fact that the decryption was successfully performed itself is an indicator that the corresponding attribute value should be included in the corresponding issued authentication token(s) (e.g., access token and / or ID token).

[0098] In some cases, the encrypted lock metadata may be an attribute value or attribute-value pair itself, rather than an arbitrary sequence of bytes as described above. After the token issuance microservice 314 attempts to decrypt the lock metadata, the contents of the lock metadata are discarded and are used only as access control for adding a key-value pair 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 pair encrypted in the ABE key is the attribute to be added to the token.

[0099] In a second provisioning operation, the AAM 312 is provisioned with the master ABE key. The master ABE key is provisioned on the AAM 312 so that it can generate ABE keys (see Figure 3 Step 7). As mentioned above, although Figure 3Only one AAM 312 is shown, but more than one AAM 312 may exist. Each AAM 312 can be associated with a different corresponding resource owner or resource owner's user agent and can operate in conjunction with a token issuance microservice 314, or a different pair of AAM 312 and token issuance microservice 314 can exist for each resource owner. Each resource owner can protect a master ABE key maintained at the corresponding AAM 312 according to its own security policy. Each resource owner can issue an ABE key via AAM 312, which is then used with the corresponding token issuance microservice 314 to issue an appropriate authentication token, such as an access token and / or ID token, with content corresponding to attribute-value pairs whose locking metadata can be decrypted using the ABE key. Each resource owner's token issuance security policy or rules can still be protected using appropriate encryption and the resource owner's attribute-value pairs, where this data can only be unlocked using the ABE key from the resource owner who possesses the locking metadata and the master ABE key. Because ABE keys are generated by different master ABE keys and possibly different AAMs 312, an ABE key issued by one resource owner cannot decrypt the locked metadata of other resource owners.

[0100] Assuming that the user agent provides authenticated credentials in step 5, and the corresponding AAM 312 generates an ABE key based on the resource owner's master ABE key (step 7), the ABE key is returned to the user agent 210 along with a redirection to the relying party (e.g., a redirect URI) (step 8). The user agent 210 uses the redirect URI to send the ABE key to the relying party 220 (step 9), which in turn sends a request for a token along with the ABE key to the token issuance microservice 314 (step 10). The token issuance microservice 314 uses the ABE key to attempt to decrypt the locking metadata for each attribute-value pair maintained in the token issuance microservice 314. For these attribute-value pairs whose locking metadata can be decrypted using the provided ABE key, the attribute-value pairs are included in the content of the returned authentication token(s) (e.g., access token and ID token) (step 11). The access token and ID token, with the attribute-value pairs whose locking metadata can be decrypted, are returned to the relying party 220 (step 11). Relying party 220 then performs a similar operation to that described in the preceding example by requesting access to protected computing resources and resource server 240 returning the requested computing resources. Figure 2Steps 12 and 13 are the same. The relying party's use of attribute-value pairs is specific to the resource server's implementation. For example, these attribute-value pairs can be used to determine whether a token is scoped for accessing a resource or any other functionality deemed appropriate by the resource server. Locking metadata can be created by the policy owner for a specific enterprise and provided to the token issuance microservice out-of-band.

[0101] In some illustrative embodiments, the ABE key sent from relying party 220 can also be replaced with ciphertext. In these illustrative embodiments, the locking metadata itself can be replaced with the ABE key of an entity whose attributes meet the requirements of the security rules / policies. Therefore, in these illustrative embodiments, the test becomes an attempt to decrypt the ciphertext using each ABE key associated with each attribute value, however, the overall mechanism described above is similar. If the ciphertext sent from relying party 220 to token issuance microservice 314 can be decrypted by the ABE key (locking metadata in this illustrative embodiment), the corresponding attribute-value pair can be added to the token(s) issued by token issuance microservice 314.

[0102] As previously described, in some demonstrative embodiments, an attribute name may point to an attribute value list, which may have accompanying locking metadata for testing which attribute value the attribute contains, or whether the attribute includes multiple values. That is, the ABE key may be used to decrypt one or more pieces of locking metadata in the attribute value list, and the corresponding attribute values ​​associated with the decrypted pieces of locking metadata may be included in the issued token. Figure 4 is an example diagram illustrating a property name / key to property value list data structure with corresponding locking metadata in accordance with one illustrative embodiment.

[0103] like Figure 4 As shown, 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, which has 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 locking metadata 430, which can be decrypted by a corresponding ABE key 440. It will be appreciated that in some implementations, any given locking metadata can be unlocked using multiple ABE keys. According to the ABE mechanism, the ABE key is only required to unlock the locking metadata with the correct attribute.

[0104] The security policy and master ABE key implemented by the AAM 312 cause the AAM 312 to issue ABE keys only to user agents 210 whose credentials satisfy the security policy / rules, where the issued ABE keys depend on specific attributes associated with the entity corresponding to the authenticated credentials. These ABE keys can be used to decrypt one or more locking metadata 430. The act of successfully decrypting the locking metadata 430 associated with a potential attribute value 420 causes the potential value to be included in the issued token(s) as part of an attribute name / key-value pair within the content of the issued token(s). This can be done for each attribute name / key 410, allowing multiple attribute name / key-value pairs to be included in the issued token(s), and in some cases, the same attribute name / key 410 can have multiple potential attribute values ​​420 included as a result of its locking metadata 430.

[0105] In some illustrative 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. Instead, potential attribute values ​​420 may be encrypted, or encrypted together with attribute name / key 410, to generate encrypted lock metadata 430. Therefore, if lock metadata 430 can be decrypted using ABE key 440, token issuance microservice 314 gains access to the decrypted attribute name / key-value pairs and can then add them to the issued token(s). Thus, unlike the illustrative embodiments in which encrypted lock metadata 430 is an arbitrary sequence of bytes, encrypted lock metadata 430 in these illustrative embodiments is an encrypted version of the attribute name / key-value pairs (attribute name / value), which has the advantage of hiding the attribute name / key and their values ​​from attackers who can penetrate token issuance microservice 314 of distributed authentication system 310.

[0106] As described above, the illustrative embodiments of the OAuth2 / OIDC architecture, which replaces the opaque authorization codes that require a specific mapping of attributes to authorization codes with an ABE key mechanism, offer the advantage of offloading token issuance from authentication and authorization services and functionality to a separate microservice, making it more difficult for attackers to gain access to protected computing resources. The illustrative embodiments also provide a mechanism for obfuscating security policies and rules by embedding them within the ABE key via the ABE mechanism, where the ABE mechanism only issues the ABE key to entities whose attributes satisfy the security policies and rules. In other words, if an attacker gains access to the ABE key, they will still be unable to determine the security policies and rules that led to the issuance of the ABE key. Furthermore, the illustrative embodiments obfuscate the attribute values ​​that can access computing resources by implementing locked metadata on attribute values ​​that can only be decrypted with the appropriate ABE key. Therefore, even if an attacker gains access to the token issuance microservice 314 without the appropriate ABE key (which is again issued only to entities with the correct attribute combination), the attacker cannot determine which attribute values ​​are authorized to access protected computing resources. Furthermore, when the token issuance microservice 314 decides what attribute name / key-value pair (e.g., claim) to add to the issued token, the token issuance microservice 314 simply attempts to decrypt the locking metadata associated with the underlying attribute value (claim), without requiring a complex database query to find the attribute, as in the case of an authentication code used by a monolithic authentication server.

[0107] I understand. Figure 3 The operational components of the distributed authentication system 310 shown may be implemented as dedicated computer hardware components, computer software executed on computer hardware (which is then configured to perform the specific computer operations attributed to the component), or any combination of dedicated computer hardware and computer hardware configured by computer software. It will be understood that these operational components automatically perform the attributed operations without human intervention. That is, even in Figure 3 While references to "user" are made herein, these merely refer to the entity being authenticated. The actual data messages sent between the depicted entities are automatically generated by the associated computing devices, as data messages are potentially generated and transmitted automatically in response to user input but are otherwise generated and transmitted automatically. The present invention is particularly directed to automated computer components that are directed to improving the manner in which entity authentication is performed, thereby improving the security of the authentication system and providing a specific solution to the aforementioned problem of monolithic authentication services. The improved computing tool mechanisms and improved computing tool functionality of the illustrative embodiments are not actually executable by humans as mental processes and are not directed to organizing any human activity.

[0108] Figure 5-6Flowcharts outlining example operations of elements of the present invention with respect to one or more illustrative embodiments are presented. It will be appreciated that Figure 5-6 The operations outlined in the foregoing are specifically performed automatically by the improved computer tools of the illustrative embodiments and are not intended to, and cannot in fact, be performed by humans as mental processes or through organized human activities. On the contrary, although humans may initiate Figure 5-6 and in some cases can be used as Figure 5-6 The result is the result of the operation described in Figure 5-6 The operations themselves are specifically performed in an automated manner by improved computing tools.

[0109] Figure 5 is a flow chart outlining the operation of the authentication and authorization microservice (AAM) according to one illustrative embodiment. Figure 5 As shown, the operation begins by receiving a login request, such as Figure 3 3 in step 510). The AAM challenges the user agent for the credentials of the entity specifying the entity requesting access to the computing resource (step 520). The received credentials are then authenticated based on the established security policies / rules to ensure that the credentials satisfy the security policies / rules for generating / issuing ABE keys 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 along with the generated ABE key (step 560). The user agent then performs the redirect to the relying party and provides the ABE key, e.g. Figure 3 Then, the operation terminates.

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

[0111] The description of the present invention is presented for the purpose of illustration and description and is not intended to be exhaustive or to limit the invention to the disclosed form. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The embodiments are selected and described in order to best explain the principles of the invention, practical applications, and to enable others of ordinary skill in the art to understand the various embodiments of the invention with various modifications that are suitable for the specific purposes contemplated. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements to existing technologies on the market, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

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

2. The method of claim 1 , further comprising issuing a logical provision attribute and a corresponding candidate attribute value to the token as an attribute-value pair, and wherein Each candidate attribute value of each attribute-value pair is associated with corresponding locking metadata.

3. The method according to claim 2, wherein: Publishing logical provisioning attributes and corresponding candidate attribute values ​​to the token includes: Storing multiple attribute names in an attribute-value data structure; In the attribute-value data structure, for each attribute name in the plurality of attribute names, a list of candidate attribute values ​​for the attribute name is stored; and In the attribute-value data structure, corresponding locking metadata is stored for each candidate attribute value in each candidate attribute value list of each attribute name, and the corresponding locking metadata is encrypted so that only the ABE key of the authorized user agent corresponding to the candidate attribute value can decrypt the corresponding locking metadata.

4. The method according to claim 1 , wherein The locking metadata is an arbitrary sequence of bytes that is encrypted such that a valid ABE key decrypts the locking metadata.

5. The method according to claim 1 , wherein The locking metadata is an attribute-value pair corresponding to the locking metadata, the attribute-value pair being encrypted such that a valid ABE key decrypts the locking metadata.

6. The method according to one of claims 1 to 5, further comprising supplying a plurality of master ABE keys to the authentication and authorization logic, wherein The ABE key is generated based on a corresponding master ABE key among the plurality of master ABE keys.

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

8. The method according to claim 1 , wherein: The ABE key is the ciphertext, each locking metadata associated with each attribute value of the at least one attribute value comprises a corresponding second ABE key, performing the decryption operation comprises attempting to decrypt the ciphertext of the ABE key using each locking metadata associated with each of the at least one attribute value, and Publishing the generated token includes generating the generated token by incorporating one or more of the at least one attribute value into the generated token in response to a corresponding second ABE key in the one or more attribute values ​​successfully decrypting the ciphertext.

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

10. The method according to claim 9, wherein: The token is a JavaScript Object Tag Web Token (JWT), and wherein the at least one attribute value includes at least one claim of the JWT.

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

12. The method according to one of claims 1 to 11, further comprising: issuing to the token a logical provisioning attribute and attribute value that are candidates for inclusion in the token as candidate attribute-value pairs; A master ABE key from which an ABE key is generated is supplied to the authentication and authorization logic, wherein issuing a 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 the subset of the candidate attribute-value pairs, and wherein the ABE key is generated based on the master ABE key.

13. A computer program product comprising a computer-readable storage medium having a computer-readable program stored therein, wherein When the computer readable program is executed in a data processing system, it causes the data processing system to: authenticating, by authentication and authorization logic of the data processing system, the credentials of the 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; generating, by the authentication and authorization logic in response to determining that the user agent is associated with the entity for which the ABE key is to be generated, the ABE key and providing the ABE key to the user agent, wherein the ABE key corresponds to a set of attributes of the entity; receiving, by token issuance logic of the data processing system, a token request and the ABE key from a relying party computing device; performing, by the token issuance logic, a decryption operation on locking metadata associated with at least one attribute value based on the ABE key; The token issuance logic issues a generated token to the relying party computing device based on the at least one attribute value in response to the decryption operation successfully decrypting the lock metadata, wherein the relying party computing device uses the generated token to access the computing resource.

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

15. The computer program product according to claim 13 or 14, wherein: Publishing logical provisioning attributes and corresponding candidate attribute values ​​to the token includes: Storing multiple attribute names in an attribute-value data structure; In the attribute-value data structure, for each attribute name in the plurality of attribute names, a list of candidate attribute values ​​for the attribute name is stored; and In the attribute-value data structure, corresponding locking metadata is stored for each candidate attribute value in each candidate attribute value list of each attribute name, and the corresponding locking metadata is encrypted so that only the ABE key of the authorized user agent corresponding to the candidate attribute value can decrypt the corresponding locking metadata.

16. The computer program product according to one of claims 13 to 15, wherein The locking metadata is an arbitrary sequence of bytes that is encrypted such that a valid ABE key decrypts the locking metadata.

17. The computer program product according to one of claims 13 to 16, wherein The locking metadata is an attribute-value pair corresponding to the locking metadata, the attribute-value pair being encrypted such that a valid ABE key decrypts the locking metadata.

18. The computer program product according to one of claims 13 to 17, wherein The computer-readable program further causes the data processing system to supply a plurality of master ABE keys to the authentication and authorization logic, wherein the ABE key is generated based on a corresponding master ABE key of the plurality of master ABE keys.

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

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

21. The computer program product according to one of claims 13 to 20, wherein Issuing the generated token includes generating the token at least by including the at least one attribute value in the token in response to the decryption operation being successful, and wherein the token is one of an access token or an ID token.

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

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

24. The computer program product according to one of claims 13 to 23, further comprising: issuing to the token a logical provisioning attribute and attribute value that are candidates for inclusion in the token as candidate attribute-value pairs; A master ABE key from which an ABE key is generated is supplied to the authentication and authorization logic, wherein issuing a 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 the subset of the candidate attribute-value pairs, and wherein the ABE key is generated based on the master ABE key.

25. An apparatus comprising: at least one processor; as well as at least one memory coupled to the at least one processor, wherein the at least one memory comprises instructions that, when executed by the at least one processor, cause the at least one processor to: authenticating, by authentication and authorization logic of the at least one processor, 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; generating, by the authentication and authorization logic in response to determining that the user agent is associated with the entity for which the ABE key is to be generated, the ABE key and providing the ABE key to the user agent, wherein the ABE key corresponds to a set of attributes of the entity; receiving, by token issuance logic of the at least one processor, a token request and the ABE key from a relying party computing device; performing, by the token issuance logic, a decryption operation on locking metadata associated with at least one attribute value based on the ABE key; The token issuance logic issues a generated token to the relying party computing device based on the at least one attribute value in response to the decryption operation successfully decrypting the lock metadata, wherein the relying party computing device uses the generated token to access the computing resource.

Images