Build a front-end load balancer and failover reverse proxy with IBM Security Access Manager 8.0

How to create a highly available, fault-tolerant, secure web environment

Learn to configure the IBM Security Access Manager for Web 8.0 appliance as a front-end load balancer and cluster of reverse proxy servers to build a highly available, fault-tolerant, secure web environment.

Share:

Ricardo Gutierrez Cabanillas (rgutierrez2004@hotmail.com), Senior IT Architect, IBM

Ricardo Gutierrez has more than 20 years of experience working with several technologies. He is a Senior IT Architect for the IBM Security Systems division of IBM Canada. He specializes in Security, Cloud Computing, IAM, Federation, and Security Intelligence.



30 May 2014 (First published 19 May 2014)

x

The IBM® Security Access Manager (ISAM) for Web 8.0 appliance is an “all-in-one” network appliance–based security solution that provides both access control and protection from web-based threats. The appliance includes several features, among the most important of which are a web reverse proxy, web application and content protection, built-in policy server, and layer 4 and 7 load balancing for high availability. Cluster services supplement the preceding features, giving the appliance the capability to deploy highly scalable reverse proxy server architectures.

Front-end load balancer and cluster overview

The front-end load balancing function automatically assigns client requests to the appropriate reverse proxy server based on the specified scheduling algorithm. Moreover, the front-end load balancer provides stickiness or persistence for existing sessions, allowing incoming requests from the same client to be forwarded to the same server. A typical setup is two front-end load balancer servers and multiple reverse proxy servers. Configuring two front-end load balancers in the environment provides high availability for the front-end load balancing service.

Figure 1 shows a typical front-end load balancer architecture.

Figure 1. Front-end load balancer architecture
Diagram that shows front-end load balancer architecture

/developerworks/library/se-isam-loadbalance-reverseproxy/

ISAM for Web appliances can be grouped to work together in a cluster environment, allowing information to be replicated across multiple nodes and providing high availability of cluster services. Members in the cluster share configuration and runtime information. The following cluster services can be provided:

  • Distributed session cache (DSC)―Represents a central cache to hold session information.
  • Configuration database―Stores configuration data that is shared among the appliances in the cluster. Configuration data can be updated in the primary master only.
  • Geolocation database―Provides geographic location information.
  • Runtime database―Runtime data that is shared among appliances in the cluster. The database can be:
    • Internal―Suitable for small deployments or proof of concept scenarios.
    • External―Recommended for most deployments; supports IBM Solid DB and IBM DB2® database types.

A cluster configuration requires at least one master, called the primary master, which provides the cluster services. For failover and high availability purposes, a customer can consider defining a cluster with multiple nodes that act as secondary, tertiary, or quaternary master. The secondary master can provide failover for the cluster services, while a tertiary and quaternary master provides extra failover to the distributed session cache. An external reference entity (ERE) must be associated with each pair in a cluster configuration (that is, primary and secondary) to help detect network failures and to prevent two masters from trying to become primary.

Figure 2 shows a high available cluster architecture in a cross–data center environment.

Figure 2. Multi–data center cluster architecture
Diagram that shows multi-data center cluster architecture

In the sections that follow, we describe the step-by-step details necessary to configure the ISAM for Web appliance to act as both a front-end load balancer and as a cluster of reverse proxy servers.


Prerequisites

The configuration that is described in this article is applicable to IBM Security Access Manager 8.0 for Web appliance (8.0.0.2) with interim fix 2.


Scenario

Figure 3 illustrates a scenario with two configurations of ISAM for Web appliance that act as a stand-alone front-end load balancer and as a cluster of reverse proxy servers.

Figure 3. Scenario configuration
Diagram that shows the scenario configuration

Two front-end load balancers (FELB) in a highly available configuration will load balance the HTTPS traffic to external address https://192.168.0.157 across a cluster of two reverse proxy servers. The cluster maintains an internal database and has its user registry in a separate LDAP server. Failover support is provided by an external reference entity (ERE) for the paired master nodes.


