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

• 1.2 Key Features of Deployment

• 1.3 Sequence of Interactions

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

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.

1. A user attempts to access a J2EE application hosted by Protected Resource 1 and Protected Resource 2.

2. Load Balancer 6 directs the user to Protected Resource 1.

3. 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.

4. Load Balancer 4 routes the user request to Distributed Authentication User Interface 2.

5. Distributed Authentication User Interface 2 displays a login page to the user.

6. The user enters credentials on the login page and they are returned to Distributed Authentication User Interface 2.

   

7. Distributed Authentication User Interface 2 passes the credentials to Load Balancer 3.

8. Load Balancer 3 routes the credentials to Access Manager 1 for validation.

9. Access Manager 1 sends a request for validation to Load Balancer 2 which specifically handles Directory Server requests for user data.

10. Load Balancer 2 routes the request to Directory Server 2 where validation takes place.

    

11. 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.

12. When a cookie is found, the J2EE Policy Agent sends a session validation request to the Access Manager Load Balancer 3.

13. The Access Manager load balancer forwards the request to the Access Manager 1 where the session originated. Cookie-based persistency enables proper routing.

14. Access Manager 1 sends a response back to the J2EE Policy Agent.

15. If the session is not valid, the J2EE Policy Agent would redirect the user to the Distributed Authentication User Interface.

16. 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.

17. The policy request is directed to Access Manager 1 which conducts the policy evaluation.

18. 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.