Cross-Domain Single Sign-On Session

CDSSO occurs when an authenticated user requests a protected resource on a 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 one DNS domain. In this scenario, the CDSSO Controller within OpenSSO Enterprise transfers the user’s session information from the initial domain, making it available to applications in a second domain.

The basic difference between the proprietary CDSSO and SAML v2 (as described in Federation Options) is that CDSSO uses a single authentication authority, a mechanism to move a cookie between multiple DNS domains. SAML v2, on the other hand, gives you the option of using multiple authentication authorities, with one authority asserting the identity of the user to the other.

1. The authenticated user’s browser sends an HTTP request to the application in a different DNS domain.

2. The policy agent intercepts the request and inspects it to determine if a session token exists for the domain in which the requested application exists. One of the following occurs:

   • If a session token is present, the policy agent validates the session.

   • If no session token is present, the policy agent (which is configured for CDSSO) will redirect the HTTP request to the CDSSO Controller.

     The CDSSO Controller uses Liberty Alliance Project protocols to transfer sessions so the relevant parameters are included in the redirect.

   In this example, no session token for the second domain is found.

3. The policy agent redirects the HTTP request to the CDSSO Controller.

4. The user’s browser allows the redirect to the CDSSO Controller.

   Recall that earlier in the user session the session token was set in a cookie in the first domain which is now part of the redirect.

5. The CDC Servlet (in the CDSSO Controller) receives the session token from the first domain, extracts the user's session information, formulates a Liberty POST profile response containing the information, and returns a response to the browser.

6. The user’s browser automatically submits the response to the policy agent in the second domain.

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

7. The policy agent in the second domain receives the response, extracts the session information, validates the session, and sets a session token in the cookie for the new DNS domain.

The process continues with Policy Evaluation and Enforcement and Logging the Results. Based on the policy outcome, the user is granted or denied access to the application.

1. If the user is denied access, the policy agent displays an “access denied” page.

2. If the user is granted access, the protected resource displays its access page. The new cookie can now be used by all agents in the new domain, and the session is valid until it is terminated.