ForgeRock AM Active/Active deployment routing using IG

Introduction

The standard deployment pattern for ForgeRock Identity platform is to deploy the entire platform in multiple datacenters/ cloud regions. This is done to ensure the availability of services in case of outage in one datacenter. Also, this approach provides performance benefits where load can be distributed among multiple datacenters for providing performance benefits. Below is the example diagram for Active/Active deployment:

Problem Statement

ForgeRock Access Manager provides both Stateful/CTS-based and Stateless/Client-based sessions. Global deployment use-cases require seamless Single sign-on (SSO) experience among all applications with following constraints:

  • Certain deployments have distributed applications such as App-A deployed only in DataCenter-A and App-B delployed only in DataCenter-B.
  • End user may travel to different locations like traveling from East to West US. This means application access requests handled by different data-centers.

To achieve these use-cases, CTS replication has to be enabled across multiple datacenters/ cloud regions.

In some situations, a user may try to access an application hosted in a specific datacenter before his corresponding session have been replicated. This can result in prompting users to re-authenticate and hence degrading user experience.

Note: This problem may be avoided if Client-based sessions are leveraged but many deployments have to use CTS-based sessions due to current limitations in Client-based sessions. Also, when CTS-based sessions are used then impact of CTS replication is much more than Client-based sessions.

This document provides an option to leverage IG to intelligently route session validation requests to the single datacenter irrespective of application being accessed.

Solution

ForgeRock Identity Gateway(IG) can be leveraged to resolve this problem. IG can route session validation requests to a specific data center/region depending on an additional “Site cookie” generated during user’s authentication.

This approach ensures that AM datacenter which issued user’s session is used for corresponding session validation calls. This also means that CTS replication is not required across multiple datacenters/ cloud regions.

AM configuration

  • Install AM 6.5.x and corresponding DS stores, Amster etc. Sample Amster install command:
  • Repeat above steps for configuring AM in all datacenters.

IG configuration

  • Repeat above steps for deploying IG in all datacenters.

Testing use-cases

User access application deployed in DC-A first:

  1. User access app1.example.com deployed in DC-A
  2. IG deployed in DC-A redirects request to AM deployed in DC-A for authentication
  3. “DataCenterCookie” is issued with DC-A value
  4. User access app2.example.com deployed in DC-B
  5. IG deployed in DC-B redirects request to AM deployed in DC-A for session validation

User access application deployed in DC-B first:

  1. User access app2.example.com deployed in DC-B
  2. IG deployed in DC-B redirects request to AM deployed in DC-B for authentication
  3. “DataCenterCookie” is issued with DC-B value
  4. User access app1.example.com deployed in DC-A
  5. IG deployed in DC-A redirects request to AM deployed in DC-B for session validation

Extending to OAuth/OIDC use-cases

  • OAuth: AM 6.5.2 provides option to modify Access tokens using scripts, this allows additional metadata in stateless OAuth tokens such as “dataCenter”. This information can be leveraged by IG OAuth RS to invoke appropriate dataceter’s AmService objects for tokenInfo/ introspection endpoints.

References

Identity & Access Management Architect / Implementation Engineer/ Principal Consultant / Software Developer https://www.linkedin.com/in/charanmann/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store