Web Agent Guides › Web Agent Configuration Guide › Single Sign-On (SSO) › Add a SiteMinder Wildcard Mapping to Protect IIS 6.0 Virtual Web Sites › Single Sign-On Across Multiple Cookie Domains

Single Sign-On Across Multiple Cookie Domains

SiteMinder implements single sign-on across multiple cookie domains using a SiteMinder Web Agent configured as a cookie provider.

The cookie domain where the cookie provider Web Agent resides is named the cookie provider domain. All the other Web Agents from the other cookie domains within the single sign-on environment, point to one cookie provider.

SiteMinder cookie providers work using the following process:

1. A user requests a protected resource in a domain within the single-sign on environment, and is challenged for credentials.
2. When the user is authenticated, the following cookies are set in the browser of the user:
   • The local cookie for the domain where the user has authenticated.
   • The cookie provider sets the cookie.
3. The user can navigate between the domains in the single-sign on environment without being rechallenged until either of the following events occur:
   • The session of the user times out.
   • The user ends the session (usually by closing the browser).

Will the Agents in your single-sign on environment use load-balancing?

All agents in an SSO environment must refer to a single cookie provider domain. Add a load-balancer between the web servers in your cookie provider domain and the other cookie domains in your SSO environment. The following illustration shows an example:

The Web Agent in the example.org cookie domain points and the Web Agent in the example.com cookie domain both point to the same cookie provider domain of example.net. A load-balancer distributes the traffic evenly between all the web servers in the example.net cookie provider domain.

Note: SSO across multiple cookie domains does not require that the same user directory be used across the SSO environment. However, if you are using replicated user directories with non-replicated policy stores, the user directory must be named identically for all policy stores. Also, the session ticket key, which encrypts session tickets, must be the same for all key stores in the SSO environment. The session ticket determines the duration of a valid user session.

Single Sign-On and Authentication Scheme Protection Levels

With single sign-on, authenticated users of one realm can access a resource in another realm without re-authenticating as long as the second realm is protected by an authentication scheme with an equal or lower protection level. If a user tries to access a resource protected by an authentication scheme with a higher protection level, SiteMinder prompts the user to re-enter their credentials.

SiteMinder lets administrators assign protection levels to authentication schemes with the Administrative UI. Protection levels range from 1 through 20, with 1 being the least secure and 20 being the most secure. These protection levels enable administrators to implement authentication schemes with an additional measure of security and flexibility for a single sign-on environment.

For example, a set of resources that is available to all users has a Basic authentication scheme with a protection level of 1. Another set of resources that should only be available to corporate executives, uses an X.509 certificate scheme with a protection level of 15. If a user authenticates with the Basic theme, then tries to access the resources protected by a certificate scheme, they will be required to re-authenticate.

Note: For more information, see the Policy Server documentation.

Allow Automatic Access to Resources that use the OPTIONS Method

The SiteMinder Web Agent still challenges authenticated users who attempt to access resources that use the OPTIONS method. Some examples of resources that use the OPTIONS method include (but are not necessarily limited to) the following:

• Microsoft^® Word documents
• Microsoft^® Excel^® spreadsheet documents

This challenge occurs because the application associated with the resource sends a request using the OPTIONS method to the web server. Because this request does not include a SiteMinder cookie, the Web Agent issues a challenge.

To prevent users from being challenged for these resources

1. Set the value of the following parameter to yes:

   autoauthorizeoptions

   Automatically authorizes any requests for resources which use the HTTP OPTIONS method.

   If you set the value of this parameter to yes, also set the value of the PersistentCookies parameter to no.

   Limits: yes, no

2. Set the value of the PersistentCookies parameter to no.

Track User Identity Across Anonymous Realms

When an anonymous user accesses resources, that user is assigned an SMIDENTITY (anonymous) cookie. When the user moves to another domain, the user is challenged, logs in successfully, and is assigned an SMSESSION (logged in) cookie.

As this user accesses protected and "anonymous" resources, that is, resources in a realm that do not require a user to present credentials, the user may enter a domain that contains both cookies for a user. For resources protected by Web Agents starting at 5.x QMR 3 , the Web Agent uses the SMSESSION cookie to identify the user, not the SMIDENTITY cookie.

If the user goes from a thoroughly upgraded domain to a domain where older Agents use the SMIDENTITY cookie to identify the user, the cookie used depends on the version of the Web Agent handling the request.

Regarding separate cookie domains, when a master cookie domain contains protected resources and a second domain contains anonymous resources, a user who does the following tasks continues to be treated as an anonymous user in the anonymous domain:

1. Accesses the anonymous domain first
2. Moves to the master domain and logs in
3. Moves back to the anonymous domain

Single Sign-on and Agent Key Management

Web Agents use keys to encrypt and decrypt cookies that pass information between Web Agents. When an Agent receives a SiteMinder cookie, the key allows the Agent to decrypt the contents of the cookie. Keys must be set to the same value for all Web Agents communicating with a Policy Server.

To ensure the keys remain secure, the Policy Server can generate these keys, encrypt them, and distribute them to all the Web Agents within a SiteMinder environment. Automated key changes make agent key management easy to implement for large SiteMinder installations that share the same key store, which holds all the key information. Automating key changes also ensures the integrity of the keys.