SINGLE SIGN-ON BETWEEN APPLICATIONS

• US 20120291114A1
• Filed: 05/13/2011
• Published: 11/15/2012
• Est. Priority Date: 05/13/2011
• Status: Active Grant

• Current Assignee: CCH Incorporated (Wolters Kluwer Nv)
• Original Assignee: CCH Incorporated (Wolters Kluwer Nv)
• Inventors: Poliashenko, Maxim, Baumann, Robert
• Granted Patent: US 8,839,395 B2
• Time in Patent Office: Days
• US Class Current: 726/8
• CPC Class Codes: G06F 21/41 where a single sign-on provides access to a plurality of computers
• CPC Class Codes: G06F 21/44 Program or device authentication
• 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/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: H04L 9/321 involving a third party or a trusted authority
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853

Abstract

A single sign-on (SSO) system uses simple one-to-one trust relationships between individual applications and an SSO service to extend log in services from one application to another. Each application retains its own login policies and can separately make a decision whether to trust the SSO request or challenge the user for login credentials. By structuring the SSO system to use simple identity mapping, there is no requirement for consolidating user identity records from multiple applications into a single database with its attendant overhead and dependency risks.

Claims

1. A method of authenticating a user accredited in an application (app A) to another application (app B), the method comprising:

receiving at an SSO service a request from app A to create an SSO request, the request including a a user identifier and an application identifier;

generating a request identifier at the SSO service;

providing the request identifier to app A for use by app A in contacting app B;

receiving, at the SSO service, from app B the request identifier provided to app A;

verifying at the SSO service that a mapping exists for app B;

providing a mapping token to app B, the mapping token corresponding to a previous registration of the user by app B with the SSO service;

extracting login information from the mapping token at app B; and

accepting the login information when the login information meets a local security policy at app B.

2. The method of claim 1,

wherein:

establishing the trust relationship comprises mutual authentication using a shared secret or a public key infrastructure.

3. The method of claim 1, wherein receiving at the SSO service the request from app A comprises receiving an authentication strength identifier.

4. The method of claim 1, further comprising:

establishing a trust relationship between a single sign-on (SSO) service and app A; and

establishing a trust relationship between the SSO service and app B, wherein;

establishing the trust relationship comprises mutual authentication using a shared secret or a public key infrastructure.

5. The method of claim 1, wherein the request includes an application instance identifier.

6. The method of claim 1, wherein providing the mapping token to app B comprises providing the mapping token and additional data stored by app B at the SSO service.

7. The method of claim 1, wherein generating a request identifier comprises generating a nonce to include with the request identifier.

8. The method of claim 1, further comprising authenticating the user between app B and app A using the mapping token.

9. A system of one or more computers coupled by a network comprising:

i) an SSO service embodied as a web service on a computer server, the computer server comprising;

a hardware communication service coupled to a physical network that supports communication between the computer server and at least one other physical computer; and

a secure storage facility that holds authentication-related data from a plurality of applications external to the computer server;

a request identifier module that provides a request identifier responsive to a message from a first application, the message requesting access to a second application;

a mapping module that stores mapping tokens with information related to a relationship between user identities in the first application and the second application and provides the mapping token responsive to a second message received from the second application, the second message including the request identifier previously sent to the first application and forwarded to the second application by the first application;

ii) the first application running on a computing device coupled to the network supporting the first application, the first application comprising;

an interface module that accepts a request to access the second application; and

a communications module that generates a communication session with the SSO service that forwards the request to the SSO service and that receives the request identifier from the SSO service responsive to the request;

iii) the second application running on the computing device or another computing device, the second application comprising;

a second interface module that receives the request identifier from the first application; and

a security module that sends the request identifier in the second message via the second interface module to the SSO service over the network, that when the mapping token is present at the SSO service, receives the mapping token from the SSO service, the mapping token including login information previously stored by the second application corresponding to a previous login at the second application via the first application, wherein the security module applies information in the mapping token to a login process, and when the information in the mapping token satisfies a login requirement, provides the user access to the second application.

10. The system of claim 9, wherein the request identifier module is programmed to retrieve a nonce from the cryptographic module for inclusion in the request identifier.

11. The system of claim 9, wherein the request identifier module is programmed to store a user identifier received from the first application and to generate the request identifier.

12. The system of claim 9, wherein communication between the SSO service and the first application, and communication between the SSO service and the second application, are cryptographically verified for source and integrity.

13. The system of claim 9, wherein the mapping token contains a hash of the user password at the second application.

14. A computer-readable storage media having computer executable instructions for executing on a processor of a computer a method of performing authentication of a user logged in to a first application requesting access to a second application, the method comprising:

challenging the user for authentication credentials when a mapping token that stores login information associated with the first application and that was previously received from the second application is not available from a single sign-on service;

logging the user into the second application when the authentication credentials are satisfactory; and

sending user information and application information to the single sign-on service for use in generating the mapping token for subsequent sign-on access by the user of the first application when accessing the second application.

15. The computer-readable storage media of claim 14, wherein the computer executable instructions further comprise:

receiving a request identifier at the second application indicating the user wishes to login to the second application;

sending the request identifier to the single sign-on service;

receiving the mapping token from the single sign-on service;

evaluating information in the mapping token to extract login information regarding the user; and

applying a local security or login policy to the login information to determine whether to allow the user automatic access to the second application.

16. The computer-readable storage media of claim 15, wherein the information in the mapping token includes one of a transaction identifier, a user identifier, a first application identifier, and a hash of a password corresponding to a password previously provided by first application to the second application.

17. The computer-readable storage media of claim 16, wherein the information in the mapping token further includes an authentication strength indicator corresponding to a login strength of the user at the first application.

18. The computer-readable storage media of claim 17, wherein the information in the mapping token further includes a payload provided by the first application to the single sign-on service.

19. The computer-readable storage media of claim 14, wherein the computer executable instructions further comprise requiring the user to log in manually when the local security or login policy indicate automatic access to the second application fails.

20. The computer-readable storage media of claim 14, wherein the computer executable instructions further comprise providing the mapping token by the single sign-on service when accessing another application.