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 travel administration application supplied to his company by an external company. The travel administration application is hosted on the external company’s DNS domain. In this scenario, the CDSSO Controller Service within Access Manager transfers the user’s session information from the initial domain, making the it available to applications in this second domain.

When the user logs in to the travel administration application in the external DNS domain, the events in the following illustration occur. The process is described in the accompanying text.

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

2. The policy agent intercepts the request and inspects it to determine if a session token exists for the domain in which the travel administration 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) redirects the HTTP request to the CDSSO Controller Service.

     ---

     Note –

     The CDSSO Controller Service 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 Service.

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

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

5. The CDSSO Controller Service's CDC Servlet receives the session token from the initial domain, extracts the user's session information, and formulates a Liberty POST profile response containing the information. The response is returned to the browser.

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

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

   For detailed information, see Session Validation.

8. The process continues with policy evaluation and results logging.

   See the following sections for detailed information.

   • Policy Evaluation and Enforcement

   • Logging Results

9. The policy agent allows or denies the user 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 resource displays its access page.

Assuming proper authorization, the policy agent responds to the user by presenting the travel administration application screen. This new cookie can now be used by all agents in the new domain, and the session is valid until it is terminated. (See Session Termination.)