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:
This chapter contains introductory information on the deployment example. It includes the following sections:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
am-config stores Access Manager configuration data.
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.
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.
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.
This chapter contains technical information regarding the machines, software, and other components used in this deployment example. It contains the following sections:
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 |
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 | |
Sun Java System Web Server |
7.0 | |
Sun Java System Directory Server |
6.0 | |
BEA Weblogic Server |
9.2 | |
Web Policy Agent (for Sun Java System Web Server) |
2.2 | |
J2EE Policy Agent (for BEA Weblogic Server) |
2.2 | |
Java (for Access Manager and policy agents) |
1.5.0_09 | |
BIG-IP Load Balancer |
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) |
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 |
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 |
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.