PLUGGABLE AUTHORIZATION POLICIES

• US 20150089571A1
• Filed: 04/30/2014
• Published: 03/26/2015
• Est. Priority Date: 09/29/2011
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Srinivasan, Uppili, Sondhi, Ajay, Chu, Ching-Wen, Bhat, Shivaram, Evani, Venkata S.
• Granted Patent: US 9,544,294 B2
• Time in Patent Office: Days
• US Class Current: 726/1
• CPC Class Codes: G06F 2221/2103 Challenge-response
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/0815 providing single-sign-on or federations
• CPC Class Codes: H04L 63/0853 using an additional device, e.g. smartcard, SIM or a different communication terminal cryptographic mechanisms or cryptographic arrangements for entity authentication involving additional secure or trusted devices H04L9/3234
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources
• CPC Class Codes: H04L 63/102 Entity profiles
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227
• CPC Class Codes: H04L 63/205 involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved negotiation of communication capabilities H04L69/24
• CPC Class Codes: H04W 12/06 Authentication

Abstract

A framework, which conforms to the OAuth standard, involves a generic OAuth authorization server that can be used by multiple resource servers in order to ensure that access to resources stored on those resource servers is limited to access to which the resource owner consents. Each resource server registers, with the OAuth authorization server, metadata for that resource server, indicating scopes that are recognized by the resource server. The OAuth authorization server refers to this metadata when requesting consent from a resource owner on behalf of a client application, so that the consent will be of an appropriate scope. The OAuth authorization server refers to this metadata when constructing an access token to provide to the client application for use in accessing the resources on the resource server. The OAuth authorization server uses this metadata to map issued access tokens to the scopes to which those access tokens grant access.

Claims

1. A computer-implemented method comprising:

storing, by a resource server, a first mapping between a first authorization policy and a first identity domain of a plurality of identity domains;

receiving, at an OAuth authorization server, a first token request from a first client application contained in the first identity domain;

in response to receiving the first token request, determining, based on the first mapping, that the first authorization policy is associated with the first identity domain in which the first client application is contained;

in response to determining based on the first mapping that the first authorization policy is associated with the first identity domain, the OAuth authorization server producing first scope of access information determined based on the first authorization policy; and

sending, from the OAuth authorization server to the first client application, a first token that specifies the first scope of access information.

2. The computer-implemented method of claim 1, wherein producing the first scope of access information determined based on the first authorization policy comprises:

requesting, by the OAuth authorization server, the first scope of access information from the resource server;

determining, at the resource server, based on the first mapping, that the first identity domain is mapped to the first authorization policy;

in response to determining based on the first mapping that the first identity domain is mapped to the first authorization policy, applying, at the resource server, the first authorization policy to attributes of the first client application to produce the first scope of access information; and

sending the first scope of access information from the resource server to the OAuth authorization server in response to said requesting.

3. The computer-implemented method of claim 1, further comprising:

storing, by the resource server, a second mapping between a second authorization policy and a second identity domain of a plurality of identity domains;

receiving, at the OAuth authorization server, a second token request from a second client application contained in the second identity domain;

in response to receiving the second token request, the OAuth authorization server requesting second scope of access information from the resource server;

determining, at the resource server, based on the second mapping, that the second identity domain, in which the second client application is contained, is mapped to the second authorization policy;

in response to determining based on the second mapping that the second identity domain is mapped to the second authorization policy, applying, at the resource server, the second authorization policy to attributes of the second client application to produce the second scope of access information;

sending the second scope of access information from the resource server to the OAuth authorization server in response to said requesting; and

sending, from the OAuth authorization server to the second client application, a second token that specifies the second scope of access information;

wherein the second authorization policy differs from the first authorization policy.

4. The computer-implemented method of claim 1, further comprising:

receiving, at the OAuth authorization server, a second token request from a second client application contained in the first identity domain;

in response to receiving the second token request, the OAuth authorization server requesting second scope of access information from the resource server;

determining, at the resource server, based on the first mapping, that the first identity domain, in which the second client application is contained, is mapped to the first authorization policy;

in response to determining based on the first mapping that the first identity domain is mapped to the first authorization policy, applying, at the resource server, the first authorization policy to attributes of the second client application to produce the second scope of access information;

sending the second scope of access information from the resource server to the OAuth authorization server in response to said requesting; and

sending, from the OAuth authorization server to the second client application, a second token that specifies the second scope of access information;

wherein the second client application is separate from the first client application; and

wherein the second scope of access information differs from the first scope of access information.

5. The computer-implemented method of claim 1, further comprising:

