SMSESSION handling for nested cookie domains such as: and
search cancel

SMSESSION handling for nested cookie domains such as: and


Article ID: 51494


Updated On:


CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On



The client ran into trouble setting up an internal Siteminder protected webserver on a subdomain of their corporate intranet.

The server they were trying to install had an address of: and cookie domain of:

Where as the corporation already had an existing Siteminder installation, with main site of and cookie domain of:

They did not have access to the corporate Siteminder policy servers and wanted to setup their own nested domain to control access to applications within their division.

However when they set it up, half of the users that first visited, and logged onto the global site were then unable to logon and access pages in the local site, but for the other half and for those that directly accessed the local site access worked correctly.



For those users that had the problem the steps were:

  1. Access the corporate domain

  2. Login to
    this sets cookie:

  3. Then access the subdomain which has its own policy server setup.

  4. Login to
    this sets cookie:

  5. Sometimes the user gets access to the site, and at other times the user does not get access to the site, and gets prompted again for credentials.


Unfortunately the browser (and the HTTP standard) will see:


As separate cookies
(If you have Mozilla, you can look at your current cookies and will see both)

The (incorrect) expectation is that the cookie for the more specific domain would take precedence over a cookie for the more general domain when accessing sites such as, either in being sent by the client or in the order processed by the server is incorrect.

However when you then access the resource:

It will send BOTH cookies to the server:

(The domain info is not sent)

The server will process one SMSESSION (either first or last one, but the order sent from the browser is not specified)

The outcome for the user then is:

  1. If it uses SMSESSION=YYYYY... then it works and the user can access the resource.

  2. If it uses SMSESSION=XXXXX... then user is not considered logged on and they will be redirect back to the logon page again.

From the Cookie RFC:

If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. Ordering with respect to other attributes (e.g., Domain) is unspecified.

(oddly enough so nested paths work in a predictable manner but not nested domains)


Here are a number of things you can try to work around this limitation.

THE SOLUTION (workaround A - integrate with your corporate SSO infrastructure)

The best solution possible is if you can integrate your local siteminder implementation into the corporate model, then you only need the one cookie domain and do not have a problem with nested domains.

However this is not always possible.

THE SOLUTION (workaround B - use different ZONES)

Recent versions of Siteminder webagent (but not application agent) allow for the specifying of "zones". The default zone is the "SM" zone and it uses "SMSESSION" as the cookie.

In the above example if the web agents for specified SSOZoneName="DIVA", then they would use a session cookie named "DIVASESSION", and ignore the set of SMXXXX cookies, instead using a series of DIVAXXXX cookies for Siteminder processing.

In this way both SMSESSION and DIVASESSION can co-exist and although both a SMSESSION and DIVASESSION will be sent to the webserver:, that server will only look for and process the DIVASESSION session cookie.

However, a word of warning with Zones, the SMSESSION cookie is fairly large (often about 2k). Even with one SMSESSION cookie we can run into problems of exceeding the allowed HTTP header size limit of 4k of data, (the header also includes other content such as other cookies like the JSESSION/ASPSESSION and referrer URL etc.If you have two "zones" that will mean two XXSESSION cookies (or about 4k) of data being sent, and if some webservers will truncate the request at 4k, loosing the remaining information. As URL lengths can vary, often this shows up as requests periodically loosing their JSESSION or other session information.

THE SOLUTION (workaround C - overwrite SMSESSION)

Changed to domain usage for so it issues cookie:


Since both servers uses the same domain for the SMSESSION cookie, the second logon will overwrite the first SMSESSION variable and there is only one SMSESSION hat is sent to the server and no confusion.

It does however mean that each time you go back and forth between the local and the corporate domain you will be asked to log onto again.

THE SOLUTION (workaround D - use non overlapping domain)

In the problems we have the overlapping domains:


Depending upon your circumstances, you may be able to change the divisionA domain so that it does not overlap with the primary domain, for example, if we can change to then the two will not overlap:.


And both domains can co-exist, and one SMSESSION cookie will be sent to each domain.

The same would also be true, if divisionA had its own of its own domain:



Component: SMPLC