Session Cookie Management

This content describes how to manage session cookies.
sm1252sp1
This content describes how to manage session cookies.
 
 
Information Stored in the SMSESSION Cookie
When a user in CA Single Sign-On protected realm is authenticated, Web Agent generates an SMSESSION. The SMSESSION Cookie represents a user session.
The SMSESSION contains the following information:
  •  
    ATTR_USERDN:
    Represents the user distinguished name.
  •  
    ATTR_SESSIONID:
    Indicates the session ID returned from the login call.
  •  
    ATTR_USERNAME:
    Represents the user name.
  •  
    ATTR_CLIENTIP:
    Specifies the IP address of the machine where the user initiated a request for a protected resource.
  •  
    ATTR_DEVICENAME:
    Indicates the name of the agent that is decoding the token.
  •  
    ATTR_IDLESESSIONTIMEOUT:
    Indicates the maximum idle time for a session.
  •  
    ATTR_MAXSESSIONTIMEOUT:
    Indicates the maximum time a session can be active.
  •  
    ATTR_STARTSESSIONTIME:
    Indicates the time the session started after a successful login.
  •  
    ATTR_LASTSESSIONTIME:
    Indicates the time that the Policy Sever was last accessed within the session.
  •  
    ATTR_SESSIONSPEC:
    Indicates the session specification returned from the login call.
The SESSIONSPEC contains the following information that can only be decrypted by Policy Server:
  • SessionVersion
  • SessionStartTime
  • SessionLastTime
  • SessionMaxTimeout
  • SessionIdleTimeout
  • SessionLevel
  • SessionId
  • SessionIp
  • SessionDn
  • SessionDirOid
  • SessionDirName
  • SessionUnivId
  • SessionType
  • SessionAnonymous
  • SessionImpersonatorName
  • SessionLoginName
  • SessionPersistent
  • SessionDrift
  • SessionImpersonatorDirName
  • SessionAuthContext
