1.2 System Environment and Architecture

The following components comprise the system environment and architecture described in this document:

Network Connectivity

Although firewalls were not actually implemented when setting up this deployment example, in this environment the best practice is to use three firewalls which form three distinct security zones as illustrated in Figure 1–1. One zone would be completely secured, protected by all three firewalls, and would used for internal traffic only. Two minimally-secured zones, also known as DMZs, would be protected by only two firewalls. One minimally-secured zone would be used for internal traffic only, and the second minimally-secured would be used for external traffic. Direct access to individual Access Manager servers would be allowed for internal administrators only if permitted by firewall rules. For more information on specific firewall rules, see the section 2.4 Firewall Rules in this document.

Distributed Authentication UI servers

The Distributed Authentication UI servers provide a thin presentation layer for user authentication. The purpose of the Distributed Authentication UI servers is to protect the Access Manager servers from exposure in the minimally-secured DMZ. During user authentication, a Distributed Authentication Module passes the user's credential to the Access Manager server for verification. The user does not have direct network access to Access Manager servers.

Figure 1–1 System Architecture

Protected Resources

Protected resources are the Web Servers or Application Servers to which you want to restrict access. For example, your Human Resources Department might use Applications Servers to host applications and Web Servers to host content. Some of the hosted information must be made available to external benefits administration vendors. External vendors might include health care providers or stock administrators who must access employee information in order to coordinate benefits. The external vendors access the protected resources through an external-facing load balancer. Other information must be restricted to only internal Human Resources administrators. Internal administrators access the protected resources through an internal-facing load balancer.

J2EE Policy Agents and Web Policy Agents

Policy agents restrict access to content or applications hosted on the protected resources. The policy agents intercept HTTP requests from external users, then communicate with the Access Manager servers. If the user presents proper credentials and can be authenticated by the Access Manager server, Access Manager allows the user to access the protected resource. The policy agents are deployed with a load balancer in front of them.

Access Manager Servers

Two separate Access Manager servers provide core Access Manager functionality. Both servers share the same configuration. Both servers store their configuration through a single load balancer deployed in front of the two Directory Servers.

The Access Manager servers are hosted behind the internal firewall and outside the DMZ. The load balancer and two Access Manager servers together provide high data availability within the infrastructure.

Directory Servers

Two Directory Server instances provide the storage for Access Manager configuration information. This includes information about services, policies, and more. Both Directory Server data instances are master replicas that engage in multi-master replication (MMR). MMR allows data to be synchronized in real time between two directories. This synchronization provides high availability to the Access Manager layer.

Load Balancers

Load balancers in this environment enable system failover and high server availability for optimized performance. Multiple virtual load balancers in this deployment example were aggregated into a single unit of load balancing hardware.

Distributed Authentication UI Load Balancer

This external-facing load balancer exposes the remote, web-based Access Manager interface for user authentication, self-registration, and policy agent authentication.

Policy Agents Load Balancers

Policy agents are deployed with external-facing load balancers in front of them. The policy agents then communicate with Access Manager servers through an internal-facing load balancer.

Access Manager Load Balancer

This internal-facing load balancer exposes the web-based Access Manager administration console to internal administrators. Alternatively, internal administrators can also bypass the internal-facing load balancer and log in directly to an Access Manager administration console.

Directory Server Load Balancer

The load balancer in front of the Directory Servers provides round-robin load balancing for Directory Server access, and detects individual Directory Server failures and recovery. Failed servers are taken out of the load balancer list. The load balancer also provides a single virtual Directory Server host name to the Access Manager servers.

Message Queue Broker Cluster

In this deployment example, Access Manages uses two Message Queue instances to form a cluster. The cluster acts as a communications broker, and uses the Berkeley DB by Sleepycat Software, Inc. as the session store database. When session failover is enabled, and an Access Manager server goes down, the available Access Manager server can retrieve the user's session token from one of the Message Queues in the cluster. This ensures that the user remains continuously authenticated, and allows the user to access to the Protected Resources without having to re-authenticate.