ENVIRONMENTAL ATTRIBUTE ENCODING FOR AUTHORIZATION PROTOCOLS

A computer-implemented method, in accordance with one embodiment, includes receiving, by a token service, an Attribute Based Encryption (ABE) authorization code having environmental attributes encoded therein. At least one test is performed, by the token service, on the ABE authorization code using ABE decryption for determining whether the ABE authorization code satisfies a predefined policy that is based on the environmental attributes. In response to determining that the ABE authorization code satisfies the predefined policy, a token is issued by the token service.

BACKGROUND

The present invention relates to authorization systems, and more specifically, this invention relates to using Attribute-Based Encryption (ABE) as a mechanism of encoding attributes required for ensuring an access policy or constraint is satisfied within a token and/or an authorization code itself.

Some types of authorization protocols allow users to authorize access to data they own on one site to third party sites for data processing use cases. Illustrative use cases range from printing photos the user stores in the cloud to running analytics against data stored in data lakes to logging into an online service. There is no limit on the number of potential data processing use cases.

ABE is a mechanism in which keys and cipher text are dependent upon attributes.

Open Authorization 2.0 (OAuth2) is an authorization protocol. For example, the standard defined by OAuth2 defines a procedure by which a website or application can access resources hosted by other web applications on behalf of a user. Moreover, while the Internet is the main platform for OAuth2, the delegated access provided by OAuth2 is also applicable to other client types such as browser-based applications, server-side web applications, native/mobile apps, connected devices, etc.

Similarly, Open ID Connect (OIDC) is an identity layer on top of OAuth2. OAuth2 deals with delegated authorization, while OIDC deals with delegated authentication, but both use similar toolsets.

SUMMARY

A computer-implemented method, in accordance with one embodiment, includes receiving, by a token service, an Attribute Based Encryption (ABE) authorization code having environmental attributes encoded therein. At least one test is performed, by the token service, on the ABE authorization code using ABE decryption for determining whether the ABE authorization code satisfies a predefined policy that is based on the environmental attributes. In response to determining that the ABE authorization code satisfies the predefined policy, a token is issued by the token service.

A computer-implemented method, in accordance with one embodiment, includes receiving, by a computer, an ABE token having environmental attributes encoded therein. At least one test is performed, by the computer, on the ABE token using ABE decryption for determining whether the ABE token satisfies a predefined policy that is based on the environmental attributes. In response to determining that the ABE token satisfies the predefined policy, the ABE token is authenticated. In response to authenticating the ABE token, an action is performed using the token.

DETAILED DESCRIPTION

The following description discloses several preferred embodiments of systems, methods and computer program products for using ABE as a mechanism of encoding attributes required for ensuring an access policy or constraint is satisfied within a token and/or an authorization code.

In one general embodiment, a computer-implemented method includes receiving, by a token service, an Attribute Based Encryption (ABE) authorization code having environmental attributes encoded therein. At least one test is performed, by the token service, on the ABE authorization code using ABE decryption for determining whether the ABE authorization code satisfies a predefined policy that is based on the environmental attributes. In response to determining that the ABE authorization code satisfies the predefined policy, a token is issued by the token service.

In another general embodiment, a computer-implemented method includes receiving, by a computer, an ABE token having environmental attributes encoded therein. At least one test is performed, by the computer, on the ABE token using ABE decryption for determining whether the ABE token satisfies a predefined policy that is based on the environmental attributes. In response to determining that the ABE token satisfies the predefined policy, the ABE token is authenticated. In response to authenticating the ABE token, an action is performed using the token.

As noted above, some types of authorization protocols such as OAuth2 allow users to authorize access to data they own on one site to third party sites for data processing use cases. Illustrative use cases range from printing photos the user stores in the cloud to running analytics against data stored in data lakes. There is no limit on the number of potential data processing use cases.

ABE is a mechanism in which keys and cipher text are dependent upon attributes.

Client applications, resource servers, service providers, etc. need a way to identify how and where tokens and authorization codes were generated within an authorization protocol such as OAuth2. For example, this may be needed to satisfy custom access policies, or perhaps regulations from a nation-state. These entities need a secure mechanism to encode, or otherwise map, information needed to ensure policies are satisfied via a well-defined mechanism that can be applied to other use cases. For example, assume an enterprise has a rule set defining which users can access which data, whether there are certain encryption policies that need to be applied, whether multi factor authentication is to be used, etc. It would be desirable to have a way to encode or describe information about the pertinent policy information or rule set in the tokens or authorization codes that are passed around in these frameworks.

