Overview of OpenSSO Enterprise Session Failover

• OpenSSO Enterprise Session Failover Components

• OpenSSO Enterprise Session Failover Flow

OpenSSO Enterprise Session Failover Components

A OpenSSO Enterprise session failover deployment scenario includes these components:

• Two or more OpenSSO Enterprise instances running on different host servers and configured as a site.

  To configure the OpenSSO Enterprise instances as a site, use one of these methods:

  • When you run the Configurator for the OpenSSO Enterprise instances, specify the same Site Name and load balancer Primary URL on the Site Configuration page for each instance. For information, see Configuring OpenSSO Enterprise With a Custom Configuration.

    or

  • If you did not configure the deployment as a site when you ran the Configurator, use either the Administrator Console or the ssoadm command-line utility to configure the OpenSSO Enterprise instances as a site.

• Load balancer for the OpenSSO Enterprise instances.

• Message Queue brokers, running in cluster mode on different servers.

• Oracle Berkeley DB client (amsessiondb) and database, running on the same servers as the Message Queue brokers.

  OpenSSO Enterprise uses the Oracle Berkeley DB Java Edition as the session data store. For information see http://www.oracle.com/database/berkeley-db/je/index.html.

• Client requests, which can originate from a Web browser, C or Java application using the OpenSSO Enterprise SDK, or a J2EE or web policy agent.

• OpenSSO Enterprise configuration data store (not shown in the figure):

  • Sun Java System Directory Server: All OpenSSO Enterprise instances must access the same Directory Server.

    or

  • OpenSSO data store: Instances must be configured for replication and act as a single directory server.

  The configuration data store must be running and accessible in the deployment.

• OpenSSO Enterprise user data store (not shown in the figure):

  • Sun Java System Directory Server

  • Microsoft Active Directory

  • IBM Tivoli Directory Server

  Note: The OpenSSO user data store is recommended only for prototype, proof of concept (POC), or developer deployments that have a small number of users. It is not recommended for production deployments.

The following figure shows a session failover deployment with three OpenSSO Enterprise instances. (The OpenSSO Enterprise configuration data store and user data store are not shown.)

Figure 7–1 OpenSSO Enterprise Session Failover Components

OpenSSO Enterprise Session Failover Flow

OpenSSO Enterprise session failover follows the Message Queue publish/subscribe delivery model:

1. When a user initiates, updates, or ends a session, the OpenSSO Enterprise instance publishes a session creation, update, or deletion message to the Message Queue broker cluster.

2. The Oracle Berkeley DB client (amsessiondb) subscribes to the Message Queue broker cluster, reads the session messages, and stores the session operations in the database.

The OpenSSO Enterprise instances communicate with each other using an internal routing mechanism. If an OpenSSO Enterprise instance goes down due to a single hardware or software problem, a user’s session associated with that instance moves to a secondary OpenSSO Enterprise instance, as follows:

1. The secondary OpenSSO Enterprise instance publishes a query request to the Message Queue broker cluster to get the user’s session information.

2. The Oracle Berkeley DB client (amsessiondb) receives the query request, retrieves the corresponding user entry from the session database, and then publishes the user’s session information to the Message Queue broker cluster.

3. The secondary OpenSSO Enterprise instance receives the response with the user’s session information from the Message Queue broker and continues the session, without losing any session information or requiring the user to login again.

If a Message Queue broker goes down, OpenSSO Enterprise continues to operate in non-session failover mode. When the Message Queue broker is later restarted, OpenSSO Enterprise returns to session failover mode.

For more information about the Message Queue components and the publish/subscribe delivery model, see the Sun Java System Message Queue 4.1 Technical Overview in the following collection:

http://docs.sun.com/coll/1307.3