About ACO Parameter TrackSessionDomain, I would like to know:
What is exact utility of TrackSessionDomain?
As per CA documentation:
"The Web Agent compares the intended domain stored within the session cookie against the domain of the requested resource. If the domains do not match, the Web Agent rejects the request."
- Would the "domain of requested resource" in this above line be based on DNS of resource or CookieDomain of SMSESSION?
- Setting TrackSessionDomain as yes, while creating SMSESSION would WebAgent also include CookieDomain as a parameter in SMSESSION's encrypted value?
- How does WebAgent make use of TrackSessionDomain parameter?
- Can the above mentioned scenario of WebAgent only accepting cookies as per its own ACO parameter of CookieDomain/CookieDomainScope be achieved via TrackSessionDomain?
- Would we get some additional details in webagent trace when this parameter is effective?
Here are the answers:
- The TrackSessionDomain is based on the DNS response of the requested resource for the domain.
- If cookie domain exists, it is set in TARGETH. If cookie domain is blank, that means cookie will be valid for current host only.
- While generating SiteMinder SMSESSION cookie, if "TrackSessionDomain" is set to yes, Web Agent encrypts and stores the intended domain of a session cookie within the SMSESSION cookie itself, in the TARGETH parameter. If "TrackSessionDomain" is set to no, the TARGETH is left as empty.
When this SMSESSION cookie is presented for subsequent requests, the Web Agent processing the SMSESSION cookie, looks for TARGETH. If TARGETH is not empty, Web Agent tests its value against domain of the requested resource. If TARGETH is empty, domain check does not happen.
While validating the cookie domain inside the cookie, the TARGETH value is compared against the last n characters of the actual domain of the request where n equals the length of the TARGETH value.
TARGETH = .server.a.com - Cookie Domain = .server.a.com Accepted
TARGETH = .a.com - Cookie Domain = .server.a.com Accepted
TARGETH = .server.a.com - Cookie Domain = .a.com Rejected
- If cookie domain exists, it is set in TARGETH. If cookie domain is blank, that means cookie will be valid for current host only. Web Agent Guide explains how cookie domain is affected with ACO parameters CookieDomainScope and CookieDomain.
"The CookieDomain parameter defines the cookie domain of the Web Server where you installed the Web Agent, such as netegrity.com.
You specify the cookie domain during the Web Agent installation. You can modify the domain, if necessary. This value is case-sensitive. Note the following when setting this parameter:
If you set CookieDomain to none, it forces the Web Agent to generate cookies only for the web server hosting the Web Agent.
These are server-only cookies. For example, myserver.netegrity.com.
If you leave CookieDomain blank or set it to double quote marks ("") in the local configuration file, the Web Agent gets the cookie domain from the HTTP_HOST header then bases the value on the CookieDomainScope parameter.
When the CookieDomainScope parameter is set to 0, the default, the Agent chooses the most specific cookie domain for the host without making a server-only cookie. This means that the cookie domain myserver.netegrity.com yields a domain of netegrity.com, and myserver.metals.ne.com yields a domain of .metals.ge.com. If the CookieDomainScope parameter is set to 2, the cookie domain would be .netegrity.com and .ne.com respectively.
If you set the CookieDomain parameter to a specific domain, such as .netegrity.com, that is the domain the Web Agent uses."
(Web Agent Guide)
- You will get following in the log, for e.g.:
[04/15/2010][12:18:59][a86df145-2d50-4bc73c73-0041-575c29b7][CSmHttpPlugin::ProcessSessionCookie] [SMSESSION cookie - resolved domain name does not match TARGETH '.smidp.nam.nsroot.net'.]