The present disclosure describes a methodology that uses ABE as the mechanism of encoding attributes required for ensuring access policies or constraints in an authorization scheme are satisfied within the token or authorization code itself. Such methodology may be used to improve a particular flow in OAuth2, namely the authorization code grant flow.

The following terms are used herein.Client application/service provider: Application requesting data access on behalf of a user or provider that relies on delegated access/authentication.Resource server: Host that controls user resources.Authorization code service (ACS): Entity issuing authorization codes.Token service (TS): Entity issuing tokens.

One goal of the methodology presented herein is to modify an authorization code flow, and/or other flows in which tokens are issued, such that either or both of the authorization code and issued token(s) act as an ABE key or keys. In some embodiments, these ABE keys are constructed in a way such that the location of issuance (e.g., as determined by GPS data, subnet, IP address, data center, rack, etc.) and/or location of valid use is encoded within the key.

Thus, for example, a TS or resource server can determine location of other parties based on the ABE authorization code. Moreover, other environmental attributes regarding parties can be encoded into the ABE authorization code.

One benefit of this approach is that the cryptographic material provides proof that an OAuth2 authorization code was either issued to/from a specific environment, where the environment may be characterized by any network attribute or physical attribute.

Another benefit of this approach is that the cryptographic material provides proof a token was issued to or from a specific environment, where the environment can be defined as any network attribute or physical attribute.

In addition, these materials may provide evidence that controls are met according to regulations within governments or private enterprises.

Either or both of the known methods of ABE may be adapted for use to implement various aspects of the present invention. The two methods are key-policy attribute-based encryption (KP-ABE) and ciphertext-policy attribute-based encryption (CP-ABE).

Now referring toFIG.2, a flowchart of a method200is shown according to one embodiment. The method200may be performed in accordance with the present invention in any of the environments depicted inFIG.1, among others, in various embodiments. Of course, more or fewer operations than those specifically described inFIG.2may be included in method200, as would be understood by one of skill in the art upon reading the present descriptions.

As shown inFIG.2, method200may initiate with operation202, in which an ABE authorization code having environmental attributes encoded therein is received by a TS. The ABE authorization code may act as an ABE key that is constructed in a way such that characteristics such as the location of issuance (e.g., as determined by GPS data, subnet, IP address, data center, rack, etc.) and/or location of valid use is encoded within the ABE key.

The ABE authorization code may be created using conventional ABE techniques adapted according to the teachings herein. For example, a conventional authorization code may be encrypted using an ABE key (e.g., a user's private key, a public key corresponding to the user's private key) to encode the environmental attributes into a resulting ABE authorization code. More information about key generation and use is provided below. In one approach, the environmental attributes may be encoded into the ABE key, and thus the ABE authorization code has the environmental attributes encoded therein by virtue of encryption using the ABE key.

In one embodiment, the ABE authorization code is in the form of an ABE key. In such aspect, performing the at least one test includes attempting to decrypt an “encrypted blob” corresponding to the policy using the ABE key. An encrypted blob may be any data object that is associated with a policy, and which can be unencrypted via ABE decryption using the ABE authorization code also corresponding to that policy.

Note that the TS may have many encrypted blobs, each blob being associated a respective policy. The ABE authorization code will only unlock a blob associated with the same policy as the ABE authorization code. Thus, a TS having blobs for many policies, upon receiving an ABE key, may attempt to sequentially decrypt each blob until a successful decryption is achieved. This may be conceptually thought of as “one key, many doors.” Upon successful decryption, the TS knows which policy the ABE authorization code pertains to, and may issue a corresponding token.

In another embodiment, the ABE authorization code is in the form of ciphertext. In such approach, performing the at least one test includes attempting to decrypt the ciphertext using an ABE key corresponding to the policy. The TS in such approach may have many ABE keys, e.g., one per policy. This may be conceptually thought of as “many keys, one door.”

An environmental attribute may be characterized as any network attribute or physical attribute. Any environmental attributes that would become apparent to unskilled in the art after reading present disclosure may be used. A nonexhaustive list of exemplary environmental attributes include attributes corresponding to: Operating System (OS), user agent, Global Positioning System (GPS) coordinates, time and/or date, encryption algorithm availability, browser information, subnet information, and Federal Information Processing Standards (FIPS) compliance information.

In some embodiments, the environmental attributes identify where and/or how the ABE authorization code was generated.

In other embodiments, the environmental attributes identify where the ABE authorization code is issued to, e.g., to verify that the destination of the ABE authorization code is proper.

