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:
- ForgeRock Access Management 6.5 > Authentication and Single Sign-On Guide > Session Upgrade
- ForgeRock Access Management 6.5 > Authentication and Single Sign-On Guide > Performing Session Upgrade
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:
- ForgeRock Access Management 6.5 > Authorization Guide > Implementing Transactional Authorization
- ForgeRock Access Management 6.5 > Authorization Guide > Transactional Authorization Prerequisite Tasks
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
- 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.