US20070118890A1 - Method and apparatus for facilitating single sign-on - Google Patents

Abstract

One embodiment of the present invention provides a system that facilitates single sign-on of a client, wherein single sign-on allows the client to provide authentication credentials once during a computing session and to access multiple resources without re-authenticating. The system operates by receiving a domain cookie forwarded from the client by an application server at a single sign-on server, wherein the domain cookie includes a domain identifier and an encrypted secret path, and wherein the domain cookie can only be retrieved by servers whose domain matches the domain identifier in the domain cookie. The system then decrypts the encrypted secret path to reveal an unencrypted secret path. Next, the system redirects the client to the unencrypted secret path, wherein the unencrypted secret path is a path that terminates on the single sign-on server. Upon redirection, the system sends a request to the client from the single sign-on server requesting a domain-token cookie, wherein the domain-token cookie includes the domain identifier, a clear secret path, and encrypted information, wherein the request includes the clear secret path, and wherein the domain-token cookie can only be retrieved from the client if the client determines that the unencrypted secret path and the clear secret path match. Finally, upon receiving the domain-token cookie from the client at the single sign-on server, the system authenticates the client.

Description

BACKGROUND
• 1. Field of the Invention
• The present invention relates to computer systems. More specifically, the present invention relates to a method and an apparatus for facilitating single sign-on of a client to access multiple computational applications and resources within an enterprise without having to re-authenticate.
• 2. Related Art
• Single sign-on servers have been deployed in many enterprises to improve customer satisfaction, reduce authentication overhead, and to maintain stricter compliance with security policies. A single sign-on server allows a user to authenticate one time, and subsequently allows the user to access multiple applications and resources within an enterprise without having to re-authenticate. In many cases, these applications and resources are located on different servers in different locations.
• Single sign-on servers typically operate by sending a cookie to a client. A cookie includes information that can be stored on the client by the single sign-on server, and can be retrieved at a later time. Host cookies can be retrieved only by the server that is designated as the host of the cookie, however, domain cookies can be retrieved by any server that is a member of the same domain as the server that assigned the cookie. Because of this flexibility, domain cookies are often used for single sign-on purposes.
• Cookie implementations, in their current form, are not an effective mechanism for preventing nefarious individuals from gaining access to single sign-on systems. Cookies are easy to hijack and can be manipulated because they are stored on the client. In addition, because domain cookies can be retrieved by any server within the same domain as the issuer, nothing is stopping an nefarious individual from deploying a rogue server within a domain to collect these cookies.
• Hence, what is needed is a secure means for implementing single sign-on without the limitations listed above.
SUMMARY
• One embodiment of the present invention provides a system that facilitates single sign-on of a client, wherein single sign-on allows the client to provide authentication credentials once during a computing session and to access multiple resources without re-authenticating. The system operates by receiving a domain cookie forwarded from the client by an application server at a single sign-on server, wherein the domain cookie includes a domain identifier and an encrypted secret path, and wherein the domain cookie can only be retrieved by servers whose domain matches the domain identifier in the domain cookie. The system then decrypts the encrypted secret path to reveal an unencrypted secret path. Next, the system redirects the client to the unencrypted secret path, wherein the unencrypted secret path is a path that terminates on the single sign-on server. Upon redirection, the system sends a request to the client from the single sign-on server requesting a domain-token cookie, wherein the domain-token cookie includes the domain identifier, a clear secret path, and encrypted information, wherein the request includes the clear secret path, and wherein the domain-token cookie can only be retrieved from the client if the client determines that the unencrypted secret path and the clear secret path match. Finally, upon receiving the domain-token cookie from the client at the single sign-on server, the system authenticates the client.
• In a variation on this embodiment, prior to receiving the domain cookie, the system receives an operation request from the client at an application server that requires authentication of the client. In response to the operation request, the system sends a second request to the client for a domain cookie. In response to the second request, the system receives the domain cookie at the application server. Finally, the system forwards the domain cookie to the single sign-on server.
• In a variation on this embodiment, the second request includes a request for a host cookie, wherein the host cookie includes encrypted user identification information. The system further involves receiving the host cookie at the application server, and authenticating the client.
• In a further variation, wherein upon authenticating the client, the system creates a new host cookie. The system also creates a new secret path on the single sign-on server and encrypts the new secret path to create a new encrypted secret path. In addition, the system creates a new domain cookie including the new encrypted secret path and a new domain-token cookie including the new secret path. Finally, the system issues the new host cookie, the new domain cookie, and the new domain-token cookie to the client.
• In a variation on this embodiment, upon each successful authentication, the encrypted secret path and the clear secret path are changed.
• In a variation on this embodiment, the encrypted secret path and the clear secret path are created from a random value.
• In a variation on this embodiment, the client is a browser.
• In a variation on this embodiment, the single sign-on server is an Oracle Single Sign-On Server.
• In a variation on this embodiment, the application server is an Oracle Application Server.
BRIEF DESCRIPTION OF THE FIGURES
• FIG. 1 illustrates an enterprise environment in accordance with an embodiment of the present invention.
• FIG. 2 illustrates single sign-on cookies in accordance with an embodiment of the present invention.
• FIG. 3 presents a flowchart illustrating the process of single sign-on in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION
• The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
• The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs), and computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated). For example, the transmission medium may include a communications network, such as the Internet.
• Enterprise Environment
• FIG. 1 illustrates anenterprise environment100 in accordance with an embodiment of the present invention.Enterprise environment100 includesnetwork102,user103, client104, single sign-onserver106 andapplication servers108 and110.
• Network102 can generally include any type of wired or wireless communication channel capable of coupling together computing nodes. This includes, but is not limited to, a local area network, a wide area network, or a combination of networks. In one embodiment of the present invention,network102 includes the Internet.
• Client104 can generally include any node on a network including computational capability and including a mechanism for communicating across the network.
• Single sign-onserver106 andapplication servers108 and110 can generally include any nodes on a computer network including a mechanism for servicing requests from a client for computational and/or data storage resources.
• Client104, single sign-onserver106, andapplication servers108 and110 are couple together vianetwork102. Whenuser103 wishes to access applications and resources onapplication servers108 and110 via client104,user103 must first authenticate with single sign-onserver106. Onceuser103 has been authenticated, it is not necessary foruser103 to re-authenticate to use further resources. Re-authentication happens behind the scenes and is described in more detail below in the description ofFIG. 3.
• In one embodiment of the present invention,application servers108 and110 are partner servers. Onceuser103 has authenticated withapplication server108,user103 can accessapplication server110 directly, without having to re-authenticate.
• Single Sign-On Cookies
• FIG. 2 illustrates single sign-on cookies in accordance with an embodiment of the present invention. One embodiment of the present invention uses ahost cookie200, adomain cookie210, and a domain-token cookie220 to implement single sign-on.Host cookie200 includes encrypteduser identification information202. This encrypteduser identification information202 is encrypted with a key that is known only to single sign-onserver106. In general,host cookie202 can only be retrieved by the server that assignedhost cookie202.
• Domaintoken cookie210 includes an identifier fordomain212 and encryptedsecret path214. Encryptedsecret path214, like encrypteduser identification information202, is encrypted with a key that is known only to single sign-onserver106.Domain cookie210 can be retrieved by any server that is a member of the domain specified bydomain212. This includesapplication servers108 and110.
• Domain-token cookie220 includes an identifier fordomain212, clear secret path222, andencrypted user information224. Likedomain cookie210, domain-token cookie220 can be retrieved by any server that is a member of the domain specified bydomain212. However, in order to retrieve domain-token cookie220, a server must know the contents of clear secret path222, which can only be obtained by decrypting encryptedsecret path214. Thus, if a nefarious individual has access todomain cookie210 andhost cookie200, that individual cannot gain single sign-on access because he or she will not be able to get domain-token cookie220 without the decryption key stored on single sign-onserver106.
• In one embodiment of the present invention, when client104 first authenticates withapplication server108, ahost cookie200 is generated for client104. (Domain cookie210 and domain-token cookie220 are also generated.) The next time client104 accessesapplication server108, client104 presentshost cookie200 only, and client104 will be granted access toapplication server108. This is adequate for a very simple host cookie-based single server access environment. Note thathost cookie200 is considered secure becausehost cookie200 is relatively hard to steal.
• However, when client104 tries to accessapplication server110 after the above interaction withapplication server108, client104 can not use thesame host cookie200 becausehost cookie200 can not be sent toapplication server110 by client104.Only domain cookie210 can be sent to different host on the same domain.
• When client104 subsequently accessesapplication server108, bothdomain cookie210 andhost cookie200 are presented. However, ifhost cookie200 exists, only hostcookie200 is used. Domain-token cookie220 will not be presented at all, because when domain-token cookie220 was generated, it was specified that client104 can only send domain-token cookie220 if and only if the request is for the host on the same domain as specified bydomain212 and the path matches the clear secret path222.
• In one embodiment of the present invention, the way client104 decides if or not to send a certain cookie is based on the host, domain and path. For example, in the case when the system generateshost cookie200 anddomain cookie210, the system sets the path to “/”, which means any path will match. But when the system generates domain-token cookie220, the system sets the path as the secret-path. Whenuser103 starts to accessapplication server110 after accessingapplication server108, only thedomain cookie210 will be presented the first time.
• However,application server110 does not just trustdomain cookie210. In fact,application server110 sends the encryptedsecret path214 in thedomain cookie210 to single sign-onserver106. Single sign-onserver106 decrypts the encryptedsecret path214 to reveal the clear secret path, and passes the clear secret path back toapplication server110. With the clear secret path,application server110 sends another request to client104 to ask if client104 has the domain-token cookie220 which is based on this secret path (i.e. the clear secret path matches clear secret path222). If client104 can present domain-token cookie220 based on this particular secret path, then client104 can be trusted.
• Once domain-token cookie220 has been presented, the system creates three brand new cookies—host cookie200, which will be used when client104 subsequently accessesapplication server110,domain cookie210, which will be used when client104 accesses any other partner server in the same domain, and domain-token cookie220, for the next verification.
• In one embodiment of the present invention, the encryption/decryption occurs only on single sign-onserver106.
• Single Sign-On
• FIG. 3 presents a flowchart illustrating the process of single sign-on in accordance with an embodiment of the present invention. The process of single sign-on starts whenuser103 attempts to access resources on an application server, such asapplication server108, withinenterprise environment100. The system starts whenapplication server108 receives a request to access resources from client104, wherein the request includes domain cookie210 (step302). (Note that since client104 hasdomain cookie210, but does not havehost cookie200, it is implied that client104 has not been authenticated toapplication server108, but has been authenticated on a partner server in the same domain, such asapplication server110.)
• If client104 does not havedomain cookie210, thenuser103 has not been authenticated with single sign-onserver106, and client104 is re-directed to single sign-onserver106 to authenticateuser103. If client104 hasdomain cookie210, thenuser103 has been authenticated with single sign-onserver106 in the past, and the following steps happen in a manner that is undetectable touser103.
• In response to the request,application server108forwards domain cookie210 to single sign-on server106 (step308). Single sign-onserver106 then decrypts encryptedsecret path214 to reveal the unencrypted secret path (step310). Next, the system redirects the client to a location specified by the unencrypted secret path at requests the domain-token cookie220 (step312). Because the domain-token cookie220 is only returned if the clear secret path222 matches the unencrypted secret path, a nefarious individual would have to have the decryption key on single sign-onserver106 to obtain the domain-token cookie220 and gain access to the system.
• Upon receiving domain-token cookie220, the single sign-onserver106 authenticatesuser103 at client104 (step314) and allows client104 to continue accessing resources onapplication server108. In addition, single sign-onserver106 re-issues hostcookie200,domain cookie210, and domain-token cookie220 (step316). In re-issuing the cookies, single sign-onserver106 creates a new random encryptedsecret path214 and corresponding clear secret path222 to help protect against attack.
• The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.