FIG.3depicts a system300for enabling creation of ABE authorization codes and/or ABE tokens, in accordance with one embodiment. As an option, the present system,300may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such system300and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the system300presented herein may be used in any desired environment.

ABE allows for encoding of attributes (defined by policies) within the key and resulting ciphertext.

As shown inFIG.3, a central authority302may provide key(s), such as a public key (encryption key) and a private key pair created using a master key304. When using ABE encryption, the same master key304may be used to create multiple pairs of keys, where each pair of keys is generated based on a unique set of attributes. Those attributes are then encoded into the public key and the private key. The private key is typically provided to the user306. The public key may be provided to the TS, ACS, or both (collectively shown as a Data Owner308inFIG.3).

Thus, the central authority302provisions the pertinent content, and then distributes the key pair to parties that satisfy those attributes. One party can be sure that the other party has the proper attributes, and vice versa, because, when an item is encrypted using the public key, and then a recipient of the encrypted item wants to decrypt that item, the private key held by the recipient has the necessary attributes to perform the decryption. Likewise, the private key holder who is doing the decryption can be sure that the possessor of the public key who encrypted the item had the public key to encrypt the item.

As noted above, the ACS creates codes for the authorization code grant flow, while the TS mints tokens. The ACS and TS can be separate services or a single service serving dual functions.

Consider the illustrative case where an OAuth2 Authorization Server (AS) are sufficiently de-composed into separate services, including a TS and an ACS. Either the TS or ACS (or both) can act as the trusted authority of ABE and provision keys with the master key304. The TS and ACS can also operate independently. Note a level of trust may be established between the TS, ACS, and relying party (e.g., a client application).

In alternate embodiments, the TS, ACS, (or both), or a 3rd party (not shown) can act as the ABE central authority.

Referring again toFIG.2, in operation204, at least one test is performed on the ABE authorization code using ABE decryption for determining whether the ABE authorization code satisfies a predefined policy that is based on environmental attributes.

Known ABE decryption techniques may be used to extract the environmental attributes from the ABE authorization code.

The policy may specify, for example, which environmental attributes must be in the ABE authorization code in order for the ABE authorization code, or underlying authorization code, to allow further processing and/or use of the authorization code, e.g., to allow exchange of the authorization code for a token.

Note that other attributes may be required for successful decryption and/or authorization, such as user agent, OS or platform identification, availability of certain encryption algorithms, and/or time of day/date.

In operation206, in response to determining that the ABE authorization code satisfies the predefined policy, the TS issues a token.

In some embodiments, the token that is issued is a conventional token.

In other embodiments, the token that is issued is an ABE token having second environmental attributes encoded therein. Such second environmental attributes may be any type of environmental attributes, e.g., similar to those described elsewhere herein. For example, the second environmental attributes may correspond to the TS; a destination of the ABE token, e.g., the client or relying party that will receive the issued ABE token; etc. See, e.g.,FIG.5and related description for exemplary use of an ABE token.

In OAuth2, tokens are issued, for example, to client applications that represent an access grant or authentication event.

In an illustrative embodiment, the ACS can provision ABE keys, and thus, the ACS can also choose to issue authorization codes that are the ABE keys. These are known as ABE authorization codes. The TS may be provisioned with a set of valid locations as encrypted blobs for both ACS and OAuth2 Relying Parties. The ACS may be configured to issue an ABE authorization code with both location attributes of itself (e.g., based on public IP address or some other metadata like GPS data) and location attributes of the relying party (e.g., based on public IP address or some other metadata like GPS data). The TS, when it receives an ABE code is in turn able to test each set of blobs to validate the code was issued by the ACS and to the Relying Party without any additional introspection of the network. One benefit of this approach is that the TS is then able to handle codes from one or more ACS instances (thereby enabling an increase in scale) and the authorization code itself is able to act as proof it was issued by one of the valid and trusted ACS instances.

FIG.4depicts a system400for using ABE authorization codes, in accordance with one embodiment. As an option, the present system,400may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such system400and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the system400presented herein may be used in any desired environment.

In the exemplary system400shown, an ACS402sends an ABE authorization code, which may be in the form of an ABE key or ciphertext to a relying party404. The relying party404sends the ABE authorization code to the TS406with a request for a token. The TS406performs the aforementioned test on the ABE authorization code using ABE decryption. If the ABE authorization code passes the decryption tests, a token is issued and returned to the relying party.

Authorization code formats may be defined by the ACS. In this illustrative ABE scheme, the authorization code can be an ABE key or ciphertext. Required metadata attributes describing ACS are encoded with key/ciphertext.