receiving, at the OAuth authorization server, a configuration that specifies a set of user attributes;

storing the configuration at the OAuth authorization server;

retrieving, from a user identity repository, in response to the first token request, values of the user attributes that are specified in the configuration; and

inserting the values of the user attributes into the first token prior to sending the first token to the first client application.

6. The computer-implemented method of claim 1, further comprising:

receiving, at the OAuth authorization server, a first uniform resource locator (URL) for a first plug-in that is designed to access a user identity repository of a first type;

storing, at the OAuth authorization server, a second mapping between a first type of client application and the first URL;

receiving, at the OAuth authorization server, a second uniform resource locator (URL) for a second plug-in that is designed to access a user repository of a second type that differs from the first type;

storing, at the OAuth authorization server, a third mapping between a second type of client application and the second URL;

receiving, at the OAuth authorization server, an authentication request from a particular client application of a particular type;

in response to receiving the authentication request, selecting, from among the first URL and the second URL, a particular URL that is mapped, in either the second mapping or the third mapping, to the particular type; and

forwarding the authentication request from the OAuth authorization server to a particular plug-in that is located at the particular URL.

7. A computer-readable memory comprising instructions which, when executed by one or more processors, cause the one or more processors to perform:

storing, by a resource server, a first mapping between a first authorization policy and a first identity domain of a plurality of identity domains;

receiving, at an OAuth authorization server, a first token request from a first client application contained in the first identity domain;

in response to receiving the first token request, determining, based on the first mapping, that the first authorization policy is associated with the first identity domain in which the first client application is contained;

in response to determining based on the first mapping that the first authorization policy is associated with the first identity domain, the OAuth authorization server producing first scope of access information determined based on the first authorization policy; and

sending, from the OAuth authorization server to the first client application, a first token that specifies the first scope of access information.

8. The computer-readable memory of claim 7, wherein producing the first scope of access information determined based on the first authorization policy comprises:

requesting, by the OAuth authorization server, the first scope of access information from the resource server;

determining, at the resource server, based on the first mapping, that the first identity domain is mapped to the first authorization policy;

in response to determining based on the first mapping that the first identity domain is mapped to the first authorization policy, applying, at the resource server, the first authorization policy to attributes of the first client application to produce the first scope of access information; and

sending the first scope of access information from the resource server to the OAuth authorization server in response to said requesting.

9. The computer-readable memory of claim 7, wherein the instructions, when executed by the one or more processors, cause the one or more processors to perform:

storing, by the resource server, a second mapping between a second authorization policy and a second identity domain of a plurality of identity domains;

receiving, at the OAuth authorization server, a second token request from a second client application contained in the second identity domain;

in response to receiving the second token request, the OAuth authorization server requesting second scope of access information from the resource server;

determining, at the resource server, based on the second mapping, that the second identity domain, in which the second client application is contained, is mapped to the second authorization policy;

in response to determining based on the second mapping that the second identity domain is mapped to the second authorization policy, applying, at the resource server, the second authorization policy to attributes of the second client application to produce the second scope of access information;

sending the second scope of access information from the resource server to the OAuth authorization server in response to said requesting; and

sending, from the OAuth authorization server to the second client application, a second token that specifies the second scope of access information;

wherein the second authorization policy differs from the first authorization policy.

10. The computer-readable memory of claim 7, wherein the instructions, when executed by the one or more processors, cause the one or more processors to perform:

receiving, at the OAuth authorization server, a second token request from a second client application contained in the first identity domain;

in response to receiving the second token request, the OAuth authorization server requesting second scope of access information from the resource server;

determining, at the resource server, based on the first mapping, that the first identity domain, in which the second client application is contained, is mapped to the first authorization policy;

in response to determining based on the first mapping that the first identity domain is mapped to the first authorization policy, applying, at the resource server, the first authorization policy to attributes of the second client application to produce the second scope of access information;

sending the second scope of access information from the resource server to the OAuth authorization server in response to said requesting; and

sending, from the OAuth authorization server to the second client application, a second token that specifies the second scope of access information;

wherein the second client application is separate from the first client application; and

wherein the second scope of access information differs from the first scope of access information.

11. The computer-readable memory of claim 7, wherein the instructions, when executed by the one or more processors, cause the one or more processors to perform:

receiving, at the OAuth authorization server, a configuration that specifies a set of user attributes;

storing the configuration at the OAuth authorization server;

retrieving, from a user identity repository, in response to the first token request, values of the user attributes that are specified in the configuration; and

inserting the values of the user attributes into the first token prior to sending the first token to the first client application.

