This product maintains and administers consistent user sessions across multi‑tiered applications. Maintaining user session information is critical as applications and online 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 the users close their browsers, the session cookie is destroyed, effectively logging them out.
In addition to maintaining the cookie in the web browser, you can configure SiteMinder to use a cookie that is written to the hard disk. Maintaining a SiteMinder cookie on the hard disk is known as a persistent cookie. When using persistent cookies, users that close and reopen their browser remain logged in.
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 identifies 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 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 agent is responsible for validating the cookie and enforcing session timeouts.
The 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 agent is responsible for validating the session and enforcing the session timeouts.
SiteMinder manages user sessions automatically, performing many functions during the lifecycle of a user session, as shown in the following graphic:
Establishing a session when a user successfully logs in to 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 the logic of an application crosses several application tiers.
Verifying the session ticket to verify that the user session is still active, that is, it has not expired or been terminated.
Ending a user session when any of the following events occur:
When a user logs out or the user session expires, they must log in again to create a new session. Users who were manually disabled cannot re‑initiate a session.
The following graphic 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.
Users who request accesses to resources have a session is created within the context of the realm that contains that resource. An authentication scheme that is associated with the realm 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 product environment using proprietary HTTP headers that define the following components:
You can configure response attributes in a policy to communicate extra information about a user, such as a birth date or a phone number.
If the product is configured for single sign-on, the authentication scheme can also have a protection level. Administrators assign these protection levels. The levels range from 1 through 1000. One is the least secure and 1000 is the most secure. These protection levels enable administrators to implement single sign-on with a higher level of security and flexibility.
The authenticated users from one realm can be validated for a session in another realm. The protection level of the other realm is equal to or lower than the original realm. When the protection level is the equal or lower, that user does not need to re‑authenticate. The original user session remains valid. Users who request to access resources that are associated with an authentication scheme with a higher protection level are challenged to re‑enter their credentials. The original session is ended and a new one is created.
To configure protection levels for your single sign-on environment, see Authentication Schemes.
The product 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, the session information stays with them. Configure the agents for single sign-on to maintain session information across multiple cookie domains. 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.
These cookie domains let users authenticate in one cookie domain and then navigate to 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 using same user directory throughout the single sign-on environment. However, user directory connections that are configured in the Administrative UI must share the directory object name in each cookie domain.
Agents validate users sessions by checking whether it is still active. The agent first checks its session cache for session information. When the agent reads the cookie and the information exists in the cache, it validates the session. If it does not, the agent contacts the Policy Server to verify the identity of the user. The agent also collects other session and authorization information.
Users who access a resource with a higher protection level than the one used keep their session information even though another authentication occurs.
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 specify the length of an active session and the amount of session inactivity that can pass before a session is invalid. 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 the value of the 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. |
agents use a key to encrypt and decrypt any cookies that pass between agents in the environment that the product secures. All keys must be set to the same value for all agents communicating with a Policy Server.
A product 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. Specify when key rollovers occur in the Set Rollover Frequency dialog of the Administrative UI. The key updates across a product installation can take up to 3 minutes.
Coordinate the updating of keys together with session timeouts. Otherwise or you could possibly invalidate cookies that contain session information. This coordination is critical because the person designing policies in your organization could possibly be different than the person configuring dynamic key rollover.
Session timeouts must be less than or equal to two times the interval that is configured between Agent key rollovers. When Agent key rollovers occur two times before a session expires, any cookies that are written before the first key rollover are invalidated. If a session timeout is greater than the specified rollover interval, a user could possibly be re‑challenged for their identification before their session terminates.
For example, if you configure a key rollover to occur every three hours, set the Maximum Session timeout for six hours. This setting prevents multiple key rollovers from invalidating the session cookie.
User sessions can end in any of the following ways:
|
Copyright © 2012 CA Technologies.
All rights reserved.
|
|