Configuration

The following procedure guides you through configuring a highly available front-end load balancer and a cluster of reverse proxy servers. Since this article is focused on ISAM for Web appliance only, it is assumed that configuration of an external user registry was done already. See Resources for a link with information about configuring a highly available LDAP server using IBM Tivoli Directory Server.

Cluster and proxy server configuration

  1. Log in to the Local Management Interface (LMI) of the first proxy server (primary master). From the main menu, select Manage System Settings > Network Settings > Management Interfaces. Configure the first interface (M.1) with the following values:

    PropertyValue
    Enabled M.1[checked]
    IP4 Manual[checked]
    Address192.168.0.140
    Netmask255.255.255.0
    Gateway192.168.0.1
  2. Click Save Configuration and wait until the LMI interface is restarted or else manually restart the appliance from the console.
  3. Go back to the LMI of the first proxy server (primary master). From the main menu, select Manage System Settings > Network Settings > Application Interfaces. Configure the first two interfaces with the following values:

    PropertyValue
    Interface 1 (P.1)
    Enabled[checked]
    IPv4 SettingsStatic
    Address10.10.10.200
    Netmask255.255.255.0
    Interface 2 (P.2)
    Enable[checked]
    IPv4 SettingsStatic
    Address160.20.20.90
    Netmask255.255.255.0

    Figure 4 shows the interfaces in the appliance.

    Figure 4. Appliance interfaces
    Screen capture showing appliance interfaces
  4. If you did not define a DNS in the appliance configuration, then you need to update the appliance hosts file, so that it can find other appliances in the cluster. From the main menu, select Manage System Settings > Network Settings > Hosts file. Click New to add the following values:

    192.168.0.141 : IBM-WRP81
  5. Repeat steps 1 through 4 to configure the second proxy server (secondary master). Use the corresponding values from Table 2. Network interfaces―Reverse proxy servers.
  6. Configure the runtime component. Log in to the LMI of the first proxy server (primary master). From the main menu, select Secure Web Settings > Manage > Runtime Component. Select Configure from the toolbar and select or enter the following values as appropriate:
    PropertyValue
    Main
    Policy ServerLocal
    User RegistryLDAP Remote
    Policy Server
    Management DomainDefault
    Administrator passwordPassw0rd
    SSL ComplianceNone
    LDAP
    Host name160.20.20.11
    Port389
    DNcn=root
    PasswordPassw0rd

    Figure 5 shows the runtime configuration window.

    Figure 5. Runtime configuration
    Screen capture showing runtime configuration
  7. Click Finish to save and deploy the changes.
  8. If your user registry (LDAP) is made up of a master/replica topology for high availability, then proceed to update the runtime configuration. From the main menu, select Secure Web Settings > Manage > Runtime Component. From the toolbar, select Manage > Configuration Files > ldap.conf and add the following value to the configuration file:
    replica = 160.20.20.12,389,readonly,5
  9. Click Save to review and deploy the changes.
  10. Configure the reverse proxy instance. Select Secure Web Settings > Manage > Reverse Proxy. From the toolbar, select New and select or enter as appropriate the following values in the New Reverse Proxy Instance window:
    PropertyValue
    Instance
    Instance namedefault
    Host nameIBM-WRP80
    Listening port7234
    IP Address for the primary interface10.10.10.200
    IBM Security Access Manager
    Administrator namesec_master
    Administrator passwordPassw0rd
    Domaindefault
    Transport
    Enable HTTPS[checked]
    HTTPS Port443

    Figure 6 shows the reverse proxy configuration window.

    Figure 6. Reverse proxy configuration
    Screen capture showing reverse proxy configuration
  11. Click Save to review and deploy the changes.
  12. Go back to Secure Web Settings > Manage > Reverse Proxy and select default from the list. Select Manage > Junction Management from the toolbar. Then, select New > Standard Junction from the Junction Management window and select or enter as appropriate the following values:

    PropertyValue
    Junction
    Junction Point Name/webmobile
    Junction TypeTCP
    Server
    Hostname160.20.20.88
    TCP or SSL Port9080

    As depicted in Figure 3, the IP address 160.20.20.88 corresponds to the application server that is hosting a sample application that listens on port 9080.

  13. Click Save to review and deploy the changes.
  14. Configure the cluster. From the main menu, select Manage System Settings > Network Settings > Cluster Configuration. Choose the General tab and select or enter as appropriate the following values:
    PropertyValue
    Set this appliance as the primary master[checked]
    Primary Master192.168.0.140
  15. Click Save to review and deploy the changes.
  16. Go back to the Overview tab and update the node description. Under the Nodes list, select 192.168.0.140 and click Edit Description and enter the following value:
    PropertyValue
    DescriptionPrimary master
    Figure 7 shows the cluster configuration page.
    Figure 7. Cluster configuration
    Screen capture showing cluster configuration
  17. In the same tab under Cluster Signature, click Export to export the signature file. Save the file in your local drive as signature_output_file.
  18. Log in to the LMI of the second proxy server (secondary master). From the main menu, select Manage System Settings > Network Settings > Cluster Configuration. Under Cluster Signature, click Import to import the signature file of the primary master. From the Join Cluster window, click Browse to find the file and then click Join to add the secondary master to the cluster.

    You should now see two proxy servers under the Nodes list.

  19. Go back to the LMI of the first proxy server (primary master). From the main menu, select Manage System Settings > Network Settings > Cluster Configuration. Choose the Overview tab to update the node description. Under the Nodes list, select 192.168.0.141 and click Edit Description and enter the following value:
    PropertyValue
    DescriptionSecondary Master
  20. Go back to the General tab and enter the following values:
    PropertyValue
    Secondary Master192.168.0.141
    Master External Reference Entity192.168.0.42

    An external reference entity can be a network component (for example, a router, switch, or server) with the sole responsibility of responding to simple connectivity check requests such as the requests of the ping protocol that comes from the master nodes. As indicated earlier, an ERE helps detect network failures and prevent two masters from trying to become primary.

  21. Select the Session Cache tab and select the following value:
    PropertyValue
    Support internal clients only[Checked]
  22. Select the Database tab and select the following value:
    PropertyValue
    Local to the cluster[Checked]
  23. Click Save to review and deploy the changes.
  24. Go back to Manage System Settings > Network Settings > Cluster Configuration. Choose the Replication tab and click the Runtime component link. From the Runtime Component page, click Replicate with Cluster, and select Yes in the Confirm Action window.
  25. Go to Manage System Settings > Network Settings > Cluster Configuration. Choose the Overview tab and ensure all the columns for the listed nodes have a green check. Figure 8 shows the status of the final cluster configuration.
    Figure 8. Cluster nodes
    Screen capture showing cluster nodes
  26. Go back to the LMI of the second proxy server (secondary master). From the main menu, select Secure Web Settings > Manage > Runtime Component and ensure that the runtime mode shows as configured. Figure 9 shows the runtime component page.
    Figure 9. Runtime component configuration
    Screen capture showing runtime component configuration

    Cluster services also allow you to replicate the Certificate database, although in this scenario, replication is not needed because you are not using an SSL connection with the user registry.

  27. Update the proxy instance configuration in the first proxy server (primary master). Log in to the LMI. From the main menu, select Secure Web Settings > Manage > Reverse Proxy. Select default from the list and click Edit. Select or enter the following values in the Reverse Proxy Basic Configuration window:
    PropertyValue
    Server
    Cluster is Master[checked]
    Authenticaton
    Basic Authentication 
    TransportNone
    Forms 
    Forms AuthenticationHTTPS
    Session
    Enabled Distributed Session Cache[checked]

    Among other benefits, enabling the distributed session cache within the cluster allows you to provide failover for user sessions. In the sample scenario, you enable DSC to provide failover authentication and high availability protection in the event of hardware or software failure.

  28. Click Save to review and deploy the changes.
  29. Go to Secure Web Settings > Manage > Distributed Session Cache and verify that the “default” replica set is listed. Figure 10 shows the default replica set in the distributed session cache and the reverse proxy server in the server list.
    Figure 10. Replica set and server list
    Screen capture showing replica set and server list
  30. Configure the proxy instance in the second proxy server (secondary master). Log in to the LMI. From the main menu, select Secure Web Settings > Manage > Reverse Proxy. From the toolbar, select New and select or enter as appropriate the following values in the New Reverse Proxy Instance window:
    PropertyValue
    Instance
    Instance Namedefault
    Host nameIBM-WRP81
    Listening Port7234
    IP Address for the Primary Interface10.10.10.210
    IBM Security Access Manager
    Administrator Namesec_master
    Administrator PasswordPassw0rd
    DomainDefault
    Transport
    Enable HTTPS[checked]
    HTTPS Port443
  31. Click Save to review and deploy the changes.
  32. Go back to Secure Web Settings > Manage > Reverse Proxy. Select default from the list and click Edit and select or enter the following values in the Reverse Proxy Basic Configuration window:
    PropertyValue
    Server
    Cluster is Master[unchecked]
    Master Instance Namedefault-webseald-IBM-WRP80
  33. Click Save to review and deploy the changes. Next, restart the instance.

    By restarting the proxy instance, the appliance initiates a synchronization with the primary master to bring all the configuration that includes any junction definitions.

  34. Figure 11 shows the Reverse Proxy Health widget in the LMI Dashboard after the configuration is complete.
    Figure 11. Reverse proxy configuration
    Screen capture showing Reverse proxy configuration

