How to correctly set up site with varying cookie domain scope like http://transpolar.com and http://www.transpolar.com?

Products

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

Issue/Introduction

Description:

This guide contains the following:

      An introduction to cookie domain scope
      Restrictions on Cooke Scope
      Machine vs Domain scope cookies
      How to set up a domain website  http://transpolar.com 
      How to SSO to the domain website
      How to SSO to the domain website from http://www.transpolar.com
 

The context for the explanation is the problem where the customer has a http://transpolar.com and http://www.transpolar.com site, access via Internet Explorer seems to work, but access from Firefox seems to authenticate, but then redirects the user back to the login page.

Solution:

Browser HTTP Cookie Basics

First a few relevant basics about cookies.

Cookie Domain Scope

When a user accesses a website that webserver can send a set-cookie request back to the users browser. On subsequent requests from the browser to that same website, the browser will then send those cookie values back to the webserver. For example:

In a request to http://login.transpolar.com/

we receive a:

set-cookie SMSESSION=XXX?ZZZ; domain=.transpolar.com

The webserver when sending the set-cookie back to the browser, can specify a domain, in this case ".transpolar.com" which then specifies that when the browser sends more requests to that webserver, that the cookie, here SMSESSION, should be sent with those subsequent requests.

So the request above:

where we receive a:

            set-cookie SMSESSION=XXX?ZZZ; domain=.transpolar.com

Then for all future requests made from the browser to any webserver in the .transpolar.com domain; and that will include requests to webservers: http://login.transpolar.com; http://www.transpolar.com and http://www.app1.transpolar.com then the browser will send the SMSESION cookie to the server with the new request.

Restrictions on Cookie Domain Scope

A browser will not allow a webserver in one domain to set a cookie for another domain. When receiving a set-cookie request from a webserver the browser restricts the domain scope to that of the webserver. For example:

In a request to http://login.ca.com/

if we receive a:

  set-cookie SMSESSION=XXX?ZZZ; domain=.transpolar.com

Then the browser will reject the set-cookie request. The is mainly done for security, to stop one domain overwriting or setting cookies that will be sent to another domain.

Note: However from a SiteMinder perspective, if you have many virtual hosts on the same physical webserver, say http://www.transpolar.com and http://www.ca.com then you need to ensure that in the Agent Config Object you have not hardcoded your cookiedomain setting e.g.,:

    Agent Config Object: wa-both.com
           cookiedomain=.transpolar.com

That would mean that requests to http://www.ca.com would try and set an SMSESSION cookie for the domain .transpolar.com, which will be rejected by the browser.

The above can often happen, when a server originally serving one domain, is then expanded to add another virtual website, or when the domain of a corporate website changes, often a subsidiary moves to its own domain, or an internal division moves or merges internally.

Setting the ACO values:

  
    Agent Config Object: wa-both.com
         cookiedomain=""
         domainscope=0
  

Will mean that the domain part of the SMSESSION cookie will be determined from the HTTP request that was made. So in the above example, a request to http://login.transpolar.com/ will set a cookie in the .transpolar.com domain, and a request to http://login.ca.com will set a cookie in the .ca.com domain.

Machine vs Domain scoped cookies

When setting a cookie value, the cookie can be set to have either a domain or a machine based scope. If a domain is set then it will be sent to all machines in the domain, or if no domain is specified then it will only be sent back to that specific webserver. An example is probably the best way to explain it:

So, from before, when a browser receives a Set-Cookie command from a webserver it usually has the domain portion attached to it e.g.,

In a request to http://login.transpolar.com/

we receive a:

set-cookie SMSESSION=XXX?ZZZ; domain=.transpolar.com

Then for all future requests made from the browser to any webserver in the .transpolar.com domain such as http://login.transpolar.com; http://www.transpolar.com or http://www.app1.transpolar.com then the browser will send the SMSESION cookie to the server with the new request.

However if the Set-Cookie command does not have a domain setting, then that cookie will only be sent back only to the specific machine that sent the cookie.

In a request to http://login.transpolar.com/

if we receive a:

set-cookie SMSESSION=XXX?ZZZ; 

Then the SMSESSION cookie will be sent back only to requests to http://login.transpolar.com; and the SMSESSION will not be sent for requests to websites such as: http://www.transpolar.com or http://www.app1.transpolar.com.

Note: The Cookie specification requires the domain to contain the leading ".". However, if you send a set-cookie request back to the browser, with no leading "." such as:

         set-cookie SMSESSION=XXX?ZZZ; domain=transpolar.com

Then the result depends on the browser. Some versions of IE will accept the set-cookie and send the SMSESSION back to the server for requests to http://transpolar.com and to http://www.transpolar.com. But Firefox will convert the domain to the "correct" domain=.transpolar.com and will then send the cookie back only to the site http://www.transpolar.com but will not send it back to the site http://transpolar.com. - Obviously this can cause some confusion.