Prevent Session Cookie Creation or Updates
Some web applications, such as Microsoft Outlook Web Access, make HTTP requests even when a user is not actively using the application. For example, the application makes HTTP requests when the user is not actively checking for new email on the server. These requests can update the SMSESSION cookie so that the session never expires, even when the user is idle. You can prevent the Web Agent from creating or updating session cookies during background requests so that sessions expire.
To prevent session cookie creation or updates, use the following parameters as required:
  •  
    OverlookSessionForMethods
     
    Specifies a list of methods against which the Web Agent compares the request method of all HTTP requests. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Also, cookie providers (if configured) are not updated for that request.
     
    Default:
     No default
  •  
    OverlookSessionForUrls
     
    Specifies a list of URLs against which the Web Agent compares the URLs from all HTTP requests. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Also, cookie providers (if configured) are not updated for that request.
     
    Default:
     No default
     
    Example:
     Use a relative URL, such as /MyDocuments/index.html. Do not use an absolute URL, such as http://
    fqdn.host
    /MyDocuments/index.html.
  •  
    OverlookSessionAsPattern
    If enabled, the Web Agent does not create cookies for any of the URLs under the directory that is specified in OverlookSessionForUrls.
    Default:
     No
    Options:
     Yes, No
    Example:
     Specify /siteminder/ for the OverlookSessionForUrls parameter and set the OverlookSessionAsPattern parameter to Yes. Based on this configuration, cookies are not generated for any /siteminder/* requests.
 If you configure the OverlookSessionForMethods and OverlookSessionForUrls parameters, the methods are processed before the URLs.
Prevent Session Cookie Creation or Updates Based on Method and URI
Some web applications, such as Microsoft Outlook Web Access, make HTTP requests even when a user is not actively using the application. For example, the application makes HTTP requests even when the user is not actively checking for new email on the server. These requests update the SMSESSION cookie so that the session never expires, even though the user has been idle. You can prevent the Web Agent from creating or updating session cookies during background requests so that sessions expire.
To prevent the creation of update of session cookies based on method and URI, set both of the following parameters:
  •  
    OverlookSessionForMethods
     
    Specifies a list of methods against which the Web Agent compares the request method of all HTTP requests. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Also, cookie providers (if configured) are not updated for that request.
     
    Default:
     No default
  •  
    OverlookSessionForMethodUri
     
    Specifies whether the Web Agent compares the method and the URI from all HTTP requests against the method and URI listed in this parameter. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Cookie providers (if configured) are not updated for that request.
     
    Default
    : No default.
     
    Value
    : Specify a relative URI. Do 
    not
     add spaces between the comma and the URL.
     
    Example
    : POST,/directory/file prevents updates to the SMSESSION cookie for POST requests to /directory/resource.
 Methods are processed before URIs.
Use the Session Store to Increase Security for Multi-Domain Single Sign-On 
By default, agents pass SMSESSION cookies in the query string of cookie provider redirect URLs during multi-domain single sign-on operations. To improve security during these operations, set the 
StoreSessioninServer
 parameter to configure agents and cookie providers to store the session temporarily and pass a GUID that identifies the stored session instead of the session cookie in the redirect URL.
 
Follow these steps:
 
  1. Verify that your environment meets the following conditions:
    • A session store is configured on the Policy Server.
    • A value is set for the DefaultAgentName parameter in agents that are configured as cookie providers.
  2. Set the 
    StoreSessioninServer
     agent configuration parameter to 
    Yes
     on all agents and cookie providers that are involved in multi-domain single sign-on.
Validate a Session Cookie Domain
You can reduce the risk that unauthorized users might hijack and attempt to reuse session cookies by having the Web Agent validate the domain of a session cookie. Use the 
TrackSessionDomain 
parameter to validate the domain. Setting this parameter to yes instructs the Web Agent to encrypt and store the intended domain of a session cookie in the session cookie itself. During subsequent requests, the Web Agent compares the intended domain that is stored in the session cookie against the domain of the requested resource. If the domains 
do
 
not 
match, the Web Agent rejects the request.
For example, when this parameter is set to yes, session cookies that are intended for operations.example.com are rejected when presented at finance.example.com.
In 
CA Single Sign-On
 environments using SSO, set this parameter for the Web Agent that creates the encrypted session cookie. For example, your SSO environment has domains that are named 
a.example.com
 and 
b.example.com
. If the Web Agent protecting a.example.com encrypts the session cookie, set the value of the TrackSessionDomain parameter of the associated Web Agent. When the Web Agent protecting b.example.com receives the cookie, it compares the intended domain against the domain of the requested resource.
 
Default: 
No
Set the value of the TrackSessionDomain parameter to 
yes
 to track session domains.
Protect Session Cookies from Misuse with Validation Periods and Expired Cookie URLs
 
CA Single Sign-On
 uses time-based session cookie parameters that can substantially reduce the possibility of a session cookie being compromised by administrators or other users who have access to the following items:
  • Web server logs
  • Web Agent logs
  • Potentially compromised proxy servers sitting between domains in the case of cross-domain single sign-on
These time-based session cookie parameters add the concept of "born dates" to session cookies. Agents receiving a session cookie as a result of a redirect (URL session cookie) look for the cookie born date name/value pair and compare this value with the value set for the CookieValidationPeriod configuration parameter. If the value of the born date and the CookieValidationPeriod parameter value exceed the current time, the cookie is rejected.
To protect session cookies from misuse, set the following parameters:
  •  
    CookieValidationPeriod 
     
    Specifies the time period (in seconds) in which the receiving agent accepts the session cookie. After this time passes, the session cookie will not be accepted. If this field is not used or is set to zero, the session cookie expires when the Idle Timeout and Max Session Timeout values are met.
     
    Default:
     Empty
  •  
    ExpiredCookieURL
     
    (Optional) Specifies a URL that the agent redirects the user to after any session cookie has expired. If the born date and the CookieValidationPeriod are not configured, the agent ignores the settings and processes the cookie as usual.
How IdleTimeout and SessionGracePeriod Parameters Affect Session Updates
SessionGracePeriod defines the number of seconds the agent waits from the last accessed time of the received session cookie before it generates a new session cookie. If the setting is disabled, the agent updates session cookies for every request. If the setting is enabled, the agent skips cookie generation when the following conditions are met:
  • Last access time + IdleTimeout value > Current time + 2(SessionGracePeriod)
  • Current time - Last access time < SessionGracePeriod
The value of session grace period must be less than half of the idle timeout value. If not, session cookie is updated for each request though a resource is accessed within the specified session grace period.