SMSESSION handling for nested cookie domains such as: .divisionA.intra.example.com and .intra.example.com
Article ID: 51494
Updated On:
Products
Issue/Introduction
Description:
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: http://app1.divisionA.intra.example.com and cookie domain of: .divisionA.intra.example.com
Where as the corporation already had an existing Siteminder installation, with main site of http://www.intra.example.com and cookie domain of: .intra.example.com
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.
Solution:
THE PROBLEM:
For those users that had the problem the steps were:
- Access the corporate domain http://www.intra.example.com
- Login to http://logon.intra.example.com/siteminderagent/forms/login.fcc
this sets cookie:
SMSESSION=XXXXXX... domain=.intra.example.com - Then access the subdomain http://app1.divisionA.intra.example.com which has its own policy server setup.
- Login to http://logon.divisionA.intra.example.com/siteminderagent/forms/login.fcc
this sets cookie:
SMSESSION=YYYYY.... domain=.divisionA.intra.example.com - 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.
THE REASON
Unfortunately the browser (and the HTTP standard) will see:
SMSESSION=XXXXX.... domain=.intra.example.com
SMSESSION=YYYYY.... domain=.divisionA.intra.example.com
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 .divisionA.intra.example.com would take precedence over a cookie for the more general domain .intra.example.com when accessing sites such as http://app1.divisionA.intra.example.com, either in being sent by the client or in the order processed by the server is incorrect.
However when you then access the resource:
http://app1.divisionA.intra.example.com/
It will send BOTH cookies to the app1.divisionA.intra.example.com server:
SMSESSION=XXXXX....
SMSESSION=YYYYY....
(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:
- If it uses SMSESSION=YYYYY... then it works and the user can access the resource.
- 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.
http://www.faqs.org/rfcs/rfc2109.html
(oddly enough so nested paths work in a predictable manner but not nested domains)
SOLUTIONS
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 divisionA.intra.example.com 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: http://app1.divisionA.intra.example.com, 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 divisionA.intra.example.com so it issues cookie:
SMSESSION=YYYY... domain=.intra.example.com
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:
SMSESSION=XXXXX.... domain=.intra.example.com
SMSESSION=YYYYY.... domain=.divisionA.intra.example.com
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 .divisionA.intra.example.com to .divsionA.example.com then the two will not overlap:.
SMSESSION=XXXXX.... domain=.intra.example.com
SMSESSION=YYYYY.... domain=.divisionA.example.com
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 .divisionA.com of its own domain:
SMSESSION=YYYYY.... domain=.divisionA.com
Environment
Component: SMPLC
Feedback
