Cross-Domain Single Sign-On Session

CDSSO occurs when an authenticated user requests a protected resource on a different server in a different DNS domain. The user in the previous sections, Basic User Session and Single Sign-On Session, for example, accessed applications in his company’s DNS domain. In the following example, the same user will log in to a benefits administration application supplied to his company by an external company. The benefits administration application is hosted on the external company’s DNS domain.

The CDSSO servlet within Access Manager transfers the user’s SSOToken into the external DNS domain, making the SSOToken usable for applications in this second domain. The CDSSO Controller Service uses Liberty Protocols to transfer sessions between domains.

When the user logs in to the benefits administration application in the external DNS domain, the following events occur.

1. The user’s browser sends an HTTP request to the benefits administration application.

2. The policy agent intercepts the request and inspects it to determine if a session token or SSOToken exists.

3. If a session token or SSOToken is present, the policy agent validates the session.

   In this example, the SSOToken is present. See Session Validation, then skip to Cross-Domain Single Sign-On Session.

4. If no session token or SSO token is present, the policy agent sends the HTTP request to the CDSSO Controller Service.

   The send includes the relevant Liberty parameters.

   

5. The user’s browser allows the redirect.

   This time the request contains the SSOToken. Recall that earlier in the user session (see Single Sign-On Session), the SSOToken was set in a cookie in the primary domain.

6. The CDC Servlet receives the SSOToken, and replies to the browser with a Liberty Post Profile response that includes user session information.

   1. The user’s browser automatically submits the form containing the Liberty document to the policy agent.

      The form is based upon the Action and the Javascript included in the Body tags onLoad.

   2. The policy agent receives the Liberty document and extracts the user session information.

7. The policy agent validates the SSOtoken.

   For detailed information, see Session Validation.

8. The policy service examines policies.

   For detailed information, see Policy Evaluation.

9. The policy agent allows or denies access to the requested resource.

   For detailed steps, see Results Logging. In this case, the session token was determined to be valid, and the user is allowed access.

10. The policy agent responds to the user by presenting the benefits administration application screen.

11. The policy agent sets the SSOToken in a cookie for the new DNS domain.

    The cookie can now be used by all agents in the new domain.

    The CDSSO session is valid until it is terminated.