内に含ま
その他のドキュメント
サポート リソース
|  PDF 文書ファイルをダウンロードする (1748 KB)
Part I About This Deployment Example
Chapter 1 Key Features and Constraints
This document provides instructions for installing and configuring
a common Sun Java System Access Manager 7 2005Q4 solution that incorporates
load-balancing, distributed authentication UI, and policy agents.
1.1 Key Features of This Deployment Example
-
All components such as Directory Servers, Access Manager
Servers, Distributed Authentication UI servers, and Policy Agents
are redundant to achieve high availability.
-
Both Web Policy Agents and J2EE Policy Agents are
used to protect resources in the environment.
-
All components use load-balancing for system failover
and for high availability.
-
Each Directory Server contains three instances: one
named ds-config for storing Directory Server configuration,
one named am-config for storing Access Manager
configuration, and one named am-users for storing
Access Manager users. The am-users instance serves
as the LDAPv3 user data store.
-
The environment includes one service access interface
for external users and agents, and a separate service access interface
for internal administrators.
-
Actual firewalls were not used in this deployment.
However, critical components such as Access Manager and Directory
Server can be protected by three firewalls as illustrated in Figure 1–1. In this illustration,
only simple components and interfaces are exposed to the Internet
in a minimally-secured zone known as the DMZ.
-
Access Manager servers are reconfigured to run as
non-root users.
-
The environment is configured for system failover
capability. System failover ensures that when one Access Manager server
goes down, requests are redirected to a second Access Manager server.
It is important to note that system failover, by itself, does not
ensure Access Manager session failover.
-
The environment is configured for session failover
capability. Session failover ensures that when the Access Manager
server where the user's session was created is
stopped, the user's session token can still be retrieved from a backend
session database. The user is continuously authenticated, and does
not have to log into the system again unless the session is invalidated.
For example, a session is invalidated when the logout occurs or when
the session expires.
-
An existing LDAPv3 user data store is integrated into
the environment.
-
SSL is terminated at the load balancer for Access
Manager servers and at the load balancer for Access Manager Distributed
Authentication UI servers. In this deployment example, communication
to each of these load balancers is in SSL, and communication between
the load balancer and the server is non-SSL.
-
Each policy agent in the deployment is configured
with a unique agent profile used by the agent to authenticate itself
to Access Manager.
-
The Distributed Authentication UI servers use a custom
user profile to authenticate to Access Manager instead of a default
of amadmin or UrlAccessManager.
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.
1.3 System Behaviors
The following sequence describes the interaction between the
various components in this Deployment Example. These interactions
are also illustrated in the following pages. The numbered steps here
correspond to the numbers in the figures on the following pages.
-
A user attempts to access the J2EE application hosted
by Protected Resource 1 and by Protected Resource 2 through Load Balancer
6. Load Balancer 6 redirects the user to Protected Resource 1.
-
The J2EE Policy Agent intercepts the request and checks
for the Access Manager cookie.
-
If the Access Manager cookie is not found, the J2EE
Policy Agent redirects the user to Load Balancer 4, the load balancer
for the Distributed Authentication UI servers.
-
Load Balancer 4 routes the user request to Authentication
UI Server 2.
-
Authentication UI Server 2 displays a login page to
the user.
-
The user enters credentials on the login page.
-
Authentication UI Server 2 passes the credentials
to Load Balancer 3.
-
Load Balancer 3 routes the Authentication UI 2 request
to Access Manager 1 for validation.
-
Access Manager 1 sends the Authentication UI 2 request
to Load Balancer 2. Load Balancer 2 handles Directory Server requests
for user data.
-
Load Balancer 2 routes the Authentication UI 2 request
to Directory Server 2 where validation takes place.
-
After successful authentication, Access Manager 1
sends the Authentication UI 2 request 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 3 forwards the request
to the Access Manager 1 where the session originated. Cookie-based
persistency and routing enables Access Manager to route the request
properly.
-
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 UI server.
-
In this example, J2EE Policy Agent receives the response
back as a valid session. When the session is valid, the J2EE Policy
Agent sends a policy request to Access Manager servers' Load Balancer
3.
-
Access Manager 1 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 example, the user is allowed access to the Application Server.
Figure 1–2 Request for Access
In this figure, a user attempts to access a protected application.
The J2EE Policy Agent intercepts the access request. The Authentication
UI is invoked. The Authentication UI server displays a login page
to the user.
Figure 1–3 Authentication
In this figure, the user credentials are passed to Access Manager
1. Access Manager 1 checks the user credentials against Directory
Server.
Figure 1–4 Access Granted
Access Manager authenticates the user, and the J2EE Policy Agent
determines that the user's session is valid. The J2EE Policy Agent
sends a second request to Access Manager for policy evaluation. Based
on the results of the policy evaluation, the J2EE Policy Agent allows
access to the application server. Access Manager continues to manage
the session until the user logs out.
Chapter 2 Technical Overview
This chapter contains the following topics:
2.1 Software Used in this Environment
The following table lists the software used in this deployment.
Table 2–1 Software Versions and Download
Locations
2.2 Host Names and Main Service URLs Used in
Examples
The following table summarizes naming conventions used in this
guide. For detailed configuration information, see Part III, Reference: Summaries of Server and Component Configurationsin this guide.
Table 2–2 Host Names and Service URLs
|
|
Host or Component
|
Main Service URL
|
|
Directory Servers
|
|
|
DirectoryServer–1
|
ldap://DirectoryServer-1.example.com:1389
|
|
|
DirectoryServer-1 User Data Store
|
ldap://DirectoryServer-1.example.com:1489
|
|
|
DirectoryServer–2
|
ldap://DirectoryServer-2.example.com:1389
|
|
|
DirectoryServer-1 User Data Store
|
ldap://DirectoryServer-2.example.com:1489
|
|
|
LoadBalancer–1
|
http://LoadBalancer-1.example.com:389
(Access Manager configuration)
|
|
|
LoadBalancer–2
|
http://LoadBalancer-2.example.com:489
(User data store)
|
|
Access Manager Servers
|
|
|
AccessManager–1
|
http://AccessManager-1. example.com:1080/amserver/console
|
|
|
AccessManager–2
|
http://AccessManager-2. example.com:1080/amserver/console
|
|
|
LoadBalancer–3
|
http://LoadBalancer-3.example.com:90 (for Intranet users)
https://LoadBalancer-3.example.com:9443 (for Internet users)
|
|
Message Queue Broker Cluster
|
|
|
MessageQueue–1
|
http://MessageQueue-1.example.com:7777
|
|
|
MessageQueue–2
|
http://MessageQueue-2.example.com:7777
|
|
Distributed Authentication UI Modules
|
|
|
AuthenticationUI–1
|
http://AuthenticationUI-1. example.com:1080/distAuth/UI/Login
|
|
|
AuthenticationUI–2
|
http://AuthenticationUI-2. example.com:1080/distAuth/UI/Login
|
|
|
LoadBalancer–4
|
https://LoadBalancer-4.example.com:9443
|
|
Protected Resources and Policy Agents
|
|
|
ProtectedResource–1
|
http://ProtectedResource-1.example.com:8888
(Sun Java System Web Server)
|
|
|
Web Agent 1
|
http://ProtectedResource-1.example.com:1080
|
|
|
ProtectedResource–1
|
http://ProtectedResource-1.example.com:7001/console
(WebLogic Application Server)
|
|
|
J2EE Policy Agent 1
|
http://ProtectedResource-1.example.com:1081
|
|
|
|
|
|
|
ProtectedResource–2
|
http://ProtectedResource-2.example.com:8888
(Sun Java System Web Server)
|
|
|
Web Agent 2
|
http://ProtectedResource-2.example.com:1080
|
|
|
ProtectedResource–2
|
http://ProtectedResource-2.example.com:7001/console
(WebLogic Application Server)
|
|
|
J2EE Policy Agent 2
|
http://ProtectedResource-2.example.com:1081
|
|
|
|
|
|
|
LoadBalancer–5
|
http://LoadBalancer-5.example.com:90
(Web Policy Agents)
|
|
|
LoadBalancer–6
|
http://LoadBalancer-6.example.com:91
(J2EE Policy Agents)
|
2.3 Intercomponent Communication
The following table provides an overview of the types of communication
that take place between server, load balancers, and other components
in the deployment example.
Table 2–3 Summary of Intercomponent
Communication
|
Entity A
|
Entity B
|
Bi-Directional
|
Port
|
Protocol
|
Traffic Type
|
|
Intranet Users
|
LoadBalancer-5
|
|
90
|
HTTP
|
Application Traffic
|
|
Internet Users
|
LoadBalancer-6
|
|
91
|
HTTP
|
Application Traffic
|
|
Internet Users
|
LoadBalancer-4
|
|
9443
|
HTTPS
|
Internet User Authentication
|
|
Intranet Users
|
LoadBalancer-3
|
|
90
|
HTTP
|
Intranet 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
|
|
AuthUIServer-1
|
LoadBalancer-3
|
|
9443
|
HTTPS
|
Internet User Authentication
|
|
AuthUIServer-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
|
Yes
|
7777
|
HTTP
|
Session communication
|
|
AccessManager-2
|
MessageQueue-2
|
Yes
|
7777
|
HTTP
|
Session communication
|
|
MessageQueue-1
|
MessageQueue-2
|
Yes
|
7777
|
HTTP
|
Session communication
|
|
MessageQueue-2
|
MessageQueue-1
|
Yes
|
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
|
LoadBalancer-1
|
|
389
|
LDAP
|
AM Configuration communication
|
|
AccessManager-2
|
LoadBalancer-2
|
|
489
|
LDAP
|
User profile communication User Authentication
|
|
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.4 Firewall Rules
Set up firewalls to allow traffic to flow as described in the
following table.
Table 2–4 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 user
|
LoadBalancer-6
|
90
|
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
|
9443
|
HTTPS
|
User authentication and various Access Manager services
|
|
