Deployment Example 1: Access Manager 7.1 Load Balancing, Distributed Authentication UI, and Session Failover

Part I About This Deployment Example

This first part of the Deployment Example 1: Access Manager 7.1 Load Balancing, Distributed Authentication UI, and Session Failover provides introductory material and an overview of the Sun Java™ System Access Manager 7.1 deployment solution that incorporates load-balancing, distributed authentication, policy agents, and protected resources. It contains the following chapters:

Chapter 1 Components and Features

This chapter contains introductory information on the deployment example. It includes the following sections:

1.1 System Components and Architecture

The following components comprise the system environment of the deployment example. Figure 1–1 follows the list and illustrates the components as they will be situated when the deployment is complete.

Sun Java System Access Manager

Two Access Manager servers provide core Access Manager functionality. Both servers share the same configuration data, accessed through a single load balancer deployed in front of two instances of Directory Server.

Sun Java System Directory Server

Two instances of Directory Server provide storage for the Access Manager configuration data and user entries. Configuration data includes information about Access Manager services, realms, policies, and more. User entries will be created and used for testing the deployment. Both Directory Server instances are master replicas that engage in multi-master replication (MMR). MMR allows data to be synchronized in real time between two directories, providing high availability to the Access Manager layer.

Note –

No Directory Server Administration Console is installed with the bits downloaded for this deployment example. The command line is used for all Directory Server configurations.

Protected Resources

The protected resources are host machines that contain content for which you want to restrict access. Towards this end, web servers, application servers, and policy agents will be installed. For example, a Human Resources Department might use Sun Java System Web Server to host content and applications. Some of the hosted information must be made available to benefits administration vendors (such as health care providers or stock administrators) that need to access employee information in order to coordinate benefits. These external vendors access the protected resources through an external-facing load balancer. Other information must be restricted to internal Human Resources administrators who access the protected resources through an internal-facing load balancer.

Sun Java System Access Manager Policy Agents 2.2

Both Web Policy Agents and J2EE Policy Agents are used to restrict access to content or applications hosted on the protected resources. The policy agents intercept HTTP requests from external users and redirect the request to Access Manager for authentication. The agent communicates with the Access Manager servers through an internal-facing load balancer.

Distributed Authentication User Interface

The Distributed Authentication User Interface is a component of Access Manager that provides a thin presentation layer for user authentication. During user authentication, a Distributed Authentication Module retrieves the user's credentials and passes them to Access Manager for verification. Thus, the user does not have direct network access to any Access Manager servers.

Sun Java System Message Queue Broker Cluster

Access Manager uses two Message Queue broker instances to form a cluster for distributing client connections and message delivery. The Berkeley Database by Sleepycat Software, Inc. is the session store database. When an Access Manager server goes down and session failover is enabled, the user's session token can be retrieved from one of the Message Queues by the available Access Manager server. This ensures that the user remains continuously authenticated, allowing access to the protected resources without having to reauthenticate.

Load Balancers

The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are deployed as follows:

Distributed Authentication User Interface Load Balancer. This external-facing load balancer exposes the remote, web-based Distributed Authentication User Interface for user authentication and self-registration.

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

Directory Server Load Balancer. The load balancers in front of the Directory Server instances provide 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 for the Access Manager servers.

Figure 1–1 System Architecture

Illustrates flow from Internet through multiple
load balancers and optional firewalls to Access Manager servers.

Note –

Actual firewalls are not set up in this example deployment although they are referred to in this illustration. For information on specific firewall rules, see 2.5 Firewall Rules.

1.2 Key Features of Deployment

All components (including installations of Access Manager and Directory Server, the Distributed Authentication User Interface, and policy agents) are redundant to achieve high availability.
All components use ZIP-based installation.
All components use load-balancing for session failover and high performance.
Each Directory Server contains two instances:
1. am-config stores Access Manager configuration data.
2. am-users serves as the LDAP v3 data store for user entries.
The environment includes one service access interface for external users and agents, and a separate service access interface for internal administrators.
Access Manager servers are configured to run as non-root users.
The environment is configured for system failover capability, ensuring that when one Access Manager server goes down, requests are redirected to the second Access Manager server.

