Decoupling applications from OAuth Authorization Server

Introduction

With the evolution of 5G networks and the expansion of the “always on” world in which we live, online service providers are experiencing a demand explosion while their customers still expect lightning fast end user experiences. To address this, organizations are scaling their application servers and containers to meet the load. However, there will come a point where they face diminished returns on this tactic.

Traditionally, these applications consist of JavaScript based UI frameworks interacting with backend microservice REST APIs. These REST APIs are usually protected using OAuth standards. In ForgeRock world, this means…


Introduction

This is the continuation of the previous blog on Zero Downtime upgrade strategy using a blue/green deployment for AM. Traditionally, ForgeRock DS upgrades are handled via a rolling upgrade strategy using an in-place update. As many deployments have constraints around this approach (zero downtime, immutable etc), a parallel deployment approach or a blue/green strategy can be leveraged for upgrading ForgeRock DS servers.

This blog provides a high-level approach of using a blue/green methodology for updating ForgeRock DS-UserStores.

This corresponds to Unit 3: DS-UserStores in our overall ForgeRock upgrade approach.

ForgeRock Upgrade units

Unit 3: DS-User Store Upgrade


Introduction

The standard deployment for ForgeRock Identity platform consists of multiple ForgeRock products such as IG, AM, IDM and DS. As newer ForgeRock versions are released, deployments using older versions need to be migrated before they reach their end of life. Also, newer versions of ForgeRock provide features such as Intelligent authentication, latest OAuth standards etc which helps businesses to implement complex use-cases

ForgeRock deployment components

Problem Statement

Traditionally, ForgeRock upgrades are handled via a rolling upgrade strategy using an in-place update. This strategy doesn’t suit all deployments due to below constraints:

  • Many deployments don’t allow any downtime. …


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…


Both AM and IG support UMA 1.0.1 where AM acts as UMA Authorization Server (AS) and IG as UMA Resource Server (RS).

Currently there are some limitations in AM and IG support UMA support in IG, one of the most important is: PAT is stored in IG memory and is not persisted and if IG is restarted then the resource owner must perform the entire share process again. UMA 1.0.1 where AM acts as UMA Authorization Server (AS) and IG as UMA Resource Server (RS).

Note: This post is based on UMA 1.0.1 (Support for UMA 1.0 and UMA 1.0.1…


Note that OpenDJ also provides Account Lockout functionality, this article is based on OpenAM Account Lockout policies. Refer this users may get locked out with invalid login attempts. OpenAM offers both OpenAM provides “Account Lockout” functionality which can be used to configure various lockout parameters such as failure count, lockout interval etc .Refer this KB article for more differences between OpenAM and OpenDJ lockout polices.

Using OpenAM “Account Lockout” policies, users may get locked out with invalid login attempts. OpenAM offers both Memory and Physical lockouts. Using memory lockout, users get unlocked automatically after specified duration.

Many deployments use “Physical…


OpenAM provide HOTP authentication module which can send OTP to user’s email address and/or telephone number. By default, OpenAM doesn’t displays user’s email address and/or telephone number while sending this OTP.

Solution

Versions used for this implementation: OpenAM 13.5, OpenDJ 3.5
One of the solution can include extending out of the box OpenAM’s HOTP module:

  • Extend HOTP auth module (openam-auth-hotp).
  • Update below property in extended amAuthHOTP.properties: send.success=Please enter your One Time Password sent at
  • Extend HOTPService appropriately to retrieve user profile details.
  • Change extended HOTP module code as per below (both for auto send and on request):
substituteHeader(START_STATE, bundle.getString("send.success") …

OpenAM can act as both SP and IdP for SAML webSSO flows. OpenAM also provides ability to dynamically create user profiles.

When OpenAM is acting as SAML SP and Dynamic user profile is enabled, if user profile doesn’t exist on OpenAM then OpenAM dynamically creates this profile from attributes in SAML assertion.
The problem comes if user profile is updated at IdP side, all subsequent SAML webSSO flows doesn’t update these changes at OpenAM SP side. More details here: OPENAM-8340

Solution

Versions used for this implementation: OpenAM 13.5, OpenDJ 3.5

One of the solution can include extending OpenAM SP Attribute Mapper…

Charan Mann

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