The TS contains a policy for any set of environmental attributes/rules that must be satisfied before exchanging the authorization code for a token (e.g., IP address range, user-agent, time of day, etc.). For example, the TS may store one encrypted blob per policy if the authorization code is ABE key (one key, many doors), for many policies. Moreover, if the authorization code is cyphertext, the TS may store one decryption key per policy (one door, many keys), for many policies.

Note that the authorization code, because it is passed from the ACS to the relying party to the TS, may also contain metadata of the relying party. Moreover, the token may also have such attributes (or a different set) embedded therein.

The TS406performs the aforementioned decryption test on the ABE authorization code using ABE decryption for each policy. If code is an ABE key, it is tested against each encrypted blob. If the authorization code is ciphertext, it is tested against each key. If the authorization code passes a test, the TS, via ABE, has cryptographically verified metadata about other parties involved in the token exchange. This in turn reduces difficulty of one TS having many ACS (or vice versa) because the policy if self-contained in code.

Now referring toFIG.5, a flowchart of a method500is shown according to one embodiment. The method500may be performed in accordance with the present invention in any of the environments depicted inFIGS.1-4, among others, in various embodiments. Of course, more or fewer operations than those specifically described inFIG.5may be included in method500, as would be understood by one of skill in the art upon reading the present descriptions.

As shown inFIG.5, method500may initiate with operation502, where an ABE token having environmental attributes encoded therein is received. The environmental attributes may be as described elsewhere herein. For example, in one embodiment, the environmental attributes identify where and/or how the ABE token was generated. In another embodiment, the environmental attributes encoded in the ABE token correspond to environmental attributes of the token service that issued the ABE token. In yet another embodiment, the environmental attributes encoded in the ABE token correspond to a destination of the ABE token, e.g., the location or other characteristic of an entity that will receive and use the ABE token for some purpose such as the client or relying party that will receive the issued ABE token.

In operation504, at least one test is performed on the ABE token using ABE decryption. Decryption tests similar to those listed above in the method200for using ABE authorization codes may be used in operation504to test the ABE token. The test determines whether the ABE token satisfies a predefined policy that is based on the environmental attributes. The predefined policy may be similar to, and/or have a similar purpose as, other predefined policies listed herein, but for use with the ABE token.

In operation506, in response to determining that the ABE token meets the predefined policy, the ABE token is authenticated.

In operation508, in response to authenticating the ABE token, an action is performed using the token. Any action that would become apparent to one skilled in the art after reading the present disclosure may be performed. For example, if the relying party is the entity authenticating the ABE token, the relying party may forward the ABE token to a resource server to access the desired data. Likewise, if a resource server is the entity authenticating the ABE token, the resource server may grant the access requested in conjunction with the ABE token if the ABE token is deemed to be authentic.

In one embodiment, the action includes forwarding the ABE token to a resource server with a request to access desired data from the resource server. In another embodiment, the action includes providing, by a resource server, access to desired data.

In one exemplary embodiment, consider the case where the TS is capable of provisioning ABE keys. The TS can choose to issue opaque access tokens that are also ABE Keys. The ABE access tokens may contain the encoded location of the intended audiences (e.g., relying party or resource server(s)). For example, when a resource server receives an OAuth2 ABE access token, it could test a set of encrypted blobs that represent its expected relying parties and/or itself.

In yet another aspect of the present invention, it is possible to issue an authorization code that is also ABE cipher text. In this approach, the TS and/or resource server are preferably provisioned with a set of valid ABE keys for the tests, e.g., the tests performed in operations204and504above. SeeFIGS.2and5. The overall mechanics of this aspect are essentially the same as those described above.

FIG.6depicts a system600for using ABE tokens, in accordance with one embodiment. As an option, the present system,600may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such system600and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the system600presented herein may be used in any desired environment.

In the exemplary system600shown, a TS602sends an ABE token, which may be in the form of an ABE key or ciphertext, to a relying party604. The relying party404may perform encryption test on the ABE token, e.g., in a manner similar to the testing described elsewhere herein for ABE authorization codes and ABE tokens. Preferably, if the ABE token passes the test at the relying party, the relying party may send the ABE token to a resource server606with a request for the desired resource. The resource server606may also perform decryption tests on the ABE token. If the ABE token passes a test at the resource server606, the requested resource is made available.

In other approaches, the relying party may simply pass the ABE token on to the resource server, e.g., only the resource server performs the decryption testing. In further approaches, the relying party performs the decryption testing on the ABE token and the resource server does not perform decryption testing.