Front-end load balancer configuration

The ISAM for Web appliance comes with a default IP address for the management interface (M.x). For purposes of this scenario, we will change the IP address of the management interface and define three application interfaces (P.x) on each of the appliances that act as front-end load balancers.

  1. Log in to the LMI of the first load balancer (Active FELB). From the main menu, select Manage System Settings > Network Settings > Management Interfaces. Configure the first interface (M.1) with the following values:
    PropertyValue
    Enabled M.1[checked]
    IP4 Manual[checked]
    Address192.168.0.110
    Netmask255.255.255.0
    Gateway192.168.0.1
  2. Click Save Configuration and wait until the LMI interface is restarted or else manually restart the appliance from the console.
  3. Go back to the LMI (Active FELB). From the main menu, select Manage System Settings > Network Settings > Application Interfaces. Configure the first three interfaces with the following values:
    PropertyValue
    Interface 1 (P.1)
    Enabled[checked]
    IPv4 SettingsStatic
    Address192.168.0.120
    Netmask255.255.255.0
    Interface 2 (P.2)
    Enable[checked]
    IPv4 SettingsStatic
    Address10.10.10.100
    Netmask255.255.255.0
    Interface 3 (P.3)
    Enable[checked]
    IPv4 SettingsStatic
    Address10.0.0.2
    Netmask255.255.255.0
  4. Click Save to review and deploy the changes.
  5. From the main menu, select Manage System Settings > Network Settings > Front End Load Balancer. Choose the Servers tab. From the Virtual Servers toolbar, click New and select or enter as appropriate the following values:
    PropertyValue
    General
    Enabled[checked]
    NameSampleWebMobile
    Virtual Address192.168.0.157
    Port443
    Mask255.255.255.0
    InterfaceP.1
    Layer 4 or 74

    ISAM supports load balancing at layer 4 or 7 of the OSI network model. In layer 4, the TCP header information is used to determine how to process a request, while in layer 7 the load balancer can recognize application requests (for example, HTTP requests) and process these requests accordingly. Because we don't have a need in this scenario to manipulate the HTTP header or do SSL termination, we select layer 4 for simplicity and efficiency.

    Figure 12 shows the virtual server configuration window.

    Figure 12. Virtual server configuration
    Screen capture showing Virtual server configuration
  6. Click Save to review and deploy the changes.
  7. Go back to Manage System Settings > Network Settings > Front End Load Balancer. Choose the Servers tab and select SampleWebMobile from the list. Click Real Servers. From the Real Servers window, click New to add the reverse proxy servers:
    PropertyValue
    Real Server 1
    Enable[checked]
    Address10.10.10.200
    Port443
    Wight1
    Real Server 2
    Enable[checked]
    Address10.10.10.210
    Port443
    Wight2

    Figure 13 shows the real servers configuration window.

    Figure 13. Real servers configuration
    Screen capture showing real servers configuration
  8. Click Save to review and deploy the changes.
  9. Go back to Manage System Settings > Network Settings > Front End Load Balancer. Choose the General tab and select the following value:
    PropertyValue
    Load Balancer
    Enabled[checked]
  10. Click Save to review and deploy the changes.
  11. Repeat steps 1 through 10 to configure the second load balancer (Passive FELB). Use the corresponding values from Table 1. Network interfaces―Load Balancers for steps 1 and 3.
  12. Configure high availability. Log in to the LMI of the first load balancer (Active FELB) and from the main menu select Manage System Settings > Network Settings > Front End Load Balancer. Choose the High Availability tab and select or enter as appropriate the following values:
    PropertyValue
    Enable High Availability [checked]
    This load balancer is Primary
    Local InterfaceP.3
    Remote Address10.0.0.4
    Remote Port443
    Failover
    Health Check Interval[accept the default value]
    Health Check Timeout[accept the default value]
  13. Click Save to review and deploy the changes.

    Figure 14 shows the high availability configuration window.

    Figure 14. High availability configuration
    Screen capture showing High availability configuration
  14. Log in to the LMI of the second load balancer (Passive FELB) and repeat the previous step with the following values instead:
    PropertyValue
    Enable High Availability [checked]
    This load balancer is Backup
    Local InterfaceP.3
    Remote Address10.0.0.2
    Remote Port443
  15. Click Save to review and deploy the changes.
  16. Figure 15 shows the Load Balancer Health widget in the LMI Dashboard after the configuration is complete.
    Figure 15. Load balancer configuration
    Screen capture showing load balancer configuration

