Analyzing the Deployment Architecture

Figure 17–1 illustrates the components you need for basic system failover and session failover in an OpenSSO Enterprise deployment. Key components in this high availability deployment are:

• Multiple OpenSSO Enterprise Policy Agents serve as backups when system failure occurs.

• A single load balancer distributes the workload among multiple OpenSSO Enterprise Policy Agents. This increases transaction throughput, and ensures failover when a system failure occurs.

• Multiple OpenSSO Enterprise servers with respective embedded Directory Servers act as backups when system failure occurs. Embedded Directory Servers ensure that replicated configuration data is always available even during system failure.

• Multiple load balancers distribute the workload among multiple OpenSSO Enterprise servers. This increases transaction throughput, and ensures failover when system failure occurs. Additionally, the Policy Agents can be configured to failover among OpenSSO Enterprise server load balancers when system failure occurs.

• When OpenSSO Enterprise is configured for session failover, a Java Message Queue Broker Cluster replicates session data and stores it in the Berkeley Database. When a system failure occurs, the replicated session data is made available to Policy Agents so that the end-user does not lose data and does not have to re-authenticate after system recovery.

• Multiple Berkeley Databases are used to store session data, and are configured for session failover. If one Berkeley Database fails, the working Berkeley Database can provide session data to the OpenSSO Enterprise servers for session validation.

In all examples in this chapter, load balancers represent the only access points to OpenSSO Enterprise servers. An access point can be any hardware or software that acts as a load balancer, and is associated with a site, that is installed in front of OpenSSO Enterprise servers. Policy Agents interact with OpenSSO Enterprise servers through these access points.

The following figure illustrates the components required for basic system failover and session failover in a single-site deployment.

Figure 17–1 Basic OpenSSO Enterprise High Availability Deployment Architecture

Understanding a Typical High-Availability Transaction

In any transaction, OpenSSO Enterprise must determine three things:

1. Is a valid user session token present?

2. Is the user authenticated?

3. Is the user authorized?

At any time during the transaction, if the OpenSSO Enterprise server or the OpenSSO Enterprise Policy Agent is unable to access the information required to determine these three things, then system failover or session failover may occur.

Figure 17–2 illustrates the first part of a typical high-availability process flow. In the figure, a user attempts to access a protected resource and is successfully authenticated. No system failover or session failover occurs in this first transaction.

The second part of the process flow describes how sessions are handled during subsequent requests by the same user. This second part of the process flow is influenced by two factors:

• How OpenSSO Enterprise is configured for high availability

• Availability of load balancers and servers

The following figure illustrates a user's first request in a typical high-availability transaction. Process flows for subsequent requests by the same user are presented in detail, and discussed along with their respective configuration examples, in the following sections.

Figure 17–2 Process Flow for High Availability (part 1)