Techniques for dynamically establishing and managing trust relationships

• US 20050172116A1
• Filed: 02/03/2004
• Published: 08/04/2005
• 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.
• Granted Patent: US 7,316,027 B2
• Time in Patent Office: Days
• US Class Current: 713/155
• 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, wherein the community list includes one or more different principals with which the requesting principal can permissibly establish a trust relationship;

dynamically maintaining the community list in a trust configuration associated with the requesting principal; and

transmitting the community list to the requesting principal.

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;

acquiring one or more trust specifications for the community list from the identity service; and

dynamically managing interactions with the one or more principals according to the one or more trust specifications.

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, 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 with 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.

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.

25. A trusted relationship data structure, residing on a computer readable medium, the data structure defining trusted relationships of a particular principal and comprising:

second principal identifiers;

metadata associated with each of the second principal identifiers; and

a trust specification defining policies and access rights for interactions occurring between a first principal and second principals associated with the second principal identifiers.

26. The trusted relationship data structure of claim 25 wherein a new second principal identifier is dynamically added as one of the second principal identifiers along with new metadata related to the new second principal identifier and a modified trust specification including new policies and new access rights for interactions occurring between the first principal and a new second principal associated with the new second principal identifier.

27. The trusted relationship data structure of claim 25 wherein the trusted relationship data structure is received from an identity service and managed locally by a principal service of the first principal according to the limits defined in the trust specification.

28. The trusted relationship data structure of claim 27 wherein the trusted relationship data structure is subdivided into multiple trusted relationship data structures each individual trusted relationship data structure including selected ones of the second principal identifiers, selective portions of the metadata, and selective portions of the trust specification.

29. The trusted relationship data structure of claim 25 wherein the metadata includes public key certificates for the second principal identifiers.

30. The trusted relationship data structure of claim 25 wherein an identity service generates an initial instance of the trusted relationship data structure, encrypts the initial instance using a public key of the first principal, signs the initial instance, and transmits the encrypted and signed initial instance to the first principal.

31. The trusted relationship data structure of claim 25 wherein at least one of the second principal identifiers is associated with a group having a plurality of entries where each entry is associated with a third principal.

32. The trusted relationship data structure of claim 25 wherein a first principal service manages the trusted relationship data structure for the interactions between the first principal and the second principals, and wherein the first principal service generates, modifies, and manages one or more policies that the interactions conform to, wherein the policies do not exceed strictures of the trust specification.

33. The trusted relationship data structure of claim 25 wherein as portions of the data structure are communicated between an identity service and the first principal, the portions are encrypted and decrypted using public-private key pairs and signed by sending parties.