Caution –
It is important to note that system failover, by itself, does not ensure Access Manager session failover. Session failover is configured separately.
The environment is configured for session failover capability. Session failover ensures that when the Access Manager server where the user's session was created goes down, the user's session token can still be retrieved from a backend session database. Thus, the user is continuously authenticated, and does not have to log into the system again unless the session is invalidated as a result of logout or session expiration.
Communications to the load balancer for the Access Manager servers and to the load balancer for the Distributed Authentication User Interface are in Secure Sockets Layer (SSL). SSL is then terminated and communications between the load balancers and their respective components is non-SSL.
Policy agents are configured with a unique agent profile to authenticate to Access Manager.
The Distributed Authentication User Interface uses a custom user profile to authenticate to Access Manager instead of the default amadmin or UrlAccessAgent.

1.3 Sequence of Interactions

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

A user attempts to access a J2EE application hosted by Protected Resource 1 and Protected Resource 2.
Load Balancer 6 directs the user to Protected Resource 1.
The J2EE Policy Agent intercepts the request and checks for an Access Manager cookie. In this scenario, no cookie is found and the request is returned to the browser which then redirects it to Load Balancer 4, the load balancer for the Distributed Authentication User Interface.
Load Balancer 4 routes the user request to Distributed Authentication User Interface 2.
Distributed Authentication User Interface 2 displays a login page to the user.
The user enters credentials on the login page and they are returned to Distributed Authentication User Interface 2.
Distributed Authentication User Interface 2 passes the credentials to Load Balancer 3.
Load Balancer 3 routes the credentials to Access Manager 1 for validation.
Access Manager 1 sends a request for validation to Load Balancer 2 which specifically handles Directory Server requests for user data.
Load Balancer 2 routes the request to Directory Server 2 where validation takes place.
After successful authentication, Access Manager 1 sends the response back to the J2EE Policy Agent. The J2EE Policy Agent receives the request and checks for the Access Manger cookie.
When a cookie is found, the J2EE Policy Agent sends a session validation request to the Access Manager Load Balancer 3.
The Access Manager load balancer forwards the request to the Access Manager 1 where the session originated. Cookie-based persistency enables proper routing.
Access Manager 1 sends a response back to the J2EE Policy Agent.
If the session is not valid, the J2EE Policy Agent would redirect the user to the Distributed Authentication User Interface.
If the session is valid, the J2EE Policy Agent receives the response back and sends a policy request to the Access Manager Load Balancer 3.
The policy request is directed to Access Manager 1 which conducts the policy evaluation.
Based on the policy evaluation, the J2EE Policy Agent either allows access to the resource or denies access to the resource. In this scenario, the user is allowed access to the Application Server.

Chapter 2 Technical Overview

This chapter contains technical information regarding the machines, software, and other components used in this deployment example. It contains the following sections:

2.1 Host Machines

The following table lists the attributes of the physical host machines used for this deployment example.

Table 2–1 Physical Machines and Operating Systems


Host Machine	Architecture	Operating System
DirectoryServer–1	x86	Solaris 10
DirectoryServer–2	x86	Solaris 10
AccessManager–1	SPARC	Solaris 10
AccessManager–2	SPARC	Solaris 10
MessageQueue–1	SPARC	Solaris 10
MessageQueue–2	SPARC	Solaris 10
AuthenticationUI–1	x86	Solaris 10
AuthenticationUI–2	x86	Solaris 10
ProtectedResource–1	SPARC	Solaris 10
ProtectedResource–2	SPARC	Solaris 10

2.2 Software

The following table lists the software used in this deployment example.

Table 2–2 Software Versions and Download Locations


Product	Version	Download Location
Sun Java™ System Access Manager	7.1	`http://www.sun.com/download/`
Sun Java System Web Server	7.0	`http://www.sun.com/download/`
Sun Java System Directory Server	6.0	`http://www.sun.com/download/`
BEA Weblogic Server	9.2	`http://www.bea.com`
Web Policy Agent (for Sun Java System Web Server)	2.2	`http://www.sun.com/download/`
J2EE Policy Agent (for BEA Weblogic Server)	2.2	`http://www.sun.com/download/`
Java (for Access Manager and policy agents)	1.5.0_09	`http://www.java.com/en/`
BIG-IP Load Balancer		`http://www.f5.com`

