ForgeRock AM Active/Active deployment routing using IG

Charan Mann
4 min readOct 31, 2019

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:
install-openam — serverUrl http://am-A.example.com:8094/am — adminPwd cangetinam — acceptLicense — userStoreDirMgr “cn=Directory Manager” — userStoreDirMgrPwd “cangetindj” — userStoreHost uds1.example.com — userStoreType LDAPv3ForOpenDS — userStorePort 1389 — userStoreRootSuffix dc=example,dc=com — cfgStoreAdminPort 18092 — cfgStorePort 28092 — cfgStoreJmxPort 38092 — cfgStoreSsl SIMPLE — cfgStoreHost am-A.example.com — cfgDir /home/forgerock/am11 — cookieDomain example.com
am> connect http://am-A.example.com:8094/am -i
Sign in
User Name: amadmin
Password: **********
amster am-A.example.com:8094> import-config — path /home/forgerock/work/amster
Importing directory /home/forgerock/work/amster
Imported /home/forgerock/work/amster/global/Realms/root-employees.json
Imported /home/forgerock/work/amster/realms/root-employees/CoookieSetterNode/e4c11a8e-6c3b-455d-a875–4a1c29547716.json
Imported /home/forgerock/work/amster/realms/root-employees/DataStoreDecision/6bc90a3d-d54d-4857-a226-fb99df08ff8c.json
Imported /home/forgerock/work/amster/realms/root-employees/PasswordCollector/013d8761–2267–43cf-9e5e-01a794bd6d8d.json
Imported /home/forgerock/work/amster/realms/root-employees/UsernameCollector/31ce613e-a630–4c64–84ee-20662fb4e15e.json
Imported /home/forgerock/work/amster/realms/root-employees/PageNode/55f2d83b-724b-4e3a-87cc-247570c7020e.json
Imported /home/forgerock/work/amster/realms/root-employees/AuthTree/LDAPTree.json
Imported /home/forgerock/work/amster/realms/root/J2eeAgents/IG.json
Import completed successfully

- Creates /root realm aliases: am-A.example.com and am-B.example.com
- AM Agent to be used by IG in /root realm- LDAPTree to create cookie after authentication. Update Cookie value as DC-A or DC-B, dependending on datacenter being used
  • Repeat above steps for configuring AM in all datacenters.

IG configuration

- frProps.json to specify AM primary and secondary DC endpoints. Refer frProps-DC-A for DC-A and frProps-DC-B for DC-B.- config.json to declare primary and secondary AmService objects- 01-pep-dc-igApp.json to route session validation to specific datacenter, depending on “DataCenterCookie” value.
  • 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.
{
“sub”: “user.88”,
“cts”: “OAUTH2_STATELESS_GRANT”,
“auth_level”: 0,
“iss”: “http://am6521.example.com:8092/am/oauth2/employees",

“dataCenter”: “DC-A”
}

References

--

--

Charan Mann

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