Setting up: http://transpolar.com (a Machine scoped cookie domain)

As the web increasingly got used for HTTP traffic the trend for web designers has been to do away with the www prefix, and just have the whole domain as the HTTP address. So the address http://transpolar.com became more popular to use than http://www.transpolar.com. This isn't quite how domains were designed to work. Originally, www.transpolar.com translated to the machine "www" in the domain ".transpolar.com". Nevertheless http://transpolar.com does work, but because of the HTTP protocol design it translates as the machine "transpolar" in the domain ".com".

So for cookies to work for http://transpolar.com they need to be machine scoped cookies.

In the webagent to set up a machine scoped SMSESSION cookie for http://transpolar.com you need the following WebAgent Configuration Object setting:

   Agent Config Object: wa-transpolar.com
         cookiedomain=NONE

This instructs the webagent not to send the domain= portion when sending the Set-cookie command back to the users browser. Requests to http://transpolar.com/ will set-cookies in the browser that will only be returned to subsequent requests to http://transpolar.com.

In setting up http://transpolar.com we will also need for the following cases:

1. A login page of: http://transpolar.com/siteminderagent/login.fcc and
2. A cookieprovider URL of http://transpolar.com/siteminderagent/SmMakeCookie.ccc.

That should be all you need to have a working http://transpolar.com website.

Note: In some SiteMinder versions there is an edit check for the UN/PW Auth scheme that requires you to enter a three part domain for the host name, to work around this you can do an smobjexport, hand edit the URL and then do an smobimport to load the value. You can also edit the LDAP or SQL entry directly to achieve the same effect if you have the knowledge to do that.

Single Sign On Setup using http://transpolar.com

If we want to use http://transpolar.com as the cookie domain for a SSO for a number of other domains then all we need is the normal cookie provider setup. For example, if we want http://www.ca.com to SSO using the http://transpolar.com domain then we need the following configuration:

The wa-transpolar.com agent set up remains the same.

Agent Config Object: wa-transpolar.com
     cookiedomain=NONE

And the wa-ca.com setup is as follows:

    Agent Config Object: wa-ca.com
         cookiedomain=".ca.com"
         cookieproviderURL=http://transpolar.com/siteminderagent/SmMakeCookie.ccc

Notice that since both agents need different cookiedomain settings they cannot be different virtual servers on the same web agent. Otherwise configuring additional SSO domains to use http://transpolar.com as their primary domain is identical to a normal SSO setup.

Note: I have included an explicit cookiedomain here on agent wa-ca.com, it is added for clarity of the example, but as mentioned previously, cookiedomain="" will work just well.

Single Sign On Setup for http://www.transpolar.com

A special case to consider, mainly because it is confusing, is where we want to have websites such as http://www.transpolar.com and have them share cookie sessions with the primary domain http://transpolar.com.

In fact these two do not share a common domain, and cookies set for http://transpolar.com will not be sent to the http://www.transpolar.com website. So we need to set up these two, as per the previous setup as SSO across multiple domains:

The wa-transpolar.com agent set up remains the same.

   Agent Config Object: wa-transpolar.com
        cookiedomain=NONE
  

And the wa-www-transpolar.com setup is as follows:

Agent Config Object: wa-www.transpolar.com
      cookiedomain=".transpolar.com"
      cookieproviderURL=http://transpolar.com/siteminderagent/SmMakeCookie.ccc

Again, as before notice that since both agents need different cookiedomain settings so they cannot be different virtual servers on the same web agent. Otherwise configuring http://www.trasnpolar.com is identical to other SSO domains.

Note: And Again, as before, for agent wa-www.transpolar.com a setting of cookiedomain="" will work just as well.

Cause of the Firefox Problem

Now that we have walked through the above setup, we have the context to explain why in the original problem IE would work but Firefox would not.

In the construction of cookies for domain http://transpolar.com, IE was also setting them for ".transpolar.com" (due to the "bug" mentioned previously) so the SMSESSION cookie was accepted both by request to http://transpolar.com and to http://www.transpolar.com.

However for Firefox, the construction of cookies for http://transpolar.com was only setting them for http://transpolar.com and they were not being sent to http://www.transpolar.com so access to the secound site, would keep sending you back to the login page.

Appendix A

Summary of ACO cookiedomain values:

• cookiedomain=NONE # SMSESSION domain set to machine name "transpolar.com"
• cookiedomain="" # SMSESSION domain set based on host in request ".transpolar.com" or ".ca.com"
• cookiedomain=".transpolar.com" # SMSESSION set to ".transpolar.com"
• cookiedomain="transpolar.com" # SMSESSION set to "transpolar.com" - but actually not legal syntax, and causes different response in difference browsers.

Environment

Release:
Component: SMPLC