Web Policy Agents 5.9.1

Configuration for Load Balancers and Reverse Proxies

Most environments deploy a load balancer and reverse proxy between the agent and clients, and another between the agent and AM, as shown in the following diagram:

Simplified diagram showing reverse proxies and load balancers configured in an environment with web agents.
Figure 1. Environments with Load Balancers and Reverse Proxies

The reverse proxy and the load balancer can be the same entity. In complex environments, multiple load balancers and reverse proxies can be deployed in the network.

Identifying Clients Behind Load Balancers and Reverse Proxies

When a load balancer or reverse proxy is situated in the request path between the agent and a client, the agent does not have direct access to the IP address or hostname of the client. The agent cannot identify the client.

For load balancers and reverse proxies that support provision of the client IP and hostname in HTTP headers, configure the following properties:

When there are multiple load balancers or reverse proxies in the request path, the header values can include a comma-separated list of values, where the first value represents the client, as in client,next-proxy,first-proxy.

Agent Connection to AM Through a Load Balancer/Reverse Proxy

When a reverse proxy is situated between the agent and AM, it can be used to protect the AM APIs.

When a load balancer is situated between the agent and AM, it can be used to regulate the load between different instances of AM.

Consider the points in this section when installing Web Agent in an environment where AM is behind a load balancer or a reverse proxy.

Agent’s IP Address and/or FQDN

The load balancer or reverse proxy conceals the IP addresses and FQDNs of the agent and of AM. Consequently, AM cannot determine the agent base URL.

To prevent problems during installation or redirection, do the following:

  • Configure the load balancer or reverse proxy to forward the agent IP address and/or FQDN in a header.

  • Configure AM to recover the forwarded headers. For more information, see Configuring AM to Use Forwarded Headers.

  • Install the agent using the IP address or FQDN of the load balancer or reverse proxy as the point of contact for the AM site.

AM Sessions and Session Stickiness

Improve the performance of policy evaluation by setting AM’s sticky cookie (by default, amlbcookie) to the AM’s server ID. For more information, see Configuring Site Sticky Load Balancing in AM’s Setup Guide.

When configuring multiple agents, consider the impact on sticky load balancer requirements of using one or multiple agent profiles:

  • If agents are configured with multiple agent profiles, configure sticky load balancing. The agent profile name is contained in the OpenID Connect JWT, used by the agent and AM for communication. Without session stickiness, it is not possible to make sure that the appropriate JWT ends in the appropriate agent instance.

    To have multiple agent profiles without sticky load balancing, disable validation of the aud claim in the session ID token. Either enable Disable Audience Claim Validation, or configure Agent Profile ID Allow List.

    For security reasons, agents should validate all claims in session ID tokens. Therefore, use this approach sparingly and mostly for migrations.

  • If multiple agents are configured with the same agent profile, decide whether to configure sticky load balancing depending on other requirements of your environment.

WebSockets

For communication between the agents and the AM servers, the load balancers and reverse proxies must support the WebSocket protocol. For more information, see the load balancer or proxy documentation.

For an example of how to configure Apache HTTP as a reverse proxy, see Configuring Apache HTTP Server as a Reverse Proxy Example.

Configuring AM to Use Forwarded Headers

When a load balancer or reverse proxy is situated between the agent and AM, configure AM to recover the forwarded headers that expose the agents' real IP address or FQDN.

To configure how AM obtains the base URL of web agents, use the Base URL Source service:

  1. Log in to the AM console as an administrative user, such as amAdmin.

  2. Select Realms > Realm Name > Services.

  3. Select Add a Service > Base URL Source, and create a default service, leaving the fields empty.

  4. Configure the service with the following properties, leaving the other fields empty:

    • Base URL Source: X-Forwarded-* headers

      This property allows AM to retrieve the base URL from the Forwarded header field in the HTTP request. The Forwarded HTTP header field is standardized and specified in RFC 7239.

    • Context path: AM’s deployment URI. For example, /openam.

    For more information, see Base URL Source in AM’s Reference.

  5. Save your changes.

Agent Connection to Clients Through a Load Balancer/Reverse Proxy

When a reverse proxy is situated between the agent and client, it can be used to anonymize the client traffic that enters the network.

