Configuring AM Behind a Reverse Proxy

Reverse proxies (such as ForgeRock Identity Gateway) are proxy servers that sit between clients and application servers. Their main function is to act on behalf of the application server, forwarding resources to the client as if they were the application server itself.

Modern reverse proxies also provide additional functionality such as load balancing, compression, SSL termination, web acceleration, and firewall capabilities.

Configuring a reverse proxy in front of your AM instances provides the following security benefits:

  • Protecting AM servers from denial of service attacks.

    A reverse proxy will terminate incoming connections and reopen them against the AM servers, effectively masking the AM IP addresses. This makes it more difficult for attackers to launch DoS attacks against them. A firewall can prevent direct access to the AM servers.

  • SSL termination/SSL offloading.

    Since reverse proxies terminate incoming connections to AM, they also decrypt the HTTPS requests and pass them unencrypted to the container where AM runs.

    This has several benefits, such as removing the need to install certificates in the containers, which simplifies the management of SSL/TLS.

    Depending on your environment, though, you may decide to configure SSL/TLS between AM and the reverse proxy, or configure the proxy to pass-through the SSL traffic to the container where AM runs.

    This guide, and the examples in other AM guides default to AM being configured to use HTTPS communication.

  • Provide a unique point of access to AM.

    Configuring a reverse proxy in front of AM creates a channel between the public network and the internal network.

    Since all communication to AM needs to come from the reverse proxy, you can, for example, restrict access to a set of trusted networks. You can fine-tune the access restrictions for each request and apply rate-limiting and load balancing such that a possible attack does not bring down your whole infrastructure.

  • Protect Endpoints

    In the same way that you can restrict access to trusted networks, you can also restrict access to any endpoint AM is exposing.

    AM exposes a number of internal administration endpoints, such as the /sessionservice endpoint. You must ensure those are not reachable over the Internet.

    For a list of internal endpoints that you should protect, see Service Endpoints.

    Regarding feature endpoints, AM makes endpoints accessible the moment an administrator creates a service. For example, the OAuth 2.0 endpoints are not available by default, but configuring an instance of the OAuth 2.0 provider service in a realm will make the endpoints available for that realm.

    You must ensure you are exposing the correct endpoints to the Internet.

Recommending how to set up your network infrastructure is beyond the scope of this guide. There are too many permutations that are valid use cases; for example, some environments may deploy a reverse proxy for its load balancing capabilities instead of dedicated, hardware-based load balancers. More complex deployments may have multiple layers of firewalls, load balancers, and reverse proxies.

The following figure is an example of a possible configuration:

Exposing Only a Reverse Proxy to the Internet
Exposing only a reverse proxy to the Internet

Configuring the Base URL Source Service

In many deployments, AM determines the base URL of a provider using the incoming HTTP request. However, there are often cases when the base URL of a provider cannot be determined from the incoming request alone, especially if the provider is behind some proxying application. For example, if an AM instance is part of a site where the external connection is over SSL but the request to the AM instance is over plain HTTP, then AM would have difficulty in reconstructing the base URL of the provider.

In these cases, AM supports a provider service that allows a realm to have a configured option for obtaining the base URL including protocol for components that need to return a URL to the client.

To Configure the Base URL Source Service
  1. In the AM console, go to Realms > Realm Name > Services.

  2. Click Add a Service, select Base URL Source, and then click Create, leaving the fields empty.

  3. For Base URL Source, select one of the following options:

    Base URL Source Options
    Extension class

    Click the Extension class to return a base URL from a provided HttpServletRequest object. In the Extension class name field, enter

    Fixed value

    Click Fixed value to enter a specific base URL value. In the Fixed value base URL field, enter the base URL.

    Forwarded header

    Click Forwarded header 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.

    Host/protocol from incoming request (default)

    Click Host/protocol from incoming request to get the hostname, server name, and port from the HTTP request.

    X-Forwarded-* headers

    Click X-Forwarded-* headers to use non-standard header fields, such as X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto.

  4. In the Context path, enter the context path for the base URL. If provided, the base URL includes the deployment context path appended to the calculated URL. For example, /openam.

  5. Click Finish to save your configuration.

Read a different version of :