The Session Service programmatically creates a session data structure to store information about a user session. The result of a successful authentication results in the validation of a session data structure for the user or entity and the creation of a session token identifier. The session data structure minimally stores the following information.
A unique, universal identifier for the session data structure.
The location from which the client (browser) is making the request.
Set to the user's distinguished name (DN) or the application's principal name.
USER or APPLICATION
Defines whether the session is valid or invalid.
Maximum number of minutes without activity before the session will expire and the user must reauthenticate.
Maximum number of minutes (activity or no activity) before the session expires and the user must reauthenticate.
Maximum number of minutes before the client contacts OpenSSO Enterprise to refresh cached session information.
The value for Maximum Caching Time should be smaller than the value for Maximum Idle Time. If not, the user session idle time won't be updated if the resource is accessed again within the maximum caching time period.
A session can also contain additional 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 OpenSSO Enterprise to include the following types of data in a session:
Protected properties are only modifiable by the server-side modules (primarily the Authentication Service).
Custom properties are modifiable remotely by any application which possesses the session identifier.
For a detailed summary of information that can be included in a session, see Chapter 14, Configuring OpenSSO Enterprise Sessions, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
The session token, also referred to as a sessionID and programmatically as an SSOToken, is an encrypted, unique string that identifies the session data structure. As the user visits different protected resources using the browser, the session token is propagated to these resources and is used to retrieve the user's credentials. These credentials are then validated by sending a back-end request (using the Client SDK or a policy agent) to OpenSSO Enterprise which then returns an error or the session's prior authentication data. Sessions (and hence the SSOToken) are invalidated when a user logs out, the session expires, or a user in an administrative role invalidates it. With OpenSSO Enterprise, a session token is carried in a cookie, an information packet generated by a web server and passed to a web browser. (The generation of a cookie for a user by a web server does not guarantee that the user is allowed access to protected resources. The cookie simply points to information in a data store from which an access decision can be made.)
Access to some OpenSSO Enterprise services, such as the Policy Service and the Logging Service, require presentation of both the SSOToken of the application as well as the SSOToken of the user, allowing only designated applications to access these services.