test

Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0

1.3 Sequential Component Interactions

The following sequence describes the interactions between the various components in this deployment. The interactions are illustrated and the numbered steps correspond to the numbers in the diagrams.

  1. A user attempts to access a J2EE application hosted on both Protected Resource 1 and Protected Resource 2.

    Request goes through Load Balancer 5 to J2EE Policy Agent 1 to Distributed Authentication User Interface for authentication.

  2. Load Balancer 5 directs the user to Protected Resource 1 where J2EE Policy Agent 1 intercepts the request.

  3. J2EE Policy Agent 1 checks for an OpenSSO Enterprise cookie (SSOToken). In this scenario, no cookie is found and the request is returned to the browser which redirects the request to Load Balancer 3, the load balancer for the instances of the Distributed Authentication User Interface.

  4. Load Balancer 3 routes the user request to Distributed Authentication User Interface 2.

  5. Distributed Authentication User Interface 2 displays a login page to the user.

  6. The user enters credentials on the login page which are returned to Distributed Authentication User Interface 2.

  7. Distributed Authentication User Interface 2 passes the credentials to Load Balancer 2.

    Credentials are passed through a load balancer to OpenSSO Enterprise 1 and Directory Server 2 for authentication.

  8. Load Balancer 2 routes the credentials to OpenSSO Enterprise 1.

  9. OpenSSO Enterprise 1 sends a request for validation of the credentials to Load Balancer 1 in front of the Directory Server instances.

  10. Load Balancer 1 routes the request to Directory Server 2.

  11. Authentication occurs using the Distributed Authentication User Interface. Assuming successful authentication, OpenSSO Enterprise Distributed Authentication User Interface 1 sends the response back to J2EE Policy Agent 1 which receives the request and checks again for the OpenSSO Enterprise cookie.

    Response is returned, session is validated, policy request is sent and access is allowed.

  12. When a cookie is found, J2EE Policy Agent 1 sends a session validation request to the OpenSSO Enterprise Load Balancer 2.

  13. The OpenSSO Enterprise Load Balancer 2 forwards the request to OpenSSO Enterprise 1 where the session originated. Cookie-based persistency enables proper routing.

  14. OpenSSO Enterprise 1 sends a response back to J2EE Policy Agent 1.

    1. If the session is not valid, J2EE Policy Agent 1 redirects the user back to Distributed Authentication User Interface 2.

    2. If the session is valid, J2EE Policy Agent 1 receives the response and sends a request for policy evaluation to Load Balancer 2.

  15. As the session is valid, the request is directed to OpenSSO Enterprise 1 to conduct the policy evaluation.

  16. Based on the outcome of the policy evaluation, J2EE Policy Agent 1 allows or denies access to the resource. In this scenario, the user is allowed access.