Techniques for dynamically establishing and managing trust relationships

• US 7,316,027 B2
• Filed: 02/03/2004
• Issued: 01/01/2008
• Est. Priority Date: 02/03/2004
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Novell Incorporated (Open Text Corporation)
• Inventors: Carter, Stephen R, Burch, Lloyd Leon, Earl, Douglas G.
• Primary Examiner(s): Vu; Kim
• Assistant Examiner(s): Dada; Beemnet W
• Application Number:
  US10/770,677
• Publication Number:
  US 20050172116A1
• Time in Patent Office: 1,428 Days
• Field of Search: 713/168, 713/175, 713/155, 713/164, 713/166, 380/277, 380/282, 726/1, 726/2, 726/4, 726/27, 726/28, 709/223, 709/225, 709/228
• US Class Current: 726/1
• CPC Class Codes: G06F 21/41 where a single sign-on provides access to a plurality of computers
• CPC Class Codes: H04L 63/0428 wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• 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/20 for managing network security; network security policies in general filtering policies H04L63/0227

Abstract

Techniques are provided for dynamically establishing and managing trust relationships. A first principal initially requests a community list. The community list includes identities of one or more second principals with which the first principal can establish trusted relationships with. The community list is associated with a trust specification. The trust specification defines the policies and access rights associated with interactions between the first principal and the second principals during any active trusted relationships. The first principal can dynamically subdivide, manage, and modify entries of the community list and the trust specification, assuming any such modifications are permissible according to global contracts and policies associated with the first principal.

Claims

1. A method for dynamically establishing trust relationships, comprising:

acquiring a community list for a requesting principal via an identity service, wherein the community list includes one or more different principals with which the requesting principal can permissibly establish a trust relationship and wherein the community list identifies other principals that the requesting principal may not engage in other trusted relationships with and the community list also includes conditions for particular ones of the one or more different principals that are to be satisfied before the trust relationship with those particular ones are permitted to proceed;

dynamically maintaining the community list separate from the principal via the identity service in a trust configuration associated with the requesting principal, and wherein the trust configuration includes a threshold limitations which cannot be exceeded by the requesting principal, and wherein hard limitations with respect to communications with the one or more different principals and which are defined in the trust configuration cannot be expanded by the requesting principal but the requesting principal can add more restrictive limitations to a version of the trust configuration being maintained by the requesting principal; and

transmitting the community list and a copy of the trust configuration to the requesting principal, and wherein the identity service is an intermediary between the requesting principal and one of the one or more different principals.

2. The method of claim 1 further comprising:

detecting changes to the community list;

updating the trust configuration with the changes; and

notifying the requesting principal of the changes.

3. The method of claim 1 further comprising:

receiving a refresh request from the requesting principal;

determining if there are changes to the community list;

updating the trust configuration with the changes, if present; and

notifying the requesting principal of the changes, if present.

4. The method of claim 1 further comprising associating a time-to-live constraint with the transmitted community list, wherein the time-to-live constraint informs the requesting principal when it is recommended that a refreshed version of the community list be requested.

5. The method of claim 1 further comprising:

removing a selective one of the one or more different principals from the community list producing a modified community list upon notice from the requesting principal; and

updating the trust configuration with the modified community list.

6. The method of claim 1 further comprising:

receiving an add request from the requesting principal to add a new principal to the community list;

verifying a contract and policy associated with the requesting principal permits the new principal to be added in the community list;

producing a modified community list with the new principal added to the community list, if verified; and

updating the trust configuration with the modified community list, if verified.

7. The method of claim 6 further comprising:

determining the add request is a permanent request from the requesting principal; and

updating one or more stores with the new principal, wherein the one or more stores were used to derive the trust configuration.

8. The method of claim 1 further comprising:

detecting an event that revokes the requesting principal'"'"'s use of the community list;

removing the trust configuration; and

revoking the community list from the requesting principal.

9. A method for dynamically managing trust relationships, comprising:

receiving a community list from an identity service, wherein the community list includes one or more principals with which trusted relationships can be established, and wherein the community list identifies specific principals that a requesting principal may not engage in other trusted relationships with and the community list also includes conditions for particular ones of the one or more different principals that are to be satisfied before the trust relationship with those particular ones are permitted to proceed with the requesting principal;

