Sessions, Session Tokens, and Cookies

The Access Manager Session Service creates a session data structure to store information about a user session and uses cookies to store a token that identifies the session data structure. When a user logs in and is successfully authenticated, the user is assigned a session, a session data structure that, minimally, stores the following information about a user session:

Maximum Idle Time

Maximum number of minutes without activity before the session will expire and the user must reauthenticate.

Maximum Session Time

Maximum number of minutes (activity or no activity) before the session expires and the user must reauthenticate.

Maximum Caching Time

Maximum number of minutes before the client contacts Access Manager to refresh cached session information.

Internally, these session attributes are used to enforce Access Manager timeout limits. But a session can also contain additional attributes and properties which can be used by other applications. For example, a session data structure can store information about a user’s identity, or about a user’s browser preferences. You can configure Access Manager to include the following types of information in a session:

• Fixed session attributes

• Protected properties

• Custom properties

For a detailed summary of information that can be included in a session, see Configuring Access Manager Sessions in the Sun Java System Access Manager 7.1 Postinstallation Guide.

The Session Service also generates a session token for the new session data structure. The session token, also known as a sessionID, is an encrypted, unique string that identifies the specific session instance. If the session token is known to a protected resource such as an application, the application can access the session and all user information contained in it. In Access Manager, a session token is carried in a cookie. A cookie is an information packet generated by a web server and passed to a web browser. The fact that a web server generates a cookie for a user does not guarantee that the user is allowed access to protected resources. The cookie simply points to user information in a data store from which an access decision can be derived.

Cookies are domain-specific. For example, a cookie generated by a web server within Domain A cannot be used by a web server in Domain B. Cookies can be passed only between servers in the same domain in which the cookie was set. Similarly, servers can set cookies only on servers within in their own domain.