This section contains the following topics:
How Sessions Across Realms Are Maintained
How Sessions Across Multiple Cookie Domains Are Maintained
How a User Session Is Validated
How Session Information Is Delegated
How Agent Key Management and Session Timeouts are Coordinated
SiteMinder maintains and administers consistent user session across multi-tiered applications. Maintaining user session information is critical as applications and Internet businesses become location-independent and the environments and applications technology and security needs vary.
Standard SiteMinder session cookies are non–persistent. A non–persistent cookie is one that is maintained only in the memory of the web browser. When users close their browser, the session cookie is destroyed, effectively logging them out.
In addition to maintaining the cookie in the web browser memory, you can configure SiteMinder to have the cookie written to the hard disk. Maintaining a SiteMinder cookie in the web browser and on hard disk is known as a persistent cookie. When using persistent cookies, users that close and reopen their browser remain logged in.
Note: For more information about configuring a persistent cookie, see the Web Agent Configuration Guide.
SiteMinder also provides the ability to configure a persistent session to provide Windows security context functionality and support for Federated Web Services. A persistent session is one in which a SiteMinder cookie is maintained in a SiteMinder session store, in the memory of the web browser, and optionally the hard disk.
Before you implement persistent sessions, consider the following:
Note: For more information about enabling and configuring session services, see the Policy Server Administration Guide.
SiteMinder implements session management using session tickets. A session ticket contains basic information about a user and the authentication information for that user. The session ticket is used to identify the session of the user across all sites in a single sign–on SiteMinder environment. Session tickets are encrypted and only the Policy Server can read/validate them. SiteMinder web agents use session tickets to identify users and provide session information to the Policy Server.
The session ticket is handled differently depending upon whether the session is persistent or non–persistent.
Note: Non–persistent and persistent cookies are unrelated to the SiteMinder session of the user being non–persistent or persistent.
The web agent places the session ticket in a cookie. The cookie contains the user session data; no user-specific data is kept in the cookie itself. The web agent is responsible for validating the cookie and enforcing session timeouts.
The web agent places the session ticket in a session store database and, if possible, in an optional cookie on the client.
The session ticket data is used as an index into the cache of the web agent, which contains the user session data. If a cookie is written, no user–specific data is kept in the cookie itself. The web agent is responsible for validating the session and enforcing the session timeouts.
For the most part, SiteMinder manages user sessions automatically, performing a number of session management functions during the life cycle of a user session, as illustrated below.
Establishing a session when a user successfully logs into an application. If a user fails to authenticate, no session is established.
Passing session information across an application environment. Delegating session information is necessary when an application’s logic crosses several application tiers.
Verifying the session ticket to make sure the user session is still active, that is, it has not expired or been terminated.
Ending a user session when a user logs out, when the configured session timeouts expire, or when a user is manually disabled by the SiteMinder System Manager. When a user logs out or the user session expires, they must log in again to create a new session. In the case of manual user disablement, the user can not re-initiate a session.
The following diagram illustrates how SiteMinder manages a non-persistent session.
The following diagram illustrates how SiteMinder manages a persistent session.
A user session begins when a user logs in and is authenticated by SiteMinder. The Policy Server issues the session ticket, which is then required for all subsequent Agent requests for that user’s session. If a user is forced to authenticate again during a session because of a higher protection level, the existing session is maintained.
A session is active until it is terminated when the user logs off, when the session expires, or when an administrator disables a user, thereby terminating the session.
When a user requests access to a resource, his or her session is created within the context of the realm that contains that resource. An authentication scheme is also associated with a realm, and it determines the type of credentials that the user must present to gain access to the resource.
This authentication context is made available to all Web servers in the SiteMinder installation through SiteMinder’s default HTTP headers that define components, such as the authentication scheme being used, the namespace the user is authenticating against, and other relevant information. In addition to the default headers, you can configure response attributes in a policy to communicate information for a user, such as a birth date or a phone number, that helps to further identify a user.
If the SiteMinder installation is configured for single sign-on, the authentication scheme may have a protection level assigned to it by an administrator. The level can be a number from 1 through 1000, with 1 being the least secure and 1000 being the most secure. These protection levels enable administrators to implement single sign-on with a higher level of security and flexibility.
An authenticated user of one realm can be validated for a session in another realm if the second realm is protected by an authentication scheme of an equal or lower protection level as the first. As long as the protection level is the same or lower, that user does not need to re-authenticate, which means that the user session remains valid. If a user tries to access a resource protected by an authentication scheme with a higher protection level, SiteMinder prompts the user to re-enter his or her credentials, thereby ending one user session and creating a new session.
To configure protection levels for your single sign-on environment, see Authentication Schemes.
SiteMinder supports single sign-on across multiple cookie domains in environments with heterogeneous Web server platforms. If a user visits companyA.com and then goes to companyB.com, his or her session information stays with them. To maintain session information across multiple cookie domains, the Web Agents must be configured for single sign-on. With single sign-on configured, the cookie that contains session information can be made available to all Agents and servers in the single sign-on environment.
The ability to pass session and identification information across multiple cookie domains enables a user to authenticate at a site in one cookie domain and then navigate to a site in another cookie domain without being re-challenged for information.
Single sign-on is accomplished using a cookie provider. The cookie provider is an extension of the Web Agents in the single sign-on environment.
To achieve cross-domain logout for resources in separate cookie domains, you can enable persistent sessions for the realms in separate cookie domains. When a user logs out in one domain, the Policy Server sends a logout event terminating the user session.
Note: Single sign-on across multiple cookie domains does not require that the same user directory be used across the single sign-on environment. However, user directory connections configured in the Administrative UI must share the same directory object name in each cookie domain.
When a user requests access to a resource, the Web Agent validates the session by checking whether or not it is still active. The Web Agent first checks its session cache for session information. If the Web Agent reads the cookie and has the information in cache, it can validate the session. If it does not, then it contacts the Policy Server to verify the user’s identity and collect any other session and authorization information.
When a user accesses a resource that has a higher protection level than the one used when establishing the session, the session information is maintained, even though another authentication takes place.
User sessions may be delegated between application tiers in a SiteMinder installation using the session ticket. The session ticket is the mechanism by which the user identity is passed from one application tier to another. Each application can make authorization calls to the Policy Servers after getting the session ticket.
If your SiteMinder installation uses custom Agents, the custom Agent must have access to the information in the session ticket to maintain session information.
In addition to using the session ticket for delegation, the Web Agent makes a set of default HTTP headers available for session management. These default headers can be passed across different business application tiers such as Enterprise Java Beans (EJB) and Component Object Model (COM) based tiers. Included in these headers is a unique session ID and optionally, a universal ID. The session ID identifies an active user session.
The universal ID identifies the user to an application in a SiteMinder environment. This ID is typically not the same as the user login ID, but is some other type of unique identifier like a telephone number or a customer account number. The universal ID helps facilitate identification between old and new applications. The universal ID delivers the user identification automatically, regardless of the application. In addition, the ID is built into applications. A built-in ID provides applications a user identification method that is separate from the user directory, which undergoes constant changes.
Both the session ID and the universal ID are shared among all the applications in a SiteMinder environment to maintain consistent user sessions.
Each user session includes session timeout information. The timeout values let you determine the length of an active session and the amount of session inactivity that can pass before a session is invalid. You configure session timeouts on a per-realm basis using the following timeout options.
|
Name |
Purpose |
|---|---|
|
Maximum Timeout (All sessions) |
Specifies the maximum amount of time a user session can be active before the Web Agent challenges the user to re-authenticate. You can override this setting using the WebAgent-OnAuthAccept-Session-MaxTimeout response attribute. |
|
Idle Timeout (All sessions) |
Specifies the amount of time that a user session can be idle before the Web Agent terminates the session. If the session expires, a user must re-authenticate. Note: For persistent sessions, this value must be greater than that specified by Session Validation Period. You can override this setting using the WebAgent-OnAuthAccept Session-Idle-Timeout response attribute. |
|
Session Validation Period (Persistent Sessions) |
For persistent sessions only, specifies the maximum period between Agent calls to the Policy Server to validate a session. Session validation calls perform two functions: informing the Policy Server that a user is still active and checking that the user’s session is still valid. |
SiteMinder Web Agents use a key to encrypt and decrypt any cookies that pass between Web Agents in a SiteMinder environment. All keys must be set to the same value for all Web Agents communicating with a Policy Server.
A SiteMinder installation can be configured to use dynamic Agent keys that change on a periodic basis. Dynamic key rollover lets you update dynamic keys at regular intervals to ensure the security of encrypted cookies. You specify when key rollovers occur in the Set Rollover Frequency dialog box of the Administrative UI. Key updates across a SiteMinder installation can take up to three minutes.
You must coordinate the updating of keys together with session timeouts or you may invalidate cookies that contain session information. This coordination is critical because the person designing policies in your organization may be different than the person configuring dynamic key rollover.
Session timeouts must be less than or equal to two times the interval configured between Agent key rollovers. If an administrator configures an agent key rollover to occur two times before a session expires, cookies written by the Web Agent before the first key rollover will no longer be valid. If a session timeout is greater than the specified rollover interval, a user may be re-challenged for their identification before their session terminates.
For example, if you configure key rollover to occur every three hours, you might want to set the Maximum Session timeout for 6 hours to ensure that multiple key rollovers do not invalidate the session cookie.
A user session can end in one of three ways:
A user can terminate his or her own session by logging out.
A user’s session can expire because of configured session timeouts or policy-based response attributes, requiring the user to re-enter his or her credentials to begin a new session.
A System Manager can disable a user account, flushing the session account and preventing that user from re-authenticating. For more information, see the Policy Server Administration Guide.
|
Copyright © 2012 CA.
All rights reserved.
|
|