Web Policy Agent Use Case 2: Accessing a Protected Resource in the Non-Primary Domain First

In this use case, an unauthenticated user first accesses a protected resource in the DNS Domain 2, the non-primary domain. The user then accesses a protected resource in the primary domain DNS Domain1.

1. An unauthenticated user attempts to access a resource in the non-primary domain, Domain 2. Example: http://Host2.Domain2.com:80/app2/test2.html.

2. The policy agent intercepts the request and receives no SSO Token.

   Because CDSSO is enabled, the policy agent responds with a redirection to the OpenSSO Enterprise CDC servlet URL https://serverHost1.Domain1.com:8443/opensso/cdcservlet.

3. The browser follows the redirection to access the CDC servlet without any SSO token. The CDC servlet responds with a login page.

4. The user types his credentials on the login page and clicks Submit.

   A login form is posted to the OpenSSO Enterprise server.

   1. If the user authenticates successfully, the OpenSSO Enterprise server responds by setting an SSO token in Domain1.com.

   2. The response also redirects the browser back to the CDC servlet https://serverHost1.Domain1.com:8443/opensso/cdcservlet.

5. The browser follows the redirection to access the CDC servlet again.

   This time the SSO token is sent in the HTTP request because the server DNS domain matches the cookie domain.

6. The CDC servlet validates the SSO Token and responds with an HTML page.

   The page contains a HTML form which is automatically posted to the policy agent http://Host2.Domain2.com:80/app2/test2.html?sunwMethod=GET.

   This is derived from the goto and target parameters. The form's hidden field LARES is an encoded Liberty-like AuthnResponse that contains the existing SSO Token in Domain1.

7. The browser automatically posts the form with LARES to http://Host2.Domain2.com:80/app2/test2.html?sunwMethod=GET with no user interaction.

8. The policy agent validates the AuthNResponse, and responds by setting a second SSO Token. The second SSO token domain is the policy agent's fully-qualified host name. The cookie value is identical to the cookie value set by the OpenSSO Enterprise server in step 4.

9. The policy agent performs necessary session validation and policy evaluation. If the session is validated, and the policy evaluation succeeds, then the user is allowed access and the protected page is served in response.

10. The user now attempts to access a resource in the primary domain, Domain 1. Example: http://Host1.Domain1.com:7001/app1/test1.html.

    An SSO Token is sent with the HTTP request. The browser now has two SSO Tokens, one for each domain. The sent token was obtained in Step 4.

11. The policy agent intercepts the request and receives the SSO Token.

    The policy agent validates the token and permits the server to serve the content of the protected page.