Web Policy Agent Use Case 1: Accessing a Protected Resource in the Primary Domain First

In this use case, an unauthenticated user first accesses a resource under Policy Agent 1 in the DNS Domain 1, the primary domain. After the authentication, the OpenSSO Enterprise sets an SSO token in Domain 1. Then the user accesses another resource under Policy Agent 2 in DNS Domain 2, a non-primary domain. The CDSSO sequence is invoked and access is allowed without re-authentication.

1. An unauthenticated user attempts to access a resource in Domain 1. Example: http://Host1.Domain1.com:7001/app1/test1.html.

2. The Web policy agent intercepts the request and receives no SSO Token. The policy agent responds with a redirection to the OpenSSO Enterprise login page.

3. The browser follows the redirection to access the OpenSSO Enterprise login page.

4. The user provides the credentials and clicks Submit.

   A login form posted to the OpenSSO Enterprise server.

   • If the user is not authenticated successfully, the server responds by displaying an “Access Denied” message.

   • If the user authenticates successfully, the server responds by setting an SSO token (represented by the iPlanetDirectoryPro cookie) in Domain 1. The response also includes a redirect to the original requested resource http://Host1.Domain1.com:7001/app1/test1.html.

5. The browser follows the redirection to access http://Host1.Domain1.com:7001/app1/test1.html.

   1. The SSO token is sent in the HTTP request to the server.

   2. The policy agent validates the SSO token and evaluates policies by interacting with the OpenSSO Enterprise server in the background. If access is denied, the policy agent displays an “Access Denied” message. If access is allowed, the server responds with the content of the protected resource.

6. The user tries to access another resource in the non-primary domain, Domain 2. Example: http://Host2.Domain2.com:80/app2/test2.html.

   1. The SSO token is not sent in the HTTP request because the policy agent domain Domain2.com does not match the cookie domain Domain1.com.

   2. The policy agent, receiving no SSO token, responds by redirecting the browser to the CDC servlet URL https://serverHost.Domain1.com:8443/opensso/cdcservlet.

   The redirection URL contains some parameters to be carried to the CDC servlet. Some of these parameters are:

   goto

   The URL to which CDC servlet will forward AuthNResponse.

   This is the originally requested URL with the parameter sunwmethod=GET appended to it.

   MajorVersion

   The Liberty Federation Protocol major version. Set to 1 by default.

   MinorVersion

   The Liberty Federation Protocol minor version. Set to 1 by default.

   RequestID

   An AuthnRequestID.

   This is a uniquely generated ID. It uses the following form:

   s<20-digit hexadecimal string>.

   The AuthnRequestID is sent to the CDC Servlet so that its AuthnResponse later can contain this unique identifier. The RequestID is used to tie the response coming back. The RequestID is verified when the response comes back from the CDC servlet.

   ProviderID

   Identifies the provider, which is the policy agent. The value will be of the form: http(s)://agent-host:port/amagent?Realm=<RealmName> where RealmName is what is configured for the property com.sun.identity.agents.config.organization.name in the policy agent profile.

   IssueInstant

   The time at which the AuthnRequest was created in UTC format.

7. The browser follows the redirection to access the CDC servlet.

   1. The SSO token is sent in the HTTP request because the OpenSSO Enterprise server domain matches the cookie domain.

   2. The CDC servlet validates the SSO token and responds with an HTML page.

      The page contains an HTML FORM which will be automatically posted to the policy agent with no user interaction. Example: http://Host2.Domain2.com:80/app2/test2.html?sunwmethod=GET based on the goto parameter.

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

   1. The policy agent 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.

   2. The assertions are extracted from the AuthnResponse. There should only be one AuthnResponse.

   3. The policy agent also 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.