2.3 Main Service URLs for Deployment Components

The following table summarizes the main service URLs for the components used in this deployment example. For detailed configuration information, see Part III, Reference: Summaries of Server and Component Configurations.

Table 2–3 Components and Main Service URLs


	Components	Main Service URL
Directory Server Instances and Load Balancers
	Directory Server 1	`ldap://DirectoryServer-1.example.com:1389` (for Access Manager configuration data) `ldap://DirectoryServer-1.example.com:1489` (for user data)
	Directory Server 2	`ldap://DirectoryServer-2.example.com:1389` (for Access Manager configuration data) `ldap://DirectoryServer-2.example.com:1489` (for user data)
	Load Balancer 1	`http://LoadBalancer-1.example.com:389` (for Access Manager configuration data)
	Load Balancer 2	`http://LoadBalancer-2.example.com:489` (for user data)

Access Manager Servers and Load Balancer
	Access Manager 1	`http://AccessManager-1.example.com:1080/amserver/console`
	Access Manager 2	`http://AccessManager-2.example.com:1080/amserver/console`
	Load Balancer 3	`http://LoadBalancer-3.example.com:7070` (for Intranet users) `https://LoadBalancer-3.example.com:9443` (for Internet users)

Message Queue Broker Clusters
	Message Queue 1	`http://MessageQueue-1.example.com:7777`
	Message Queue 2	`http://MessageQueue-2.example.com:7777`

Distributed Authentication User Interfaces and Load Balancer
	Distributed Authentication User Interface 1	`http://AuthenticationUI-1.example.com:1080/distAuth/UI/Login`
	Distributed Authentication User Interface 2	`http://AuthenticationUI-2.example.com:1080/distAuth/UI/Login`
	Load Balancer 4	`http://LoadBalancer-4.example.com:90` (non-secure for internal users) `https://LoadBalancer-4.example.com:9443` (secure for external users)

Protected Resources 1 and 2, Policy Agents, and Load Balancers
	Web Container 1	`https://ProtectedResource-1.example.com:8989` (for Sun Java System Web Server administration console)
	Web Policy Agent 1	`http://ProtectedResource-1.example.com:1080`
	J2EE Container 1	`http://ProtectedResource-1.example.com:7001/console` (for BEA Weblogic administration server)
	J2EE Policy Agent 1	`http://ProtectedResource-1.example.com:1081`

	Web Container 2	`https://ProtectedResource-2.example.com:8989` (for Sun Java System Web Server administration console)
	Web Policy Agent 2	`http://ProtectedResource-2.example.com:1080`
	J2EE Container 2	`http://ProtectedResource-2.example.com:7001/console` (for BEA WebLogic administration server)
	J2EE Policy Agent 2	`http://ProtectedResource-2.example.com:1081`

	Load Balancer 5	`http://LoadBalancer-5.example.com:90` (for web policy agents)
	Load Balancer 6	`http://LoadBalancer-6.example.com:91` (for J2EE policy agents)

2.4 Intercomponent Communication

The following table provides an overview of the types of communication that take place between servers, load balancers, and other components in the deployment example.

Table 2–4 Summary of Intercomponent Communication


