Enterprise service-to-service trust framework

• US 20070118878A1
• Filed: 03/22/2006
• Published: 05/24/2007
• Est. Priority Date: 11/22/2005
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Shrivastava, Saurabh, Lee, Stephen, Sastry, Hari, Ng, Raymond, Turlapati, Romana
• Granted Patent: US 7,721,322 B2
• Time in Patent Office: Days
• US Class Current: 726/3
• CPC Class Codes: G06F 21/33 using certificates
• CPC Class Codes: H04L 63/105 Multiple levels of security

Abstract

Embodiments of the invention provide a trust framework for governing service-to-service interactions. This trust framework can provide enhanced security and/or manageability over prior systems. Merely by way of example, in some cases, an information store can be used to store information security information (such as trust information, credentials, etc.) for a variety of services across an enterprise. In other cases, the trust framework can provide authentication policies to define and/or control authentication between services (such as, for example, types of authentication credentials and/or protocols are required to access a particular service—either as a user and/or as another service—and/or types of authentication credentials and/or protocols a service may be enabled to use to access another service). Alternatively and/or additionally, the trust framework can provide authorization policies to define and/or control authorization between services.

Claims

1. In an enterprise computing network, a system for providing authorization and authentication in response to a service request from a client computer, the system comprising:

a centralized policy server comprising a centralized policy repository, the centralized policy repository comprising;

(a) an information store configured to store a plurality of sets of trust information, each of the plurality of sets of trust information comprising trust information about one of a plurality of services;

(b) one or more authorization models, each of the one or more authorization models comprising information about a mode of interaction between two or more services;

(c) one or more authentication policies, each of the one or more authentication policies defining a set of authentication requirements for a particular service; and

(d) one or more authorization policies, each of the one or more authentication policies defining a set of authorization requirements for a particular service;

a first server computer comprising a first processor and a first set of instructions executable by the first processor, the first set of instructions comprising;

(a) instructions to receive with a first service the service request from the client computer;

(b) instructions to ascertain that the service request requests an operation to be performed by second service at a second server computer;

(c) instructions to obtain from the centralized policy repository an identifier of the first service;

(d) instructions to transmit a request for the operation for reception by the second server computer, the request comprising the identifier of the first service;

a second server computer comprising a second processor and a second set of instructions executable by the second processor, the second set of instructions comprising;

(a) instructions to receive, with the second service, the request for the operation from the first server computer;

(b) instructions to transmit an authentication request for reception by the centralized policy server, the authentication request comprising the identifier;

(c) instructions to transmit an authorization request for reception by the centralized policy server; and

(d) instructions to provide the requested operation, based on an authentication status and an authorization status of the first server; and

an application programming interface (“

API”

) configured allow the first service and the second service to communicate with the centralized policy repository;

wherein the centralized policy server further comprises a third processor and a third set of instructions executable by the third processor, the third set of instructions comprising;

(a) instructions to receive the authentication request;

(b) instructions to identify the first service, based on the identifier;

(c) instructions to determine, based on an authentication policy for the second service, a set of authentication information for the first service, the set of authentication information being sufficient to authenticate the first service;

(d) instructions to provide the set of authentication information to the second server computer;

(d) instructions to receive the authorization request;

(e) instructions to determine, based on an authorization policy for the second service, a set of authorization information for the first service, the set of authorization information being sufficient to indicate whether the first service is authorized for the second service; and

(f) instructions to provide the set of authorization information to the second server computer.

2. In a computer environment comprising a plurality of services distributed across a plurality of network nodes, the plurality of services comprising a target service that is configured to perform a requested operation and a source service that requests the requested operation, a method of providing authentication and authorization among the plurality of services, the method comprising:

receiving, at a centralized policy repository, a first request from the target service, the first request comprising a request for authentication information about the source service;

determining, based on an authentication policy for the target service, a set of trust information required by the target service for authentication;

providing a first response to the target service, the first response comprising information for authenticating the source service;

receiving, at the centralized policy repository, a second request from the target service, the second request comprising a request for authorization information about an authorization of the source service to access the target service;

determining, based on an authorization policy for the target service, a set of authorization requirements for the source service; and

providing a second response to the target service, the second response comprising information about authorizing the source service.

