User Sessions

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.
sm1252sp1
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.
2
Non-Persistent and Persistent Cookies
Standard
CA Single Sign-On
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 the product to use a cookie that is written to the hard disk. Maintaining a 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.
Non-Persistent and Persistent Sessions
CA Single Sign-On
also provides the ability to configure a persistent session. A persistent session is one in which a session is maintained in the session store.
Before you implement persistent sessions, consider the following:
  • Persistent sessions are enabled when you configure a realm.
  • Persistent sessions should only be used where necessary. Using session services to maintain sessions has an impact on system performance.
Session Tickets
CA Single Sign-On
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 the single sign–on environment. Session tickets are encrypted and only the Policy Server can read/validate them. 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.
Non-persistent and persistent cookies are unrelated to the session of the user being non-persistent or persistent.
  • Non–persistent session
    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.
  • Persistent Session
    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.
How
CA Single Sign-On
Manages User Sessions
The system manages user sessions automatically, performing the following functions during the lifecycle of a user session:
  • Session creation
    Establishing a session when a user successfully logs in to an application. If a user fails to authenticate, no session is established.
  • Session delegation
    Passing session information across an application environment. Delegating session information is necessary when the logic of an application crosses several application tiers.
  • Session validation
    Verifying the session ticket to verify that the user session is still active, that is, it has not expired or been terminated.
  • Session termination
    Ending a user session when any of the following events occur:
    • When a user logs out.
    • When the configured session timeouts expire.
    • When the
      CA Single Sign-On
      system manager disables a user.
    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 the management of a non-persistent session. In this graphic, the Web Agent passes the session ticket information across the application tier.
non-persistent session
non-persistent session
The following diagram shows the management of a persistent session. In this graphic, the Web Agent passes the session ticket information across the application tier.
persistent session
persistent session
How a User Session Begins
A user session begins when a user logs in and is authenticated by the Policy Server . 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.
How Sessions Across Realms Are Maintained
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:
  • The authentication scheme being used.
  • The namespace that the user is authenticating against.
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.
How Sessions Across Multiple Cookie Domains Are Maintained
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.
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.
How a User Session Is Validated
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.
How Session Information Is Delegated
User sessions may be delegated between application tiers in a
CA Single Sign-On
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 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 your  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 the deployment to maintain consistent user sessions.
Session Timeouts
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 time period that the Agent caches the result of a session validation call to the Policy Server. Session validation calls perform two functions: informing the Policy Server that a user is still active
and
checking that the user session is still valid.
How Agent Key Management and Session Timeouts are Coordinated
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.
How a User Session Ends
User sessions can end in any of the following ways:
  • A user logs out.
  • The session timeouts expire.
  • A user account is disabled from the Administrative UI (Select Administration, Manage User Accounts).
    Disabling a user account through the UI works only if the Web Agent has to call the Policy Server to validate the user session. If a persistent session is enabled and the session validation period is still active, the Agent checks its cache to validate the user session and might not contact the Policy Server. If the session is no longer in the Web Agent cache, then the Agent contacts the Policy Server to perform the user session verification. The session for the disabled user account is then denied.