Single Sign-on and the OBSSOCookie

The Oracle Access System implements single-domain and multi-domain single sign-on
through an encrypted cookie called the ObSSOCookie. The WebGate sends the
ObSSOCookie to the user’s browser upon successful authentication. This cookie can
then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.


When the user requests access to a browser or another resource, the request flows to
the Access Server. The user is logged in, and the ObSSOCookie is set. The Access
Server generates a session token with a URL that contains the ObSSOCookie. Single
sign-on works when the cookie is used for subsequent authorizations in lieu of
prompting the user to supply authorization credentials.


When the cookie is generated, part of the cookie is used as an encrypted session token.


The encrypted session token contains the following information:
- The distinguished name (DN) of the authenticated user.
- The level of the authentication scheme that authenticated the user.
- The IP address of the client to which the cookie was issued.
- The time the cookie was originally issued.
- The time the cookie was last updated.

If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter.


Unencrypted ObSSOCookie data includes:
- Cookie expiry time.
- The domain in which the cookie is valid.
- An optional flag that determines if the cookie can only be sent using SSL.
Security of the ObSSOCookie


The ObSSOCookie is a secure mechanism for user authentication. When the Access
System generates the cookie, an MD-5 hash is taken of the session token. When the
ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the
original cookie contents to be sure no one has tampered with the cookie. MD-5 is a
one-way hash, so it cannot be unencrypted. The Access Server does the comparison by
hashing the session token again and comparing the output with the hash of the token
already present in the cookie. If the two hashes do not match, the cookie is corrupt.
The system relies on the fact that if someone tampers with the session token, the
hashes will not match.

More Here

Courtesy:http://securidm.wordpress.com/2009/07/13/single-sign-on-and-the-obssocookie/