Entity A	Entity B	Bi-Directional	Port	Protocol	Traffic Type
Internet Users	LoadBalancer-5		90	HTTP	Application Traffic
Intranet Users	LoadBalancer-3		7070	HTTP	Intranet User Authentication
Internet Users	LoadBalancer-6		91	HTTP	Application Traffic
Internet Users	LoadBalancer-4		9443	HTTPS	Internet User Authentication
LoadBalancer-4	AuthenticationUI-1		1080	HTTP	Internet User Authentication
LoadBalancer-4	AuthenticationUI-2		1080	HTTP	Internet User Authentication
LoadBalancer-5	ProtectedResource-1		1080	HTTP	Application Traffic
LoadBalancer-5	ProtectedResource-2		1080	HTTP	Application Traffic
LoadBalancer-6	ProtectedResource-1		1081	HTTP	Application Traffic
LoadBalancer-6	ProtectedResource-2		1081	HTTP	Application Traffic
AuthenticationUI-1	LoadBalancer-3		9443	HTTPS	Internet User Authentication
AuthenticationUI-2	LoadBalancer-3		9443	HTTPS	Internet User Authentication
ProtectedResource-1	LoadBalancer-3		9443	HTTPS	Agent-AM communication
ProtectedResource-2	LoadBalancer-3		9443	HTTPS	Agent-AM communication
LoadBalancer-3	AccessManager-1		1080	HTTP	User Authentication Agent-AM communication
LoadBalancer-3	AccessManager-2		1080	HTTP	User Authentication Agent-AM communication
AccessManager-1	AccessManager-2	Yes	1080	HTTP	AM Back-channel communication
AccessManager-1	MessageQueue-1		7777	HTTP	Session communication
AccessManager-1	LoadBalancer-1		389	LDAP	AM Configuration communication
AccessManager-1	LoadBalancer-2		489	LDAP	User profile communication User Authentication
AccessManager-2	MessageQueue-2		7777	HTTP	Session communication
AccessManager-2	LoadBalancer-1		389	LDAP	AM Configuration communication
AccessManager-2	LoadBalancer-2		489	LDAP	User profile communication User Authentication
MessageQueue-1	MessageQueue-2	Yes	7777	HTTP	Session communication
MessageQueue-2	MessageQueue-1	Yes	7777	HTTP	Session communication
LoadBalancer-1	DirectoryServer-1		1389	LDAP	AM Configuration communication
LoadBalancer-1	DirectoryServer-2		1389	LDAP	AM Configuration communication
LoadBalancer-2	DirectoryServer-1		1489	LDAP	User profile communication User Authentication
LoadBalancer-2	DirectoryServer-2		1489	LDAP	User profile communication User Authentication
DirectoryServer-1	DirectoryServer-2	Yes	1389	LDAP	Data replication communication
DirectoryServer-1	DirectoryServer-2	Yes	1489	LDAP	Data replication communication

2.5 Firewall Rules

Actual firewalls are not set up in this deployment example. The intended deployment if firewalls were configured would be to protect critical components using three distinct security zones as illustrated in Figure 1–1. One zone is completely secure, protected by all three firewalls, and used for internal traffic only. The second, less secure zone is protected by only two firewalls and is also for internal traffic only. The third, minimally-secured demilitarized zone (DMZ) leaves only simple components and interfaces exposed to the Internet and is used for external traffic. Thus, direct access to individual Access Manager servers and Directory Server instances is allowed only if permitted by firewall rules. Based on the illustration cited:

The Access Manager servers are isolated between an internal firewall and the DMZ. Access Manager services are exposed through both an external-facing load balancer and an internal-facing load balancer. The load balancer and Access Manager servers together provide high data availability within the infrastructure.
The policy agents themselves are deployed behind a load balancer configured in the DMZ.
The Distributed Authentication User Interface would be deployed in the DMZ for communication with Access Manager behind a firewall, additionally protecting the Access Manager servers from exposure in the minimally-secured DMZ.

You may set up firewalls to allow traffic to flow as described in the following table.

Table 2–5 Summary of Firewall Rules


From	To	Port #	Protocol	Traffic Type
Internet users	LoadBalancer-4	9443	HTTPS	User authentication
Internet users	LoadBalancer-5	90	HTTP	Application access by internet user
Internet users	LoadBalancer-6	91	HTTP	Application access by internet user
AuthenticationUI-1	LoadBalancer-3	9443	HTTPS	User authentication
AuthenticationUI-2	LoadBalancer-3	9443	HTTPS	User authentication
LoadBalancer-5	ProtectedResource-1	1080	HTTP	Application access by user
LoadBalancer-6	ProtectedResource-2	1081	HTTP	Application access by user
Intranet User	LoadBalancer-3	7070	HTTP	User authentication and various Access Manager services

2.6 Replicated Entries

Throughout this deployment example, we use ldapsearch to view replicated entries. An alternative would be to enable the Directory Server audit log and run tail -f. Enabling the audit log will also help to track changes and updates made during Access Manager configuration.