test

Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Understanding Typical Business Use Cases

This section describes actual protocol exchanges in four business use cases:

All use cases are based on the same configuration:

The following figure illustrates the configuration used for all four business use cases.

Figure 16–6 Configuration for Business Use Cases

Process flows from Browser to Policy Agent 1 in Domain 1 and to Policy Agent 2 in Domain 2.

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.

Java EE Policy Agent Use Case 2: Accessing a Protected Resource in a 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 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 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 OpenSSO Enterprise server DNS domain matches the cookie domain.

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

    The page contains an HTML form which is automatically posted to CDSSO Redirect URL on the policy agent http://Host2.Domain2.com:80/agentapp/sunwCDSSORedirectURI. 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/agentapp/sunwCDSSORedirectURI with no user interaction.

  8. 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. The HTTP response also redirects the browser to the original requested resource http://Host2.Domain2.com:80/app2/test2.html.

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

    1. The second 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.

  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.

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.

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.