Testing the scenario

For purposes of demonstrating high availability and failover capabilities, we have considered the following basic tests in this scenario:

  • Distributed session cache configuration
  • High available front-end load balancing service
  • Failover authentication with forms authentication

Testing distributed session cache

  1. Access pdadmin via the console in the first proxy server (primary master) to limit the number of sessions globally. By default this value is unset or unlimited. Run the following command to set the policy: pdadmin> policy set max-concurrent-web-sessions 1
  2. Using your favorite browser, access the protected resource. In this scenario, we secure the sample WebSphere application Web 2.0 and Mobile Showcase. Figure 19 shows the login page using forms authentication and Figure 20 shows the sample application.
  3. Open a second browser session and try to access the same protected resource. You should receive an Additional Login Denied message. Figure 16 shows the message that is returned by the proxy server.
    Figure 16. Reverse proxy message
    Screen capture showing Reverse proxy message
  4. Reset the policy to its default value. Run the following command from the pdadmin console:

    pdadmin> policy set max-concurrent-web-sessions unset

Testing high available front-end load balancing service

  1. Log in to the LMI of the first load balancer (Active FELB) and shut down the appliance.
  2. Log in to the Local Management Interface or LMI of the second load balancer (Passive FELB) and verify the status of the Load Balancer Health widget in the LMI Dashboard. Figure 17 shows the status after the first load balancer went down.
    Figure 17. Load Balancer Health
    Screen capture showing load balancer health

    You might notice that because the first load balancer (10.0.0.2) went down, it now has a red x beside it, which indicates its unavailability. Also, the second load balancer (10.0.0.4) moved to active status.

    Notice that a heartbeat is transmitted between the two front-end load balancers so that the state of each front-end load balancer is known (see the local interface and remote address in Figure 14). When available, the primary front-end load balancer acts as the active load balancer. If the primary becomes unavailable, the backup load balancer can no longer detect heartbeats. In that situation, the backup load balancer assumes the virtual IP address and starts accepting requests from clients. The length of time before the failover takes place is governed by the failover configuration entries.

    Load balancing of HTTPS requests from virtual address 192.168.0.157 still works and clients do not experience a service disruption.