Claims (20)

1. A method for facilitating single sign-on of a client, wherein single sign-on allows the client to provide authentication credentials once during a computing session and to access multiple resources without re-authenticating, the method comprising:

receiving a domain cookie forwarded from the client by an application server at a single sign-on server, wherein the domain cookie includes a domain identifier and an encrypted secret path, and wherein the domain cookie can only be retrieved by servers whose domain matches the domain identifier in the domain cookie;

decrypting the encrypted secret path to reveal an unencrypted secret path;

redirecting the client to the unencrypted secret path, wherein the unencrypted secret path is a path that terminates on the single sign-on server;

upon redirection, sending a request to the client from the single sign-on server requesting a domain-token cookie, wherein the domain-token cookie includes the domain identifier, a clear secret path, and encrypted information, wherein the request includes the clear secret path, and wherein the domain-token cookie can only be retrieved from the client if the client determines that the unencrypted secret path and the clear secret path match; and

upon receiving the domain-token cookie from the client at the single sign-on server, authenticating the client.

2. The method ofclaim 1, wherein prior to receiving the domain cookie, the method further comprises:

receiving an operation request from the client at an application server that requires authentication of the client;

in response to the operation request, sending a second request to the client for a domain cookie;

in response to the second request, receiving the domain cookie at the application server; and

