SiteMinder Browser Cookies

Contents
sm1252sp1
 
Contents
 
 
 
Require Cookies for Basic Authentication
You can control whether 
CA Single Sign-On
 requires cookies with the following parameter:
 
RequireCookies
 
Specifies whether 
CA Single Sign-On
 requires cookies. 
CA Single Sign-On
 requires cookies for the following functions:
  • Securing single sign-on environments.
  • Enforcing session timeouts.
  • Enforcing idle timeouts.
When the value of this parameter is yes, the agent requires one of the following cookies to process HTTP requests:
  • SMCHALLENGE
  • SMSESSION
When the value of this parameter is no, the following conditions could occur:
  • Users are challenged for credentials unexpectedly.
  • Timeouts are not strictly enforced.
 If the agent requires cookies, instruct your users to accept HTTP cookies in their browsers. Otherwise, the users are denied access to all protected resources.
 
Default:
 Yes
To require cookies, set the value of the RequireCookies parameter to yes.
Safeguard Information in Cookies with HTTP-Only Attribute
To help protect against cross-site scripting attacks, you can make the Web Agent set the HTTP-Only attribute for any cookies it creates using the following parameter:
 
UseHTTPOnlyCookies
 
Instructs the Web Agent to set the HTTP-only attribute on the cookies it creates. When a Web Agent returns a cookie with this attribute to a user's browser, the contents of the cookie cannot be read by a script, even a script from the web site which originally set the cookie. This helps prevent any sensitive information in the cookie from being sent to an unauthorized third party through a script.
 
Default:
 No
To safeguard the information in cookies, set the value of the UseHTTPOnlyCookies parameter to yes.
Set Secure Cookies
You can specify that session cookies are only sent between a protected web server and the requesting browser over secure (HTTPS) connections using the following parameter:
UseSecureCookies
 
Sends cookies with a secure flag to web servers. The secure flag is used by web browsers to mandate secure (HTTPS) connections. Enable this parameter to increase security between web browsers and web servers.
To send cookies over SSL connections, set the UseSecureCookies parameter to
yes
. As secure cookies cannot be passed over traditional HTTP connections, UseSecureCookies must be set to 
no
 when applications are accessed using HTTP.
Default:
 No
Control Identity Cookies
The TransientIDCookies parameter specifies whether or not the Agent identity cookie (SMIDENTITY) is transient or persistent.
Persistent cookies are written to a client system’s hard disk. Prior to Web Agent 5.x QMR1, persistent cookies remained valid for 7 days. Beginning with Web Agent 5.x QMR1, persistent cookies remain valid for the configured maximum session timeout plus 7 days. (The maximum session timeout is set in the Administrative UI.) Typically, a persistent cookie is deleted from a Web browser’s cookie file after the cookie expires; however, browsers may handle persistent cookies differently. By default, the Web Agent does not use persistent cookies. It uses transient cookies.
If you want to use single sign-on for multiple browser sessions, use persistent cookies. If you set persistent cookies, a user can end their browser session before a 
CA Single Sign-On
 session expires then start a new browser session and still have single sign-on capability.
Whereas persistent cookies are written to a hard disk, transient cookies are not written to the hard disk and they are not subject to configured session time-outs. Transient cookies will remain in your cookie folder.
Set TransientIDCookies to no, if you want the identity cookie to be persistent. Leave the default value set to yes, if you want the identity cookie to be transient.
Be sure to set the corresponding IP Check.
Set Persistent Cookies
If you want to use single sign-on for multiple browser sessions, use persistent cookies. The following steps describe one possible use for persistent cookies:
  1. Users authenticate with 
    CA Single Sign-On
    , but end their browser sessions before the 
    CA Single Sign-On
     session expires.
  2. Users start new browser sessions later, but the persistent cookie maintains their single-sign on capability.
Persistent cookies remain valid for the configured maximum session time-out 
plus 
seven days. Many browsers delete the cookie file of the web browser after the cookie expires. Some browsers possibly handle persistent cookies differently.
 
Follow these steps:
 
  1. Set the PersistentCookies parameter to yes.
    The SMSESSION cookies are persistent.
  2. Set the TransientIDCookies parameter to no.
    The SMIDENTITY cookies are persistent.
Specify the Cookie Path for Agent Cookies
When a Web Agent creates a cookie, the web agent automatically uses the root (/) directory as the cookie path. The domain and path attributes of cookies are compared to the URL of a request. If the cookie is valid for the domain and the path, the client sends the cookie to the server. When the cookie path uses the root value, the client sends the cookie to the server with all requests in the domain.
You can set 
CA Single Sign-On
 cookies to a given set of paths to eliminate the web traffic caused when cookies are sent for unprotected resources. For example, if a cookie path is set to /mypackage, the client only sends the cookie for requests in a particular package in the domain.
 
