CDSSO Overview

This section describes the over functionality for CDSSO for both J2EE and Web Policy Agents.

J2EE Agent CDSSO

Based upon the appropriate HTTP protocols, an HTTP cookie will be presented to only a server in the DNS domain that is set in the cookie. A server may only set a cookie within their own domain. Hence, despite having a valid SSO token cookie in one domain, agent protected servers in other domains are never presented with this cookie. CDSSO overcomes the problem with coordinated work between two components:

1. On the Access Manager, Cross-Domain Controller (CDC) serlvet http(s)://am_host:port/amserver/cdcserlvet

2. On the J2EE agent: CDSSO Redirect Servlet http(s)://agent_host:port/agentapp/sunwCDSSORedirectURI

The CDSSO Redirect Servlet extracts the SSO Token sent by the CDC Servlet, and then sets the same SSO Token cookie again. This time the SSO Token is set with the agent DNS domain as the cookie domain. The purpose of CDSSO Redirect Servlet is to extract the SSO token sent by CDC Servlet and sets the same SSO token cookie again but with the agent DNS domain as the cookie domain. This process essentially duplicates the SSO token in the agent DNS domain from the Access Manager DNS domain.

In the example illustrated above, the Access Manager server resides in DNS Domain-1, and a Policy Agent/Protected Resource resides in DNS Domain-2. The following protocol illustrates the CDSSO process:

1. The user's browser attempts to access an Agent-protected resource in Domain-2.

2. With CDSSO enabled on this Agent, the Agent will redirect the browser to the cdcservlet on the Access Manager. Without CDSSO enabled, the Agent will normally redirect the user to Access Manager login URL for user login.

3. The browser follows the redirection and accesses the cdcservlet on the Access Manager.

4. At this time, the cdcservlet will need to determine if the ssotoken is valid and that the cookie is for Domain-1. The cdcservlet forwards the request to Access Manager for token validation.

5. Access Manager sends the response to the cdcservlet. If the ssotoken was found to be valid and a cookie present for Domain-1, then proceed to Step 11

6. Since the ssotoken is invalid or absent, the cdcservlet forwards the request to the Access Manager's Authentication Service. When this forwarding of the request is done, it does not involve the client browser. The request is forwarded to the servlet/jsp in the container.

7. The Authentication Service presents the user with the login form.

8. The user provides his credentials on the login page, clicks on the 'Submit' button. The credentials use a POST action to the authentication module.

9. If authentication is successful, the Authentication Service sets the ssotoken cookie for the Domain-1. The Authentication Service then redirects the browser back to the cdcservlet.

10. The browser follows the redirection and accesses the cdcservlet on the Access Manager. Now proceed to Step 4.

11. The CDC servlet retrieves the user's SSO Token for Domain-1, composes a Liberty-like AuthNResponse message (LARES) with the SSOToken wrapped inside. The LARES message is contained in a HTML FORM in the HTTP response page. The HTTP response page also contains the directives to automatically post the form without the user interaction to the Agent's sunwCDSSORedirect URI.

12. The browser, upon receiving the HTTP response, automatically posts the form to the Agent's sunwCDSSORedirect URI.

13. The Agent intercepts this request. Since it is sunwCDSSORedirect URI (part of URL that is intercepted by the Agent) the Agent determines that it is a response from cdcservlet and processes the CDSSO response. The Agent validates the ProviderID in the CDSSO response, by comparing it with the registered Providers. If the provider validation fails, the user will be denied access to the protected resource. If the provider validation is successful, the Agent extracts the SSOToken and sets the cookie for Domain-2. Now the Agent retrieves the original requested URL for the protected resource and does a redirect to it.

14. The browser receives the new cookie. Now the browser has two ssotoken cookies, they only differ in their cookie domains. One is for Domain-1 and another is for Domain-2. The browser follows the redirection to the protected resource, presenting the new SSO token.

15. The Agent intercepts the request for the protected resource, and requests Access Manager to validate the ssotoken.

16. The Access Manager determines if the ssotoken is valid and the cookie is present for Domain-1. The Access Manager sends it's response to the Agent. If the ssotoken was evaluated to be invalid or absent, then proceed to Step 2.

17. Since the ssotoken was evaluated to be valid, the Agent next requests Access Manager for the policy decision as pertaining to the protected resource.

18. The Agent receives the policy decision from Access Manager, and evaluates it to determine if the user should be allowed or denied access to the protected resource. Based on the policy evaluation, the Agent enforces the policy.

19. If the policy evaluation resulted in denying access for the user, the user will see a message to that effect in the browser and not be able to access the protected resource. if the policy evaluation resulted in allowing access to the user, the user will be shown the protected resource.

In step 13 above, the current J2EE policy agent implementation sets an SSO token cookie without a domain. Per cookie protocol, this means the cookie will be presented only when accessing the server where the J2EE policy agent reside. The cookie will not be presented to any other servers in the same domain.

The following diagram illustrates the sequence of the steps described in the previous section:

Web Policy Agent CDSSO

Web Policy Agent works similarly as the J2EE Policy Agent, except for a slight variance. No CDSSO Redirect Servlet exists on the web policy agent because the agent is a NSAPI plugin. Instead, the web policy agent is invoked via a URL parameter called sunwMethod. As a result, the web policy agent combines the above steps 13-16 into a single step without the extra redirection in Step 14. For more details, please refer to the section "Web Policy Agent Sample Protocol Exchange" in this document.