StepUp Authentication using SafeNet Access Exchange
SAS PCE Enterprise allows the creation of advanced StepUp Authentication flow within SafeNet Access Exchange. In StepUp Authentication, access to clients or resources is granted based on a user’s specific authentication level.
This feature allows additional authentication steps for actions involving sensitive data or transactions. In this way, security posture is enforced by preventing access from unauthorized individuals or those using less secure authentication methods.
Functionally, if the user session switches from a low level of authentication to a higher level, this feature can enforce Multi-Factor Authentication (MFA) or phishing-resistant authentication.
StepUp Authentication is based on Authentication Context Class Reference (ACR) and Authentication Methods References (AMR).
-
An ACR specifies a set of business rules that authentication requests must meet. These rules can often be fulfilled using various authentication methods, either individually or in combination.
For example, a low ACR value might indicate that only a password must be used, while a higher value could indicate MFA must be performed.
-
AMR refers to the mechanisms used during the authentication process. It is a claim in the ID Token or Access Token, often in the form of an array, that lists the methods used to authenticate the user.
Example values: pwd, otp, sta.
Use Case Scenarios
Use Case 1: SSO exists with LDAP password and ACR is set as password
-
Preconditions:
- An active SSO session exists in a browser with the first application (App1) using LDAP-based authentication.
- The ACR value is set to password (pwd).
-
Workflow:
- The user launches App2 in the same browser.
- The user attempts authentication with a live SSO session of App1.
-
Expected Result: The user is granted access using the LDAP SSO session.
-
Actual Result: The user is logged into App2 automatically, as the SSO session of App1 (authenticated with LDAP credentials) is recognized.
Use Case 2: SSO exists with LDAP password and ACR is set as OTP
-
Preconditions:
- An active SSO session exists in a browser with the first application (App1) using LDAP-based authentication.
- The second application (App2) requires OTP-based authentication.
- The ACR value is set to otp.
-
Workflow:
- The user launches App2 in the same browser.
- The user attempts authentication with a live SSO session of App1.
-
Expected Result:
- The system prompts for OTP verification.
- The user enters OTP.
- The user is granted access to App2 after successful OTP verification.
-
Actual Result: The SSO session of App1 (authenticated with LDAP credentials) is recognized. The user is logged into App2 after successful OTP verification.
Use Case 3: No SSO exists and ACR is set as OTP
-
Preconditions:
- No active SSO session exists in a browser with the first application (App1). App1 is configured for LDAP-based authentication.
- The second application (App2) requires OTP-based authentication.
- The ACR value is set to otp.
-
Workflow:
- The user launches App2 in a browser.
- The user is prompted to enter LDAP credentials.
- The user enters LDAP credentials.
- The user is prompted to enter OTP.
- The user enters OTP.
-
Expected Result: The user is granted access to App2 after entering correct LDAP credentials and successful OTP verification.
-
Actual Result: The user is logged into App2 after successful OTP verification.
Use Case 4: SSO exists with LDAP Password and required authentication level is OTP, but ACR is set as Certificate-based Authentication (CBA)
-
Preconditions:
- An active SSO session exists in a browser with the first application (App1) using LDAP-based authentication.
- The second application (App2) requires Certificate-based Authentication (CBA), which is stronger than the required authentication level (OTP).
- The ACR value is set to cba, but the authentication flow is defined as LDAP Password + OTP.
-
Workflow:
- The user launches App2 in the same browser.
- The user attempts authentication with a live SSO session of App1.
-
Expected Result:
- The system prompts for OTP verification.
- The user enters OTP.
- The user enters the correct OTP, but gets an error because the ACR value is set as CBA, which is stronger than the defined authentication level, OTP.
-
Actual Result: System prompts for OTP only. However, an error occurs after entering correct OTP, ERROR (no-match-acr): No matching acr values. CBA is not triggered because the authentication flow is defined as LDAP Password + OTP.
Use Case 5: SSO exists with LDAP password and ACR is set as CBA
-
Preconditions:
- An active SSO session exists in a browser with the first application (App1) using LDAP-based authentication.
- The second application (App2) requires CBA.
- The ACR value is set to cba.
-
Workflow:
- The user launches App2 in the same browser.
- The user attempts authentication with a live SSO session of App1.
-
Expected Result:
- The system prompts for OTP verification.
- The user enters OTP.
- After successful OTP verification, the user selects the certificate.
- The user is granted access to App2 after successful authentication.
-
Actual Result: The SSO session of App1 (authenticated with LDAP credentials) is recognized. The user is successfully logged into App2 after successful OTP and certificate verification.
Prerequisites
Before you proceed with the integration, ensure to complete the following prerequisites:
-
Configure the following:
-
Obtain the Agent BSID Key and Token Validator URL. You will need these values while configuring Advanced Browser Login Flow using the StepUp mechanism.
StepUp Authentication Configuration
Configuring StepUp Authentication in SafeNet Access Exchange involves:
Importing StepUp Authentication Flows
-
Importing StepUp Authentication Flows in the new SafeNet Access Exchange Setup
-
Importing StepUp Authentication Flows in an existing SafeNet Access Exchange Setup
Importing StepUp Authentication Flows in a new SafeNet Access Exchange Setup
-
Download the SafeNet Access Exchange package, extract the SafeNetOtpRealm.json file, and save it on your local machine.
-
Open the .json file in a text editor, go to Line 220, after
},
press enter, and paste one of the following OTP flow codes as per your preferred configuration: -
Save the .json file.
Caution
It is recommended to save the SafeNetOtpRealm.json file at a location other than the package directory.
-
Log in to SafeNet Access Exchange as an administrator.
-
In the left pane, click on the down arrow
and then, click Create realm.
-
Under Create realm, perform the following steps:
-
Under Resource file, click Browse to search and select the SafeNetOtpRealm.json file that you updated in previous steps.
-
In the Realm name field, enter a name for the realm.
-
Click Create.
-
Importing StepUp Authentication Flows in an existing SafeNet Access Exchange Setup
-
Log into SafeNet Access Exchange as an administrator and select your desired Realm (for example, PCE).
-
In the left pane, click Realm settings, and perform the following steps:
-
Open the realm-export.json file in a text editor, search for "alias": "SafeNet LDAP OTP Flow -Conditional Flow", before
{
, press enter, and paste one of the following OTP flow codes as per your preferred configuration: -
Save the realm-export.json file.
Caution
It is recommended to save the realm-export.json file at a location other than the package directory.
-
In the left pane, click on the down arrow
and then, click Create realm.
-
Under Create realm, perform the following steps:
-
Under Resource file, click Browse to search and select the realm-export.json file that you updated in previous steps.
-
In the Realm name field, enter a name for the realm.
-
Click Create.
-
Mapping ACR to Level of Authentication (LoA)
In a realm's general settings, you can define how ACR values map to specific Levels of Authentication (LoA). While the ACR can have any value, the LoA must be numeric. The ACR claim can be requested using the claims or acr_values parameters in the OIDC request and is also included in both the access token and ID token. The mapped LoA value is then used in authentication flow conditions.
Additionally, mapping can be defined at the client level if a specific client requires different values than those set at the realm level. However, as a best practice, it is recommended to adhere to realm-level mappings.
Perform the following steps to map ACR to LoA:
-
On SafeNet Access Exchange, in the left pane, select your desired realm.
-
In the left pane, under Configure, click Realm Settings.
-
On the General tab, click ACR to LoA Mapping and enter the keys and their values as shown in the screenshot given below.
-
Click Save.
Configuring Advanced Browser Login Flow using the StepUp Mechanism
Perform the following steps to configure the advanced browser login flow using the StepUp mechanism:
-
Under Configure, click Authentication.
-
On the Flows tab, select a StepUp flow as per your preferred configuration (for example, SafeNet StepUp LDAP OTP Flow).
The StepUp flow window (for example, SafeNet StepUp LDAP OTP Flow) is displayed.
-
On the StepUp flow window (for example, SafeNet StepUp LDAP OTP Flow), under SafeNet StepUp LDAP OTP Forms, perform the following steps:
-
Under First Factor LDAP, for Condition – Level of Authentication, click ⚙️. On the Condition – Level of Authentication config window, complete the following fields, and click Save.
Field Description Alias Enter pwd. Authenticator Reference Enter pwd. Authenticator Reference Max Age Enter 3600. The value is in seconds. loa-condition-level Enter 0. loa-max-age Enter 3600. The value is in seconds. -
Under First Factor LDAP, for Username Password Form, click ⚙️. On the Username Password Form config window, complete the following fields, and click Save.
Field Description Alias Enter pwd. Authenticator Reference Enter pwd. Authenticator Reference Max Age Enter 3600. The value is in seconds. -
Under Second Factor OTP, for Condition – Level of Authentication, click ⚙️. On the Condition – Level of Authentication config window, complete the following fields, and click Save.
Field Description Alias Enter otp. Authenticator Reference Enter otp Authenticator Reference Max Age Enter 3600. The value is in seconds. loa-condition-level Enter 1. loa-max-age Enter 3600. The value is in seconds. -
Under Second Factor OTP, for SafeNet Authentication Form, click ⚙️. On the SafeNet Authentication Form config window, complete the following fields, and click Save.
Field Description Alias Enter otp. Authenticator Reference Enter otp. Authenticator Reference Max Age Enter 3600. The value is in seconds. Agent BSID Key Enter the value that you obtained as a prerequisite. Token Validator URL Enter the value that you obtained as a prerequisite.
-
Configuring OIDC Scope for AMR Values
Authentication executions can optionally have a reference value configured. The Authentication Method Reference (AMR) protocol mapper can use this to populate the AMR claim in OIDC access and ID tokens (for more information on the AMR claim, refer to RFC-8176). When the AMR protocol mapper is configured for a client, it will populate the AMR claim with the reference value for any authenticator execution the user completes during the authentication flow.
Perform the following steps to configure OIDC Scope for AMR values:
-
Under Manage, click Client Scopes.
-
Under Client Scope, click on the acr scope.
-
Under acr openid-connect, go to the Mappers tab, and click Add mapper > By configuration.
-
Under Configure a new mapper, click Authentication Method Reference (AMR).
-
Under Add mapper, in the Name field, enter amr.
-
Click Save
Running the Solution
Refer to Configuring Postman as a Client in SafeNet Access Exchange.