To specify the cookie path for agent cookies
 
  1. Open your Agent Configuration Object or your local agent configuration file.
  2. Set the Cookie Path for the Cookie Provider in the following parameter:
    •  
      MasterCookiePath
       
      Specifies the path for the primary-domain session cookies created by the cookie provider. For example, if this parameter is set to /siteminderagent, all session cookies that the cookie provider creates will have the /siteminderagent path. If this parameter is not set in the Cookie Provider Agent, the default value is used.
       
      Default:
       / (root)
  3. Set the cookie path for the secondary agents in the following parameter:
    •  
      CookiePath
       
      Specifies the cookie path for the following secondary agent browser cookies:
      • xxSESSION
      • xxIDENTITY
      • xxDOMINODATA
      • xxCHALLENGE (including SSL_CHALLENGE_DONE)
      • xxDATA
      • xxSAVEDSESSION
      For example, setting this parameter to /BasicAuth, all of the secondary agents in the previous list are created using /BasicAuth as the path. If not specified, the default value is used.
      The CookiePath is 
      not 
      added to credential cookies (such as xxxxCRED) to maintain backwards compatibility with 4.x agents.
      The following cookies will 
      always 
      use the root (/) path:
      • ONDENIEDREDIR
      • TRYNO
      If the CookiePathScope parameter is greater than zero, the CookiePath parameter settings are overriden.
       
      Default:
       / (root)
       
  4. (Optional) If you want the Web Agent to extract the cookie path from the URL instead of using the CookiePath value, set the following parameter to a number greater than zero:
    •  
      CookiePathScope
       
      Specifies the scope of the cookie path for the following secondary agent cookies:
      • xxSESSION
      • xxIDENTITY
      • xxDOMINODATA
      • xxCHALLENGE (including SSL_CHALLENGE_DONE)
      • xxDATA
      • xxSAVEDSESSION
      Using a CookiePathScope greater than zero in this parameter overrides the setting of the CookiePath parameter.
       
      Default:
       0
Force the Cookie Domain
Using fully qualified domain names helps ensure that cookies work properly. You can force the agent to append its cookie domain to the host name in a URL request that meets either of the following conditions:
  • The request does not specify a domain.
  • The request contains only an IP address.
  • Agents can be forced to use a cookie domain by setting the following parameters:
    •  
      ForceCookieDomain
       
      Forces the Web Agent to append its cookie domain to the host name in a URL request that does not specify a domain or contains only an IP address. This parameter works together with the ForceFQHost parameter for added functionality.
       
      Default:
       No
    •  
      ForceFQHost
       
      Forces an agent to use a fully qualified domain name. This parameter uses configured Domain Name System (DNS) services to append the cookie domain to the host name in a URL request through DNS services and not an Agent. If the Web Agent receives a request containing a partial URL, then the agent redirects the request back to the same destination resource specified in the original URI. The redirect request uses the fully qualified host name, which the agent determines using the configured DNS services. Use this parameter with the ForceCookieDomain parameter for added functionality.
       
      Default:
       No
       
      Example:
       When the agent receives a request from http://host1/page.html, it responds with http://host1.myorg.com/page.html. If the agent receives a request such as http://123.113.12.1/page.html, it responds with http://host1.myorg.com/page.html.
       These examples only work with proper DNS lookup tables. Request containing partial domain names that DNS cannot resolve could possibly generate errors.
 
Follow these steps:
 
  1. Set the value of the ForceCookieDomain parameter to yes.
  2. Set the value of the ForceFQHost parameter to yes.
    The agent appends its cookie domain to the host name when necessary.
Implement Cookie Domain Resolution
To implement automatic domain resolution, comment out the CookieDomain parameter or set it to none to cause the Web Agent to create cookies that are good only for the server from which they were issued.
You can further define the cookie domain by adding a value to the CookieDomainScope parameter. The scope determines the number of sections, separated by periods, that make up the domain name. (A domain always begins with a ".")
A CookieDomainScope value of 0 instructs the agent to use the most specific scope for a given host. A value of 1 (resulting, for example, in a cookie domain of .com) is not allowed by the HTTP specification. The value 2 instructs the agent to use the most general scope.
The following table shows some domain names and CookieDomainScope values.
 
 
Domain Name
 
 
Cookie Domain Scope value
 
 
Cookie Domain
 
server.myorg.com
2
.myorg.com
server.division.myorg.com
3
2
.division.myorg.com
.myorg.com
server.subdivision.division.myorg.com
4
3
2
.subdivision.division.myorg.com
.division.myorg.com
.myorg.com
For example, the domain division.myorg.com has a scope of 3. By default, the Web Agent assumes a scope of 2; cookie domains cannot have a scope of 1.
How CookiePathScope Settings Work
The following table shows how the value of the CookiePathScope parameter works with the following settings:
  • A URL such as http://
    fqdn
    /path1/path2/path3/path4/index.html
  • A CookiePath parameter value of /BasicA
 
If the CookiePath value is:
 
 
And the CookiePathScope value is:
 
 
Then the following path is used:
 
/BasicA
0
/BasicA
/BasicA
1
/Path1
/BasicA
2
/Path1/Path2
/BasicA
3
/Path1/Path2/Path3
/BasicA
4
/Path1/Path2/Path3/Path4
/BasicA
5
/Path1/Path2/Path3/Path4
/BasicA
99
/Path1/Path2/Path3/Path4
/ or "undefined"
0
/
/ or "undefined"
1
/Path1
/ or "undefined"
2
/Path1/Path2
/ or "undefined"
3
/Path1/Path2/Path3
/ or "undefined"
4
/Path1/Path2/Path3/Path4
/ or "undefined"
5
/Path1/Path2/Path3/Path4
/ or "undefined"
99
/Path1/Path2/Path3/Path4
Configure Support for SDK Third-Party Cookies
If you use non-
CA Single Sign-On
 Web Agents in your organization, you can configure them to support single sign-on with the following parameter:
 
AcceptTPCookie
 
Allows the Web Agent to accept session (SMSESSION) cookies created by third-party (non-
CA Single Sign-On
) Web Agents. Third-party agents generate and read SMSESSION cookies using the 
CA Single Sign-On
 SDK.
 
Default:
 No default
To allow the Web Agent to accept session cookies created by non-
CA Single Sign-On
 Web Agents, set the AcceptTPCookie parameter to yes.