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
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:
-
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.
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
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.
PDF 文書ファイルをダウンロードする (2163 KB)