Session Service

The mission of the OpenSSO Enterprise Session Service is to maintain information about an authenticated user's session across all web applications participating in a user session. Additionally, OpenSSO Enterprise provides continuous proof of the user’s identity, enabling the user to access multiple enterprise resources without having to provide credentials each time. This enables the following types of user sessions.

• Basic user session. The user provides credentials to log in to one application, and then logs out of the same application.

• SSO session. The user provides credentials once, and then accesses multiple applications within the same DNS domain.

• Cross domain SSO (CDSSO) session. The user provides credentials once, and then accesses applications among multiple DNS domains.

A user session is the interval between the time a user attempts authentication through OpenSSO Enterprise and is issued a session token, and the moment the session expires, is terminated by an administrator, or the user logs out. In what might be considered a typical user session, an employee accesses the corporate benefits administration service. The service, monitored by OpenSSO Enterprise, prompts the user for a username and password. With the credentials OpenSSO Enterprise can authenticate, or verify that the user is who he says he is. Following authentication, OpenSSO Enterprise allows the user access to the service providing authorization is affirmed. Successful authentication through OpenSSO Enterprise results in the creation of a session data structure for the user or entity by the Session Service. Generally speaking, the Session Service performs some or all of the following:

• Generates unique session identifiers, one for each user's session data structure

  ---

  Note –

  A session data structure is initially created in the INVALID state with default values for certain attributes and an empty property list. Once the session is authenticated, the session state is changed to VALID and session data is updated with the user's identity attributes and properties.

  ---

• Maintains a master copy of session state information

  ---

  Note –

  The session state maintained on the client side is a cached view of the actual session data structure. This cache can be updated by either the active polling mechanism or the session notification triggered by the Session Service.

  ---

• Implements time-dependent behavior of sessions — for example, enforces timeout limits

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

• Notifies all participants in the same SSO environment of session state changes

• Enables SSO and cross-domain single sign-on (CDSSO) among applications external to OpenSSO Enterprise by providing continued proof of identity.

• Allows participating clients to share information across deployments

• Implements high availability facilities

Figure 2–6 illustrates the interactions between the local and remote components of the Session Service within a OpenSSO Enterprise deployment.

Figure 2–6 Session Service Components within a OpenSSO Enterprise Deployment

Additionally, Figure 2–7 illustrates how the messaging capabilities of Message Queue can be used to push session information to a persistent store based on the Berkeley DataBase (DB). Using OpenSSO Enterprise in this manner enables the following key feature:

• Session Failover allows an alternative OpenSSO Enterprise server to pick up a given user session when the server owning the original session fails.

• Session Constraints allow deployments to specify constraints on a sessions, such as one session per user.

Figure 2–7 Session Persistence Deployment Architecture

More information on the architecture of the Session Service can be found in the Session Service Architecture document on the OpenSSO web site. For more information on session failover, see Chapter 8, Implementing OpenSSO Enterprise Session Failover, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.