CA Single Sign-On Tech Tip by Sau Lai Wong, Senior Support Engineer for 9th April 2015
OVERVIEW
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:
a. A user requests a protected resource in a domain within the single-sign on environment, and is challenged for credentials.
b. 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.
c. 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).
However, it is advisable not to use the cookie provider Web Agent to host the login page to ensure that local cookie and cookie provider cookie are updated accordingly upon authentication.
USE CASE
- Setup Web Agent A on the webserver with abc.com cookie domain.
- Setup another Web Agent B on the webserver with ca.com cookie domain.
- Allocate Web Agent A to host the login page and be the cookie provider, while allocate Web Agent B to host the protected resources.
- With a new browser session, user John attempted to access the protected resource on ca.com. Request is redirected to the login page hosted on Web Agent A. Once John is authenticated, he has both new abc.com and ca.com cookie domain cookies in his browser session.
- User clicks “Back” from the browser session and landed on the login page.
- With the same browser session, user Jane attempted to login. Once she is authenticated, she has an updated abc.com cookie domain cookie. However, when she navigates to the protected resource, she is getting John’s session.
ANALYSIS
In the above use case, John has both SMSESSION cookies from ca.com and abc.com cookie domains. When Jane (using the same browser session) clicks “Back” and login, the user is logging in through cookie provider’s agent. Upon authentication, new cookie provider cookie overwrites the existing abc.com cookie. When Jane continues to navigate to the other domain (ca.com), previously created SMSESSION cookie from ca.com is still valid. Hence, Jane is accessing the application with John’s cookie.
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 when checking to see if the user needs to provide credentials.
When user login through the cookie provider’s agent, the Web Agent is not aware of other cookie domains. Hence, it will only create or update cookie provider cookie.
RESOLUTION
When there are only 2 cookie domains:
The above security breach can be avoided by selecting an agent that is not hosting the login page to be your cookie provider. This way user will get both cookie provider and local domain cookies upon authentication.
When there are more than 2 cookie domains:
You can customize the login page to perform comprehensive log out for a clean user session.
Customization steps:
1. Customize the login page to include separate frames (or iframes) for the other cookie domains "logoffuri" in your SSO environment. These frames do not need to be visible on the page as long as they are accessed.
2. For each frame, add a hyperlink to the Logoff Uri of the associated cookie domain. For example, if you have two other cookie domains, 123.com and 456.com:
3. Update the LogoffUri ACO parameter with the URI -- "/logoff.html". When the web server loads this login page, the frames in the login page call the logoff pages from the other cookie domains. The user is logged off from all the cookie domains at once.