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

ProcedureTo Configure the Access Manager Load Balancer

Users internal to your company will access the Access Manager servers through the internal-facing load balancer. The internal-facing load balancer is optional, and enables you to customize an internal-facing login page that is different from the external-facing login page. Users external to your company will first access the Distributed Authentication UI servers, which in turn route requests to the external-facing load balancer. Internal users will access port 90 while External users will access port 9443.

Load Balancer 3 sends the user and agent requests to the server where the session originated. SSL is terminated at Load Balancer 3 before a request is forwarded to the Access Manager Servers. Otherwise the load balancer cannot inspect the traffic for proper routing.

Load Balancer 3 is capable of the following types of load balancing:


The load balancer makes decisions based on client's cookies. The load balancer looks at the request and detects the presence of a cookie by a specific name. If the cookie is detected in the request, the load balancer routes the request to the specific server to which the cookie has been assigned. If the cookie is not detected in the request, the load balancer balances client requests among the available servers. 


This is similar to cookie-based load balancing, but the decision is based on the IP address of the client. The load balancer sends requests from a specific client to the same server. So a request from the client will always be processed by the server that last processed the request from that client. 


The load balancer mainstreams session affinity. This means that all requests related to a TCP session, are forwarded to the same server. In this deployment example, Load Balancer 3 forwards all requests from a single client to exactly the same server. When the session is started and maintained by one client, session affinity is guaranteed. This type of load-balancing is applicable to the TCP-based protocols. 

Before You Begin

Contact your network administrator to obtain two available virtual IP addresses.

Note –

The load balancer hardware and software used in the lab facility for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.

  1. Create a Pool.

    A pool contains all the backend server instances.

    1. Go to URL for the Big IP load balancer log in.

    2. Open the Configuration Utility.

      Click “Configure your BIG-IP (R) using the Configuration Utility.”

    3. In the left pane, click Pools.

    4. On the Pools tab, click the Add button.

    5. In the Add Pool dialog, provide the following information:

      Pool Name

      Example: AccessManager-Pool

      Load Balancing Method

      Round Robin


      Add all the Access Manager servers IP addresses. In this example, add the IP address and port number for AccessManager-1:1080 and for AccessManager-2:1080.

    6. Click the Done button.

  2. Configure the load balancer for persistence.

    1. In the left pane click Pools.

    2. Click the name of the pool you want to configure.

    3. Click the Persistence tab.

    4. On the Persistence tab, under Persistence Type, select Cookie Hash and set the following Hash Values:

      Cookie Name:






    5. Click Apply.

  3. Add a Virtual Server.

    If you encounter Javascript errors or otherwise cannot proceed to create a virtual server, try using Microsoft Internet Explorer for this step.

    1. In the left frame, Click Virtual Servers.

    2. On the Virtual Servers tab, click the Add button.

    3. In the Add a Virtual Server dialog box, provide the following information:


      xxx.xx.69.13 (for )





    4. Continue to click Next until you reach the Pool Selection dialog box.

    5. In the Pool Selection dialog box, assign the Pool (AccessManager-Pool) that you have just created.

    6. Click the Done button.

  4. Add Monitors.

    The load balancer has a built-in HTTP monitor that probes the Access Manager TCP port periodically. Successive probing failure indicates the server is down. However, this probing does not address the case where the Access Manager server responds to a TCP connection request, but fails to process any further Access Manager requests because of internal errors such as deadlocks. Access Manager comes with a JSP file /amserver/isAlive.jsp to address this challenge. In the following steps, you create a custom monitor that periodically accesses the JSP. If a success response can be obtained, it means not only that Access Manager is responding to TCP connection request, but also that free threads exist to process the request.

    1. Click the Monitors tab, and then the click Add button.

      In the Add Monitor dialog, provide the following information:



      Inherits From:

      Choose http.

    2. Click Next.

      In the Configure Basic Properties page, click Next.

    3. In the “Configure ECV HTTP Monitor” dialog, in the Send String field, enter the following:

      GET /amserver/isAlive.jsp

    4. In the Destination Address and Service (Alias) page, click Done.

      On the Monitors tab, the monitor you just added is now contained in the list of monitors.

    5. Click the Basic Associations tab.

      Look for the IP address for AccessManager-1:1080 and AccessManager-2:1080.

    6. Mark the Add checkbox for AccessManager-1 and AccessManager-2.

    7. At the top of the Node column, choose the monitor that you just added, AccessManager-http.

    8. Click Apply.