Step-Up Authentication with Auth Trees in ForgeRock Access Manager

steve.robrahn · February 2, 2021, 5:00am

By Steve Robrahn
Originally posted on https://medium.com/@steve.robrahn

Introduction

The risk related to different actions within an application is not the same. The scale or scope of one action might have much higher risk than others. Administrative access obviously has higher risk because it may affect many users at once. Many high risk actions, like adding a new money recipient or moving a certain amount of money, often must be performed by end users. Application owners may need to require additional authentication steps before allowing higher risk access. These additional authentication steps are sometimes collectively known as step-up authentication.

ForgeRock’s Access Manager (AM) provides two options for enabling step-up authentication: session upgrade and transactional authorization. Both use the same basic functionality, but each option has subtle differences. Session upgrade requires the user to have achieved specific requirements during authentication, like authenticating again using the initial authentication service or authenticating to a specific service which requires additional factors. Transactional authorization requires the requester to pass the same authentication prompt each time a resource is accessed regardless of how they might have previously authenticated.

Problem

How can application administrators ensure users are automatically prompted again for authentication when accessing high risk resources? How can they be sure the user passed the required method when prompted for additional authentication? How can the application confirm which factors were used to authenticate? Authorization policies must be able to define which authentication factors are acceptable for authorization to access high-risk resources. Authentication services likewise must be configured to prompt for the desired authentication factors with the desired user experience.

Solution

Common Access Manager features

ForgeRock provides several features within Access Manager which can be used together to provide the control and assurance required to enable step-up authentication for applications.

Authorization policies can include environment conditions which require the user to pass a specific Authentication Service which includes the required authentication factors. Users can be prompted using session upgrade or transactional authorization if their session does not meet the environment conditions.
Web agents, the ForgeRock Identity Gateway (IG), or applications (via REST APIs) can query the policy endpoint to determine if the environment conditions required by the policy have been met before allowing access to resources.
‘Service’ is a session attribute which can also provide a list of authentication services passed during this session. Session properties must be added to the Session Property Whitelist to be retrieved from the sessions endpoint.

Session Upgrade

Session upgrade is a feature of AM which will prompt for additional user interaction when required by an authorization policy. A session can be upgraded many times to meet the environment condition requirements of different policies, however, each upgrade must be to a new combination of environment conditions. AM will evaluate session upgrade as successful and skip Auth Tree processing if the session already meets the policy’s configured environment conditions. Authentication services passed are automatically stored in the ‘Service’ attribute of a session.

Transactional Authorization

Transactional Authorization depends on the same session upgrade functionality. However, the addition of a transaction condition forces the conditions to be met on every access request regardless of the result of previous requests.

Testing Session Upgrade

Reference:

Prepare for policy-based session upgrade

Create an Auth Tree

Use a Scripted Decision node to determine if a session is present. (Sample script in Get Session Node notes.)
Retrieve ‘UserId’ from the session and add it to ‘username’ in the shared state using the Get Session Attributes node. ForgeRock Access Management 6.5 > Authentication and Single Sign-On Guide
Prompt for additional authentication using Push Sender and Push Result Verifier

Sample Step Up Auth Tree

Create an Authorization Policy

Create a basic Authorization Policy
Add an Environment Condition of type ‘AuthenticateToService’
Configure the name of your Auth Tree as the required service

Session Upgrade Authorization Policy

Regarding Authentication Levels as Environment Conditions: Environment conditions which require Authorization Levels only work with Authentication Chains as of AM version 7.1 (see RFE https://bugster.forgerock.org/jira/browse/OPENAM-16646.) for more details). The AM policy engine must evaluate which authentication services can meet the Auth Level condition to return advice including all Authentication Services which can meet the condition. Modules, which are used to build Authentication Chains, have an Auth Level attribute which can easily be used to calculate if a chain can meet a given Auth Level condition. There is not an equivalent attribute for Auth Trees and Nodes so the policy engine is unable to evaluate whether Auth Trees can meet the condition. As a result, only Authentication Chains are able to meet Auth Level conditions. For this reason, it is recommended to use ‘Authenticate to Service’ conditions when doing Session Upgrade with Auth Trees.

Perform policy-based session upgrade

Via browser — Agents and IG will automatically evaluate the policy for protected applications

Having already successfully authenticated to AM, navigate to the resource whose policy requires authentication to a specific service — https://app.example.com/sample
Agent or IG evaluates policies
Agent or IG redirects to AM for authentication
Authenticate to AM using required Auth Tree (StepUp) as a registered user
Upon success, AM redirects back to the protected resource
The Agent or IG evaluates the policies again and access is allowed

Via REST API — follow these steps as an authenticated system user who has been delegated access to request policy decisions via the privilege ‘Entitlement Rest Access’

Testing Transactional Authorization

Prepare for transactional authorization

Reference:

Create an Auth Tree (the same tree as session upgrade may be used.)

Use a Scripted Decision node to determine if a session is present.
Retrieve ‘UserId’ from the session and add it to ‘username’ in the shared state using the Get Session Attributes node ForgeRock Access Management 6.5 > Authentication and Single Sign-On Guide
Prompt for additional authentication using Push Sender and Push Result Verifier

Sample Transactional Authorization Auth Tree

Create an Authorization Policy

Create a basic Authorization Policy
Set Environment type as Transaction
Set Authentication Strategy as Auth to Service
Set Strategy Specifier as the name of your Auth Tree

Perform transactional authorization

Reference: ForgeRock Access Management 6.5 > Authorization Guide > Perform Transactional Authorization with AM Console

Via browser — Agents and IG will automatically evaluate the policy

Having already authenticated to AM, navigate to the protected resource — https://app.example.com/sample
Agent or IG evaluates policy
Agent or IG redirects to AM for authentication
Authenticate to AM using required Auth Tree (StepUp) as a registered user
Upon success, AM redirects back to the protected resource
the Agent or IG evaluates policies again and access is allowed

Via REST API — follow these steps as an authenticated system user who has been delegated access to request policy decisions via the privilege ‘Entitlement Rest Access’

Conclusion

A holistic step-up authentication strategy often requires more than one method to be successful. Session upgrade can prompt for the same authentication service again or a different authentication service. Transactional authorization can repeatedly prompt the user for the same authentication factor. When used together, these methods of authentication can help enable a more continuous approach to authentication for applications.