acquiring one or more trust specifications for the community list from the identity service, and wherein the trust specifications includes threshold limitations which cannot be exceeded by the one or more principals, and wherein hard limitations with respect to communications among the principals and which are defined in the trust specifications cannot be expanded by the principals but any given requesting principal can add more restrictive limitations to a particular trust specification being maintained by that requesting principal; and

dynamically managing interactions with the one or more principals according to the one or more trust specifications, and wherein the identity service is an intermediary between the requesting principal and one of the one or more different principals.

10. The method of claim 9 further comprising removing a selective one of the principals from the community list.

11. The method of claim 9 further comprising:

requesting from the identity service the addition of a new principal to the community list; and

adding the new principal if the identity service permits.

12. The method of claim 9 further comprising:

acquiring public key certificates from metadata of the community list for selective ones of the principals; and

performing at least one of encrypting and signing communications occurring during the interactions with the selective ones of the principals with the acquired public key certificates.

13. The method of claim 9 further comprising:

dividing the community list into one or more sub-community lists;

establishing sub-trust specifications for each of the sub-community lists; and

managing the interactions with the one or more principals according to appropriate ones of the sub-trust specifications.

14. The method of claim 13 wherein the receiving further includes receiving the community list where at least one of the principals in the community list is a group having multiple entries and each entry associated with an additional principal.

15. The method of claim 13 wherein the wherein the receiving further includes receiving the community list where at least one of the principals in the community list is a separate community list.

16. A trusted relationship management system, comprising:

a first principal service;

a plurality of second principal services; and

an identity service, which is an intermediary between the first principal service and the plurality of second principal services, wherein the first principal service receives a community list from the identity service that identifies a plurality of second principals with which a first principal can establish trusted relationships via the first principal service, which interacts with each of the second principal services, and wherein interactions occurring between the first principal and the second principals are defined by an initial trust specification assembled by the identity service and initially delivered to the first principal service as a version of that trust specification and that version includes a threshold limitations which cannot be exceeded by the first principal, and wherein hard limitations with respect to communications with the second principals and which are defined in the version of the trust specification cannot be expanded by the first principal but the first principal can add more restrictive limitations to the version being maintained by the first principal.

17. The trusted relationship management system of claim 16 wherein the identity service associates a public key certificate with at least one of the second principals identified in the community list.

18. The trusted relationship management system of claim 16 wherein the identity service dynamically notifies the first principal service when a change is detected with entries or with metadata associated with the community list.

19. The trusted relationship management system of claim 16 wherein the identity service accepts a dynamically generated public key certificate from the first principal service associated with a dynamically generated public-private key pair for the first principal and provides the dynamically generated public key certificate to select ones of the second principal services.

20. The trusted relationship management system of claim 16 wherein the first principal service uses a public key certificate and the associated private key, encrypts the certificate with the public key of the third principal from the third principal'"'"'s well-known certificate, and sends it to the identity service, the identity service sends it to the third-principal, the third-principal validates the identity service is trusted, uses the private key associated with the well-known certificate of the third principal to decrypt the encrypted certificate, obtains a strongly rooted public-private key pair of the first principal service and encrypts it with the public key of the first principal service based on contents of the decrypted certificate, and sends the encrypted strongly rooted public-private key pair to the identity service, the identity service forwards that to the first principal service, the first principal service decrypts the encrypted strongly rooted public-private key pair with the private key associated with the certificate used in the third principal transaction and uses the decrypted strongly rooted key pair to communicate with one or more of the second principals services.

21. The trusted relationship management system of claim 20 wherein as information is passed between at least one of the first principal service and the identity service and the identity service and the third principal, that information is signed by a sending party and verified by a receiving party.

22. The trusted relationship management system of claim 16 wherein the identity service adds a new second principal to the community list on the request of the first principal service and after validating that a contract or a policy of the first principal permits the new second principal to be added.

23. The trusted relationship management system of claim 16 wherein the identity service provides an original trust specification with the community list to the first principal service and wherein the first principal service manages the original trust specification and makes one or more changes to the original trust specification, wherein the one or more changes are more limiting than the original trust specification.

24. The trusted relationship management system of claim 16 wherein the first principal service sub-divides the community list into one or more sub-community lists, wherein each sub-community list represents an overlay network which the first principal can interact within and which the first principal service can dynamically manage.