Java EE 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 http://Host1.Domain1.com:7001/app1/test1.html, a resource in Domain 1.

   The Java EE policy agent intercepts the request and redirects to the OpenSSO Enterprise server login page.

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

3. The user provides the credentials and clicks Submit.

   A login form is posted to 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 includes a redirect to the original requested resource.

4. 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 policy agent allows the web container to serve the requested protected resource.

5. The user tries to access another resource http://Host2.Domain2.com:80/app2/test2.html in Domain 2.

   1. The SSO token is not sent in the HTTP request because the server Host2.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.

   3. The policy agent sets a cookie amFilterCDSSORequest to save the following:

      • The user-requested URL

      • Cookie access type, such as GET or POST

      • The value of the RequestID query parameter (AuthnRequestID)

      This cookie is set before redirecting to the OpenSSO Enterprise CDC servlet.

   Later, after getting the AuthnResponse from the CDC Servlet, the policy agent retrieves the information from the amFilterCDSSORequest cookie to continue with the user's originally requested URL. 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.

   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 form:

   s<20-digit hexadecimal string>.

   The AuthnRequestID is sent to the CDC Servlet so that the 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://agent-host:port/?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 (being sent) in UTC format.

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

   1. The SSO token is sent in the HTTP request because the server DNS 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 CDSSO Redirect URL on the policy agent. Example: http://Host2.Domain2.com:80/agentapp/sunwCDSSORedirectURI, based on the goto parameter earlier. The form's hidden field LARES is an encoded Liberty-like AuthnResponse that contains the existing SSO Token in Domain1.com.

7. The browser automatically posts the form with LARES to http://Host2.Domain2.com:80/agentapp/sunwCDSSORedirectURI without user interaction.

   1. The policy agent responds by setting a new SSO token with the cookie domain value set as the policy agent's fully qualified host name. Also note the cookie value is exactly the same as the one set in Step 3 response by OpenSSO Enterprise server.

   2. The HTTP response also redirects the browser to the original requested resource http://Host2.Domain2.com:80/app2/test2.html.

   3. In responding to this request, the policy agent goes through the following steps to validate the received AuthnResponse:

      1. First the requestID, saved in the amFilterCDSSORequest cookie, is verified against the responseID of the AuthnResponse.

      2. The status code of the AuthnResponse is verified to see if it is successful.

      3. The assertion is extracted from the AuthnResponse. There should be only one AuthnResponse.

      4. From the Assertion, the issuer is extracted and is verified against the policy agent list of trusted ID providers.

         If the issuer is not in the policy agent trusted list, then user request is blocked. These trusted ID providers are governed by the property com.sun.identity.agents.config.cdsso.trusted.id.provider[x]. See Configuring CDSSO and Cookie Hijacking Prevention. These IDs should contain URLs of the actual OpenSSO Enterprise instances, and should not contain the URL of the load balancer.

      5. The conditions that are in the assertion are also validated.

         The main condition is the date validity condition. The date validity attributes (NotBefore and NotOnOrAfter) are verified to be sure the assertion has not expired. So time synchronization between the OpenSSO Enterprise server and the policy agent is essential. The skew factor provided in the policy agent profile com.sun.identity.agents.config.cdsso.clock.skew also helps to overcome any network latencies.

      6. In the response, cookie amFilterCDSSORequest is removed by setting the expiration date in the past.

8. The browser follows the redirection to access the protected resource again at http://Host2.Domain2.com:80/app2/test.html.

   1. The new SSO token is sent to the policy agent.

   2. The policy agent validates the SSO token and evaluates the policies.

   3. The policy agent, upon successful validation, responds with the content of the protected resource.