Testing failover authentication

  1. Ensure that only the first proxy server (primary master) is running. Figure 18 shows the Load Balancer Health widget, which indicates that the second proxy server (10.10.10.210) is unavailable.
    Figure 18. Load Balancer Health
    Screen capture showing load Balancer Health
  2. Using your favorite browser, access the protected resource. In this scenario, we secure the sample WebSphere application Web 2.0 and Mobile Showcase. Figure 19 shows the login page using forms authentication and Figure 20 shows the sample application.
    Figure 19. Default forms authentication
    Screen capture showing default forms authentication

    Figure 20. Sample Protected Application
    Screen capture showing sample protected application
  3. Ensure that your session is listed in the distributed session cache. Go to Secure Web Settings > Manage > Distributed Session Cache. Select default from the list and click Sessions in the toolbar. Figure 21 shows the current user session.
    Figure 21. DSC Sessions
    Screen capture showing DSC sessions
  4. Begin starting the second proxy server (secondary master). Without closing your previous browser session, shut down the first proxy server (primary master). Figure 22 shows the Load Balancer Health widget, which indicates that the first proxy server (10.10.10.200) is unavailable.
    Figure 22. Load Balancer Health
    Screen capture showing Load Balancer Health
  5. Go back to the sample application and click one of the sample options (for example, File Uploader). You should see the File Uploader page without having to reauthenticate. Forms authentication does not provide authentication data with every request. However, because DSC is enabled, the second proxy server is able to use the stored session to recognize the user.