forwarding the domain cookie to the single sign-on server.

3. The method ofclaim 1, wherein the second request includes a request for a host cookie, wherein the host cookie includes encrypted user identification information; and wherein the method further comprises:

receiving the host cookie at the application server; and

authenticating the client.

4. The method ofclaim 3, wherein upon authenticating the client, the method further comprises:

creating a new host cookie;

creating a new secret path on the single sign-on server;

encrypting the new secret path to create a new encrypted secret path;

creating a new domain cookie including the new encrypted secret path;

creating a new domain-token cookie including the new secret path; and

issuing the new host cookie, the new domain cookie, and the new domain-token cookie to the client.

5. The method ofclaim 1, wherein upon each successful authentication, the encrypted secret path and the clear secret path are changed.

6. The method ofclaim 1, wherein the encrypted secret path and the clear secret path are created from a random value.

7. The method ofclaim 1, wherein the client is a browser.

8. The method ofclaim 1, wherein the single sign-on server is an Oracle Single Sign-On Server.

9. The method ofclaim 1, wherein the application server is an Oracle Application Server.

10. A computer-readable storage medium storing instructions that when executed by a computer cause the computer to perform a method for facilitating single sign-on of a client, wherein single sign-on allows the client to provide authentication credentials once during a computing session and to access multiple resources without re-authenticating, the method comprising:

receiving a domain cookie forwarded from the client by an application server at a single sign-on server, wherein the domain cookie includes a domain identifier and an encrypted secret path, and wherein the domain cookie can only be retrieved by servers whose domain matches the domain identifier in the domain cookie;

decrypting the encrypted secret path to reveal an unencrypted secret path;

redirecting the client to the unencrypted secret path, wherein the unencrypted secret path is a path that terminates on the single sign-on server;

upon redirection, sending a request to the client from the single sign-on server requesting a domain-token cookie, wherein the domain-token cookie includes the domain identifier, a clear secret path, and encrypted information, wherein the request includes the clear secret path, and wherein the domain-token cookie can only be retrieved from the client if the client determines that the unencrypted secret path and the clear secret path match; and

upon receiving the domain-token cookie from the client at the single sign-on server, authenticating the client.

11. The computer-readable storage medium ofclaim 10, wherein prior to receiving the domain cookie, the method further comprises:

receiving an operation request from the client at an application server that requires authentication of the client;

in response to the operation request, sending a second request to the client for a domain cookie;

in response to the second request, receiving the domain cookie at the application server; and

forwarding the domain cookie to the single sign-on server.

12. The computer-readable storage medium ofclaim 10, wherein the second request includes a request for a host cookie, wherein the host cookie includes encrypted user identification information; and wherein the method further comprises:

receiving the host cookie at the application server; and

authenticating the client.

13. The computer-readable storage medium ofclaim 12, wherein upon authenticating the client, the method further comprises:

creating a new host cookie;

creating a new secret path on the single sign-on server;

encrypting the new secret path to create a new encrypted secret path;

creating a new domain cookie including the new encrypted secret path;

creating a new domain-token cookie including the new secret path; and

issuing the new host cookie, the new domain cookie, and the new domain-token cookie to the client.

14. The computer-readable storage medium ofclaim 10, wherein upon each successful authentication, the encrypted secret path and the clear secret path are changed.

15. The computer-readable storage medium ofclaim 10, wherein the encrypted secret path and the clear secret path are created from a random value.

16. The computer-readable storage medium ofclaim 10, wherein the client is a browser.

17. The computer-readable storage medium ofclaim 10, wherein the single sign-on server is an Oracle Single Sign-On Server.

18. The computer-readable storage medium ofclaim 10, wherein the application server is an Oracle Application Server.

19. An apparatus for facilitating single sign-on of a client, wherein single sign-on allows the client to provide authentication credentials once during a computing session and to access multiple resources without re-authenticating, comprising:

a cookie receiving mechanism configured to receive a domain cookie forwarded from the client by an application server at a single sign-on server, wherein the domain cookie includes a domain identifier and an encrypted secret path, and wherein the domain cookie can only be retrieved by servers whose domain matches the domain identifier in the domain cookie;

a decryption mechanism configured to decrypt the encrypted secret path to reveal an unencrypted secret path;

a redirection mechanism configured to redirect the client to the unencrypted secret path, wherein the unencrypted secret path is a path that terminates on the single sign-on server;

a request mechanism configured to send a request to the client from the single sign-on server requesting a domain-token cookie upon redirection of the client, wherein the domain-token cookie includes the domain identifier, a clear secret path, and encrypted information, wherein the request includes the clear secret path, and wherein the domain-token cookie can only be retrieved from the client if the client determines that the unencrypted secret path and the clear secret path match; and

an authentication mechanism configured to authenticate the client upon receiving the domain-token cookie from the client at the single sign-on server.

20. The apparatus ofclaim 19, further comprising:

a receiving mechanism configured to receive an operation request from the client at an application server that requires authentication of the client, prior to the apparatus receiving the domain cookie;

wherein the request mechanism is further configured to send a second request to the client for a domain cookie, in response to the operation request;

wherein the cookie receiving mechanism is further configured to receive the domain cookie at the application server in response to the second request; and

a forwarding mechanism configured to forward the domain cookie to the single sign-on server.

Images