Previous Topic: Agents and Password ServicesNext Topic: How to Configure Single Sign-On

Web Agent Guides › Web Agent Configuration Guide › Single Sign-On (SSO)

Single Sign-On (SSO)

This section contains the following topics:

Allow Automatic Access to Resources that use the OPTIONS Method

How Single Sign-on Works in a Single Domain

Single Sign-On Across Multiple Domains

Hardware Load Balancers and Single Sign-On Across Multiple Cookie Domains

Single Sign-On and Authentication Scheme Protection Levels

Single Sign-on and Agent Key Management

How to Configure Single Sign-On

Allow Automatic Access to Resources that use the OPTIONS Method

The CA 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:

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 CA 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.

How Single Sign-on Works in a Single Domain

CA SiteMinder® provides single sign-on functionality across single and multiple cookie domains. This simplifies using applications across different Web servers and platforms, and improves the user experience because the users do not have to re-authenticate as they move across a single sign-on environment.

A single domain is an environment where all resources exist in the same cookie domain. Multiple Web Agents in the same cookie domain can be configured for single sign-on if you specify the same cookie domain in each Web Agent’s configuration.

If single sign-on is enabled, it uses the following process:

  1. The user authenticates once.
  2. The Web Agent caches the successful authentication, and then issues a single sign-on cookie to the user’s browser.
  3. The single sign-on cookie provides the session information, so that users can access the following types of resources without reauthenticating:

    Users who try to access resources with a higher protection level must re-authenticate before they are granted access.

The following illustration shows single sign-on in a single cookie domain:

Illustration showing the process of single sign-on in a single cookie domain

Note: 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 Across Multiple Domains

Without single sign-on, users are often required to log on and enter their credentials multiple times as they access different applications and resources on separate servers in different cookie domains. The ability to pass single sign-on information across multiple cookie domains enables a user to authenticate at a site in one cookie domain, and then go to a site in another cookie domain without being rechallenged for credentials. For the user, this seamless navigation makes related sites easier to use.

The following illustration shows single sign-on across multiple cookie domains.

Graphic showing how users who authenticate to one domain can go to another without being re-challenged for their credentials

Hardware Load Balancers and Single Sign-On Across Multiple Cookie Domains

CA SiteMinder® implements single sign-on across multiple cookie domains using a CA 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.

CA 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:
  3. The user can navigate between the domains in the single-sign on environment without being rechallenged until either of the following events occur:

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:

Graphic showing Multiple Domains in an SSO Environment Using a Load Balancer In Front of the Domain Hosting the Cookie Provider

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: You do not have to use the same user directory to implement SSO across multiple cookie domains. However, if you are using replicated user directories with nonreplicated policy stores, name the user directory 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, CA SiteMinder® prompts the user to re-enter their credentials.

CA 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.

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 CA 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 CA SiteMinder® environment. Automated key changes make agent key management easy to implement for large CA SiteMinder® installations that share the same key store, which holds all the key information. Automating key changes also ensures the integrity of the keys.