3. A method as recited by claim 2, wherein the authentication policy for the target service specifies a set of authentication criteria a user must meet to authenticate with the source service.

4. A method as recited by claim 2, wherein the authentication policy for the target service specifies a set of authentication criteria the source service must meet to authenticate with the target service.

5. A method as recited by claim 2, wherein providing a first response to the target service comprises providing sufficient information to allow the target service to authenticate the target service.

6. A method as recited by claim 2, further comprising authenticating the source service at the centralized policy repository, based on the set of trust information required by the target service for authentication, wherein providing a first response to the target service comprises providing an authentication status of the source service.

7. A method as recited by claim 2, wherein the authorization policy for the target service specifies a set of authorization criteria a user must meet to authorize with the source service.

8. A method as recited by claim 2, further comprising authorizing the source service at the centralized policy repository, based on the authorization requirements for the source service, wherein providing a second response to the target service comprises providing an authorization status of the source service.

9. A method as recited by claim 2, wherein providing a second response to the target service comprises providing sufficient information to allow the target service to authorize the target service.

10. A method as recited by claim 2, wherein the centralized policy repository comprises a lightweight directory access protocol (“

LDAP”

) directory.

11. A method as recited by claim 2, wherein the first request and the second request are received via an application programming interface (“

API”

) configured to facilitate communication between the plurality of services and the centralized policy repository.

12. A method as recited by claim 2, wherein the target service is provided by a first application and wherein the source service is provided by a second application.

13. A method as recited by claim 2, wherein the target service and the source service are provided by the same application.

14. In a computer environment comprising a plurality of services distributed across a plurality of network nodes, a method of providing a service-to-service trust framework to allow interoperability between two or more services, the method comprising:

providing, at a centralized policy repository, an information store configured to store trust information related to each of the plurality of services;

providing an authorization model to define an interaction between the two or more services, wherein the two or more services comprise a target service that is configured to perform a requested operation and a source service that requests the requested operation;

providing, at the centralized policy repository, at least one authentication policy for the target service to define a set of authentication requirements for the target service;

providing, at the centralized policy repository, at least one authorization policy for the target service to define a set of authorization requirements for the target service; and

providing an application programming interface (“

API”

) to allow each of the two or more services to communicate with the information store.

15. A method as recited by claim 14, wherein the information store is centralized within an enterprise-wide network.

16. A method as recited by claim 14, further comprising:

providing an administration model defining a procedure for managing information in the information store.

17. A method as recited by claim 14, further comprising:

receiving, at the information store and via the API, a request from the target service to authenticate the source service;

authenticating the source service at the information store, based on the authentication policy; and

providing a response to the request, the response indicating an authentication status of the source service.

18. A method as recited by claim 17, wherein the source service serves as a proxy for separate entity, and wherein authenticating the source service comprises verifying an authentication of the separate entity according to the authentication policy.

19. A method as recited by claim 18, wherein the separate entity is a user of the source service.

20. A method as recited by claim 14, further comprising:

receiving, at the information store and via the API, a request from the target service to authorize the source service to obtain the requested operation;

determining, based on the authorization model, whether the source service is authorized to obtain the requested operation; and

providing a response to the request from the target service, the response comprising an authorization status of the source service.

21. A method as recited by claim 20, wherein the source service serves as a proxy for separate entity, and wherein authorizing the source service comprises verifying an authorization of the separate entity to use the source service according to the authorization policy.

22. A method as recited by claim 20, wherein the source service serves as a proxy for separate entity, and wherein authorizing the source service comprises verifying an authorization of the separate entity to use the target service according to the authorization policy.

23. In a computer environment comprising a plurality of services distributed across a plurality of network nodes, a service-to-service trust framework for facilitating interactions between two or more services, the framework comprising:

an information store configured to store trust information related to each of the plurality of services;

an authorization model to define an interaction between the two or more services, wherein the two or more services comprise a target service that is configured to perform a requested operation and a source service that requests the requested operation;

at least one authentication policy for the target service to define a set of authentication requirements for the target service;

at least one authorization policy for the target service to define a set of authorization requirements for the target service; and

an application programming interface (“

API”

) to allow each of the two or more services to communicate with the information store.