Table 1. Network interfaces―Load Balancers

Appliance HostnameNetwork InterfacesComments
IBM-FLB80M.1: 192.168.0.110/24
Gateway: 192.168.0.1

P.1: 192.168.0.120/24
P.2: 10.10.10.100/24
P.3: 10.0.0.2/24

Active FELB. Appliance acting as primary front-end load balancer.
IBM-FLB81M.1: 192.168.0.111/24
Gateway: 192.168.0.1

P.1: 192.168.0.133/24
P.2: 10.10.10.110/24
P.3: 10.0.0.4/24

Passive FELB. Appliance acting as backup front-end load balancer.

Table 2. Network interfaces―Reverse proxy servers

Appliance HostnameNetwork InterfacesComments
IBM-WRP80M.1: 192.168.0.140/24
Gateway: 192.168.0.1

P.1: 10.10.10.200/24
P.2: 160.20.20.90/24

Primary master. Appliance acting as primary master and master proxy server.
Hosts file:
192.168.0.141 : IBM-WRP81
IBM-WRP81M.1: 192.168.0.141/24
Gateway: 192.168.0.1

P.1: 10.10.10.210/24
P.2: 160.20.20.91/24

Secondary master. Appliance acting as secondary master and replica proxy server.
Hosts file:
192.168.0.140 : IBM-WRP80

Conclusion

The IBM Security Access Manager for Web 8.0 provides clustering of reverse proxy servers, web single sign-on and session management, coarse-grained authorization, central policy server, and web application firewall along with load balancing capabilities. This unique set of features allows you to configure a highly scalable and failover solution that is designed to help protect web applications against fraudulent and unauthorized access.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security
ArticleID=971325
ArticleTitle=Build a front-end load balancer and failover reverse proxy with IBM Security Access Manager 8.0
publish-date=05302014