When a load balancer is situated between the agent and client, it can be used to regulate the load between the agents and the web application servers.

Consider the points in this section when installing Web Agent in an environment where clients are behind a load balancer or a reverse proxy.

Client’s IP Address and/or FQDNs

The load balancer or reverse proxy conceals the IP addresses and FQDNs of the agent and clients. Consequently, the agent cannot determine the client base URL.

Configure the load balancer or reverse proxy to forward the client IP address and/or the client FQDN in a header. Failure to do so prevents the agent from performing policy evaluation, and applying not-enforced and conditional login/logout rules.

For more information, see Configuring Client Identification Properties.

POST Data Preservation and Sticky Load Balancing

For POST data preservation, use sticky load balancing to ensure that after login the client hits the same agent as before and can therefore get their saved POST data.

Agents provide properties to set either sticky cookie or URL query string for load balancers and reverse proxies.

For more information, see Configure POST Data Preservation for Load Balancers or Reverse Proxies.

Mapping Agent Host Name to a Load Balancer or Reverse Proxy

In the following diagram, the agent and load balancer/reverse proxy use the same protocol and port, but different FQDNs:

Simplified diagram showing reverse proxies and load balancers using the same protocol and port than the web servers.
Figure 2. Same Protocol and Port, Different FQDN

Map the host name of the agent to that of the load balancer or reverse proxy.

  1. Log in to the AM console as an administrative user with rights to modify the web agent profile.

  2. Go to Realms > Realm Name > Applications > Agents > Web > Agent Name.

  3. Set the following options in the Global tab:

    • FQDN Check: Enable

      The equivalent property setting is Enable FQDN Check = true.

    • FQDN Default: Set to the FQDN of the load balancer or proxy, for example lb.example.com. Do not set it to the protected server FQDN where the agent is installed.

      The equivalent property setting is FQDN Default = lb.example.com.

    • Agent Root URL for CDSSO: Set to the FQDN of the load balancer or proxy, for example https://lb.example.com:80/.

      The equivalent property setting is Agent Root URL for CDSSO = lb.example.com.

    • FQDN Virtual Host Map: Map the load balancer or proxy FQDN to the FQDN where the agent is installed. For example,

      • Key: agent.example.com (protected server)

      • Value: lb.example.com (load balancer or proxy)

        The equivalent property setting is com.sun.identity.agents.config.fqdn.mapping[agent.example.com]=lb.example.com.

  4. Save your work.

Overriding Protocol, Host, and Port

The load balancer or reverse proxy forwards requests and responses between clients and protected web servers. In the following diagram, the protocol, port, and FQDN configured on the load balancer and reverse proxy are different than those on the protected web server:

Simplified diagram showing reverse proxies and load balancers using different protocol, port, and FQDN than the web servers.
Figure 3. Different Protocol, Port, and FQDN
Agent configuration for SSL offloading prevents FQDN checking and mapping. Consequently, URL rewriting and redirection do not work correctly when the agent is accessed directly and not through the load balancer or proxy. This should not be a problem for client traffic, but could be a problem for web applications accessing the protected container directly, from behind the load balancer.

When the following headers are defined on the proxy or load-balancer, they override the value of Agent Deployment URI Prefix:

  • X-Forwarded-Proto

  • X-Forwarded-Host

  • X-Forwarded-Port

If you are using these headers, do not configure the agent to override its hostname, port, or protocol.

Use Agent Deployment URI Prefix to override the agent protocol, host, and port with that of the load balancer or reverse proxy.

  1. Log in to the AM console as an administrative user with rights to modify the agent profile.

  2. Go to Realms > Realm Name > Applications > Agents > Web > Agent Name.

  3. Set the following options in the Global tab:

    • Agent Deployment URI Prefix: Set to the URI of the load balancer or proxy. For example, https://external.example.com:443.

      This value is used to override the protocol, host, and port of the protected server.

      The equivalent property setting is Agent Deployment URI Prefix = https://external.example.com:443.

    • Agent Root URL for CDSSO: Set to the FQDN of the load balancer or proxy, for example https://lb.example.com:80/.

      The equivalent property setting is Agent Root URL for CDSSO = lb.example.com.

  4. Enable the following options in the Advanced tab:

  5. Save your work.

