Siteminder Cookie Provider

A Siteminder cookie provider is designed to allow Single Sign-On (SSO) when multiple domains exist in an environment. The cookie provider is required due to the behavior of cookies (used to hold session information) based on the HTTP specification. Basically a cookie provider re-formats a cookie so that it is valid in a domain other than where it originated - meaning it helps SSO authentication in a cross-domain environment.

To invoke cookie provider functionality, the cookie provider URL is entered into a web agent's configuration. This tells the web agent to redirect to the specified URL (in the "master cookie provider" domain) when checking to see if the user needs to provide credentials. For example, if the user is attempting to access a protected resource in the .a.com domain, and no SMSESSION cookie exists for that domain in the browser, redirection to the specified Cookie Provider URL will occur to see if an SMSESSION cookie has been set in that domain (e.g. .b.com). All redirections are standard 302 redirects issued to the browser and built by the agent. It is necessary to redirect the browser to the "master" domain because under the HTTP specification, a cookie may only be set for the domain of the resource (thus, a user accessing a resource in the .a.com domain cannot present or have set a cookie in the .b.com domain).

All cookies are set in the user's browser - cookies are stored on the client side, not the server side. The redirection to the master cookie provider domain causes the user to access a different domain and thus be able to access cookies previously set for that domain. If a cookie exists for the master cookie provider domain, then the web agent acting as a cookie provider puts that value into a query string on the URL and redirects back to the original domain, allowing the cookie to be set in the original domain as well. Similarly, if a user logs in at a protected resource in .a.com, a redirect to the master cookie provider domain (.b.com) with the SMSESSION cookie in the query string allows the cookie provider web agent to set the SMSESSION cookie for the cookie provider domain (allowing SSO with any other agents for other cookie domains with the .b.com cookie provider URL specified). The SMSESSION cookie is encrypted, so passing it on the query string is not a security risk.

At login time, if no SMSESSION cookie exists for the local domain, redirection via the cookie provider URL allows a check to see if the browser contains an SMSESSION cookie for the master cookie provider domain. If no SMSESSION cookie exists there as well, a redirect back to the original protected resource occurs with SMSESSION=NO appended to the URL's query string. If an SMSESSION cookie exists, the redirection instead will carry SMSESSION=&ltvalue of SMSESSION cookie>.

During the login process, the SMSESSION cookie is created at authentication time. When the SMSESSION cookie is created, if a Cookie Provider URL is defined for the agent, redirection to the Cookie Provider URL will occur with the SMSESSION cookie carried in the query string. The web agent acting as a cookie provider take the SMSESSION cookie value from the query string and uses it to create an exact copy of the original SMSESSION cookie for the cookie provider domain (note: all cookies are stored locally in the user's browser).

Cookie Providers in general work the same for SiteMinder 4.x and 5.x agents. For more information, please see the section titled "Implementing Single Sign-On Across Multiple Cookie Domains" in Chapter 4 of the SiteMinder Agent Guide, v5.x QMR5 (there is a similar section in the 4.x Agent Guide as well).

If a cookie provider web agent becomes unavailable for any reason, it may cause an outage for any agents configured to redirect to that agent via the Cookie Provider URL. Therefore, it is important in a production environment to implement a high availability solution. Just like any other web agents, cookie providers generally are made highly available through the use of network devices, such as load balancers. The load balancer is responsible for making sure that requests are not sent to unavailable servers. It is possible to use these network devices because all web agent behavior, such as that used during cookie provider access, follow the HTTP specification (302 redirects, cookie creation). Instead of setting the Cookie Provider URL to point to a specific web server, the URL would point to the network device, which would distribute the requests among multiple (abstracted) web agents - for example, the load balancer could be www.b.com, while the agents / servers behind the load balancer would be 1.b.com, 2.b.com, and 3.b.com.

Please note that it is not suggestible to use load balancers or other such devices between the Web Agent and the Policy Server or the Policy Server and directory servers. There is functionality built-in to SiteMinder to provide round-robin and failover capabilities for those connections.

Steps for Below mentioned Secnario:

Multiple Domain SSO (no existing SMSession Cookies):

1.User requests a protected resource in the A.com cookie domain. The user browser does not have any SMSession Cookies for the A.com domain.

2.Because no SMSession Cookie is provided with the request, the user is redirected, as defined on the SM agent, to the cookie provider in the B.com domain.

3.If the cookie provider does not receive an SMSession Cookie for the B.com domain, it sends a redirect back to the web server in A.com with SMSession=NO in the query string.

4.Receiving SMSession=NO triggers the SM agent to authenticate the user per the authentication method associated with the originally requested resource. An SMSession Cookie is created but NOT set in the user browser.

5.The user is redirected back to the cookie provider, this time with the SMSession Cookie in the query string. The cookie provider now knows the user has been authenticated.

6.The cookie provider makes a copy of the SMSession Cookie received in the query string and sets it on the browser as the SMSession Cookie for B.com. 

7.The cookie provider then redirects the user, with the SMSession Cookie in the query string, back to the web server in A.com.

8.This triggers the SM agent to set the SMSession Cookie for A.com.  The browser now has two SMSession Cookies, one for the A.com domain and one for B.com.

9.The user is redirected to the originally requested protected resource.

a.See step 1.

10.The user requests the protected resource and provides the SMSession Cookie for the A.com domain. The request is now forwarded to the authorization phase.

●

Now that the user has SMSession Cookies for both the A.com and B.com domains, they can navigate seamlessly between the domains without having to re-authenticate.

Note the SMSession Cookies are exactly the same, the only difference is the associated domain. Also note that all communication between the web servers of different domains is facilitated through a series of redirects. There is no back-channel communication between the web servers themselves.