Web Agent Guides › Web Agent Configuration Guide › User Protection › SiteMinder Browser Cookies

SiteMinder Browser Cookies

To manage the cookies that are associated with the CA SiteMinder® agent, use the parameters in any of the following procedures:

• Require cookies for the basic authentication scheme.
• Safeguard information in cookies with the HTTP-only attribute.
• Set secure cookies within a domain.
• Control identity cookies.
• Set persistent cookies.
• Specify the cookie path for agent cookies.
• Force the agent to use a cookie domain.
• Implement cookie domain resolution.
• How cookie path scope settings work.

Require Cookies for Basic Authentication

You can control whether CA SiteMinder® requires cookies with the following parameter:

RequireCookies

Specifies whether CA SiteMinder® requires cookies. CA SiteMinder® 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.

Important! 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 to web servers using secure (HTTPS) connections. Enable this parameter to increase security between browsers and web servers.

When this setting is enabled, users in single sign-on environments who move from an SSL web server to a non-SSL web server will have to reauthenticate. Secure cookies cannot be passed over traditional HTTP connections.

Default: No

To send cookies over SSL connections, set the UseSecureCookies parameter to yes.

More information:

Set Secure Cookies Across Multiple Domains

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 SiteMinder® 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.

More Information

Compare IP Addresses to Prevent Security Breaches

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 SiteMinder®, but end their browser sessions before the CA SiteMinder® 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 SiteMinder® 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

More information:

Configure Full Logoff

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.

  Note: 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.

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

These settings also affect simple SSO. For example, if the value of the CookiePathScope is set to 1 or higher,users will get challenged for credentials for both /BasicA/Index.html and /BasicB/Index.html since the SESSION cookie with a path /BasicA will not be valid for /BasicB/Index.html request.

Configure Support for SDK Third-Party Cookies

If you use non-CA SiteMinder® 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 SiteMinder®) Web Agents. Third-party agents generate and read SMSESSION cookies using the CA SiteMinder® SDK.

Default: No default

Note: For more information, see the programming documentation.

To allow the Web Agent to accept session cookies created by non-CA SiteMinder® Web Agents, set the AcceptTPCookie parameter to yes.