12. The computer-readable memory of claim 7, wherein the instructions, when executed by the one or more processors, cause the one or more processors to perform:

receiving, at the OAuth authorization server, a first uniform resource locator (URL) for a first plug-in that is designed to access a user identity repository of a first type;

storing, at the OAuth authorization server, a second mapping between a first type of client application and the first URL;

receiving, at the OAuth authorization server, a second uniform resource locator (URL) for a second plug-in that is designed to access a user repository of a second type that differs from the first type;

storing, at the OAuth authorization server, a third mapping between a second type of client application and the second URL;

receiving, at the OAuth authorization server, an authentication request from a particular client application of a particular type;

in response to receiving the authentication request, selecting, from among the first URL and the second URL, a particular URL that is mapped, in either the second mapping or the third mapping, to the particular type; and

forwarding the authentication request from the OAuth authorization server to a particular plug-in that is located at the particular URL.

13. A system comprising:

a first machine that stores a resource server that is configured to store a first mapping between a first authorization policy and a first identity domain of a plurality of identity domains;

a second machine that stores a first client application contained in the first identity domain; and

a third machine that stores an OAuth authorization server that is configured to;

receive a first token request from the first client application;

determine, in response to receiving the first token request, and based on the first mapping, that the first authorization policy is associated with the first identity domain in which the first client application is contained;

produce, in response to determining based on the first mapping that the first authorization policy is associated with the first identity domain, first scope of access information determined based on the first authorization policy; and

send, to the first client application, a first token that specifies the first scope of access information.

14. The system of claim 13, wherein, to produce the first scope of access information determined based on the first authorization policy, the OAuth authorization server is configured to request the first scope of access information from the resource server, and the resource server is configured to:

determine, based on the first mapping, that the first identity domain is mapped to the first authorization policy;

apply, in response to determining based on the first mapping that the first identity domain is mapped to the first authorization policy, the first authorization policy to attributes of the first client application to produce the first scope of access information; and

send the first scope of access information to the OAuth authorization server.

15. The system of claim 13, wherein the system comprises a fourth machine that stores a second client application contained in a second identity domain of the plurality of identity domains;

wherein the OAuth authorization server is configured to receive a second token request from the second client application and to request, in response to receiving the second token request, second scope of access information from the resource server; and

wherein the resource server is configured to;

store a second mapping between a second authorization policy and the second identity domain;

determine, based on the second mapping, that the second identity domain, in which the second client application is contained, is mapped to the second authorization policy;

apply, in response to determining based on the second mapping that the second identity domain is mapped to the second authorization policy, the second authorization policy to attributes of the second client application to produce the second scope of access information; and

send the second scope of access information to the OAuth authorization server;

wherein the second authorization policy differs from the first authorization policy.

16. The system of claim 13, wherein the system comprises a fourth machine that stores a second client application contained in the first identity domain;

wherein the OAuth authorization server is configured to receive a second token request from the second client application and to request, in response to receiving the second token request, second scope of access information from the resource server; and

wherein the resource server is configured to;

determine, based on the first mapping, that the first identity domain, in which the second client application is contained, is mapped to the first authorization policy;

apply, in response to determining based on the first mapping that the first identity domain is mapped to the first authorization policy, the first authorization policy to attributes of the second client application to produce the second scope of access information; and

send the second scope of access information to the OAuth authorization server;

wherein the second client application is separate from the first client application; and

wherein the second scope of access information differs from the first scope of access information.

17. The system of claim 13, wherein the OAuth authorization server is configured to:

receive a configuration that specifies a set of user attributes;

store the configuration;

retrieve, from a user identity repository, in response to the first token request, values of the user attributes that are specified in the configuration; and

insert the values of the user attributes into the first token prior to sending the first token to the first client application.

18. The system of claim 13, wherein the system comprises a fourth machine that stores a first plug-in that is designed to access a user identity repository of a first type;

wherein the system comprises a fifth machine that stores a second plug-in that is designed to access a user identity repository of a second type that differs from the first type; and

wherein the OAuth authorization server is configured to;

receive a first uniform resource locator (URL) for the first plug-in;

store a second mapping between a first type of client application and the first URL;

receive a second uniform resource locator (URL) for the second plug-in;

store a third mapping between a second type of client application and the second URL;

receive an authentication request from a particular client application of a particular type;

select, in response to receiving the authentication request, and from among the first URL and the second URL, a particular URL that is mapped, in either the second mapping or the third mapping, to the particular type; and

forward the authentication request from the OAuth authorization server to a particular plug-in that is located at the particular URL.