Configuring Client Identification Properties

After configuring proxies or load balancers to forward the client FQDN and/or IP address, configure the agents to check the appropriate headers.

This procedure explains how to configure the client identification properties for a centralized web agent profile configured in the AM console. The steps also mention the properties for web agent profiles that rely on local, file-based configurations:

  1. Log in to the AM console with a user that has permissions to modify the web agent profile.

  2. Go to Realms > Realm Name > Applications > Agents > Web > Agent Name.

  3. Set the following options in the Advanced tab:

    • Client IP Address Header: Configure the name of the header containing the IP address of the client. For example, X-Forwarded-For.

      The equivalent property setting is Client IP Address Header = X-Forwarded-For.

      Configure this property if any of the following points are true:

      • AM policies are IP address-based.

      • The agent is configured for not-enforced IP rules.

      • The agent is configured take any decision based on the client’s IP address.

    • Client Hostname Header: Configure the name of the header containing the FQDN of the client. For example, X-Forwarded-Host.

      The equivalent property setting is Client Hostname Header = X-Forwarded-Host.

      Configure this property if any of the following points are true:

      • AM policies are URL address-based.

      • The agent is configured for not-enforced URL rules.

      • The agent is configured take decisions based on the client’s URL address.

  4. Save your changes.

Configuring POST Data Preservation for Load Balancers or Reverse Proxies

Use one of the following procedures to configure post data preservation for load balancers or reverse proxies.

Map One Agent Profile to One Agent Instance When POST Data Preservation is Enabled

In this procedure, a separate agent profile must created in AM for each agent instance. For scalable deployments, where resources are dynamically created and destroyed, use Map One Agent Profile to Multiple Agent Instances When POST Data Preservation is Enabled instead.

  1. Configure your load balancer or reverse proxy to ensure session stickiness when the cookie or URL query parameter are present.

  2. Log in to the AM console as a user that has permissions to modify the agent profile.

  3. Go to REALMS > Realm Name > Applications > Agents > Web > Agent Name.

  4. Set the following options in the Advanced tab:

    • POST Data Sticky Load Balancing Mode:

      • COOKIE: The agent creates a cookie for POST data preservation session stickiness. The content of the cookie is configured in the next step.

      • URL: The agent appends to the URL a string specified in the next step.

        The equivalent property setting is com.sun.identity.agents.config.postdata.preserve.stickysession.mode=COOKIE or com.sun.identity.agents.config.postdata.preserve.stickysession.mode=URL.

    • POST Data Sticky Load Balancing Value: Configure a key-pair value separated by the = character.

      The agent creates the value when it evaluates POST Data Sticky Load Balancing Mode. For example, specifying lb=myserver either sets a cookie called lb with myserver as a value, or appends lb=myserver to the URL query string.

      The equivalent property setting is com.sun.identity.agents.config.postdata.preserve.stickysession.value=lb=myserver.

  5. Save your changes.

Map One Agent Profile to Multiple Agent Instances When POST Data Preservation is Enabled

Use this procedure for scalable deployments, where resources can be dynamically created or destroyed. For example, use it in deployments with load balancing, or environments running Kubernetes.

  1. Configure your load balancer or reverse proxy to ensure session stickiness when the cookie or URL query parameter are present.

  2. For each agent instance, configure post data preservation in the agent configuration file agent.conf. This configuration overrides the configuration in AM.

    In the following example, the settings in agent.conf configure two agents behind a load balancer to use the same agent profile, and provide uniqueness to the load balancer:

    • Agent 1:

      com.sun.identity.agents.config.postdata.preserve.stickysession.mode = COOKIE
com.sun.identity.agents.config.postdata.preserve.stickysession.value = EXAMPLE=Agent1

    • Agent 2:

      com.sun.identity.agents.config.postdata.preserve.stickysession.mode = COOKIE
com.sun.identity.agents.config.postdata.preserve.stickysession.value = EXAMPLE=Agent2

    For information about the values to use, see the following properties:

  3. Restart the web server where the agent is installed.

Copyright © 2010-2023 ForgeRock, all rights reserved.