Chapter 5 User Sessions and the Session Service

The Session Service in Sun OpenSSO Enterprise tracks a user’s interaction with web applications through the use of session data structures, session tokens, cookies, and other objects. This chapter explains these concepts and other components of a user's session and contains the following sections:

• About the Session Service

• User Sessions and Single Sign-on

• Session Data Structures and Session Token Identifiers

About the Session Service

The Session Service in Sun OpenSSO Enterprise tracks a user’s interaction with protected web applications. For example, the Session Service maintains information about how long a user has been logged in to a protected application, and enforces timeout limits when necessary. Additionally, the Session Service:

• Generates session identifiers.

• Maintains a master copy of session state information.

• Implements time-dependent behavior of sessions.

• Implements session life cycle events such as logout and session destruction.

• Generates session life cycle event notifications.

• Generates session property change notifications.

• Implements session quota constraints.

• Implements session failover.

• Enables single sign-on and cross-domain single sign-on among applications external to OpenSSO Enterprise.

• Offers remote access to the Session Service through the Client SDK with which user sessions can be validated, updated, and destroyed.

The state of a particular session can be changed by user action or timeout. Figure 5–1 illustrates how a session is created as invalid before authentication, how it is activated following a successful authentication, and how it can be invalidated (and destroyed) based on timeout values.

Figure 5–1 Life Cycle of a Session

User Sessions and Single Sign-on

A user session is the interval between the moment a user attempts to log in to a resource protected by OpenSSO Enterprise, and the moment the session expires, is terminated by an administrator, or the user logs out. As an example of a user session, an employee attempts to access the corporate benefits administration application protected by OpenSSO Enterprise. A new invalid session is created, and the Authentication Service prompts the user for a username and password to verify the user's identity. Following a successful authentication, the Policy Service and policy agent work together to check that the user has the appropriate permissions to access the protected application and allows or denies access based on the outcome.

Oftentimes, in the same user session (without logging out of the corporate benefits application), the same employee might attempt to access a corporate expense reporting application. Because the expense reporting application is also protected by OpenSSO Enterprise, the Session Service provides proof of the user’s authentication, and the employee is allowed to access the expense reporting application (based on the outcome of a second authorization check with the Policy Service). If access is granted, the employee has accessed more than one application in a single user session without having to reauthenticate. This is called single sign-on (SSO). When SSO occurs among applications in more than one DNS domain, it is called cross-domain single sign-on (CDSSO). For a more detailed overview of a basic user session, an SSO session, and a CDSSO session, see Chapter 6, Models of the User Session and Single Sign-On Processes.

Session Data Structures and Session Token Identifiers

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.

Identifier

A unique, universal identifier for the session data structure.

Host Name or IP Address

The location from which the client (browser) is making the request.

Principal

Set to the user's distinguished name (DN) or the application's principal name.

Type

USER or APPLICATION

Session State

Defines whether the session is valid or invalid.

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 OpenSSO Enterprise to refresh cached session information.

---

Note –

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.