How to Integrate Advanced Auth, Risk-Based Auth, and SSPR with an Authorization Policy

Micro Focus - Cool Solution
by Gary L. Gilbert

Use Case

Users of an organization are required to have an email address before allowing access to a protected resource. If the authenticated user does not have an email address, then the user is redirected to SSPR to fill out their missing profile information. Otherwise, if the authenticated user already has an email address, they’re required to perform second-factor authentication on their initial access to the protect resource and again every 60 days going forward.

Technical Overview

Prerequisites

This solution assumes NetIQ Access Manager (NAM 4.5 or later) is installed and protected resources are behind the Access Gateway (AG). The Identity Provider (IDP) is integrated with Advanced Authentication Framework (AAF), and Self-Service Password Reset (SSPR) is installed.

Solution Process Flow

The solution diagram below illustrates the process flow between components involved in setting up a combined Authorization Email Check, Risk-Based Authentication, and Advanced Authentication integrated solution.

The following steps will guide you through the setup of policies and configuration of the components shown in the process flow above. The basic premise is to prompt for second-factor authentication (if needed) using the Email OTP method provided within AAF. AAF is configured to auto-enroll the user with the Email OTP authenticator if they have an email address. If the user does not have an email address, they are not allowed access and can’t proceed with second-factor authentication until they update their profile in SSPR with an email address. If the user has a valid email address, then a risk-based policy is invoked that will determine if the user needs second-factor authentication before allowing access.

Integrating Advanced Authentication Framework (AAF) with Access Manager (NAM)

Overview

The Advanced Authentication Framework will provide second-factor authentication when invoked by Access Manager. The solution involves a basic setup of AAF integrated with NAM using either the OAUTH2 or NAM AA Plugin Methods. For this solution, the user is auto-enrolled with the Email OTP method. If the user does not have an email address, they will not be enrolled until they update their profile with a valid email address.

Proceed with integrating Advanced Authentication with Access Manager by using any one of the following approaches:

• Plug-in-based approach: The Advanced Authentication functionality is embedded in Access Manager.
• OAuth-based approach: (Recommended) This is available in Access Manager 4.4 and later versions. This approach uses the OAuth claims-based authentication mechanism for secure and trusted communication. Any new methods introduced in the Advanced Authentication server become dynamically available in Access Manager without making any modification in the product.

Create a new OAuth2 event in AAF for integration to Access Manager

In the Advanced Authentication administration console, perform the following steps to configure an event:

1. Prerequisites (Email OTP Method and Chain already created).
2. Click Events | New Event.
3. Specify a name for the event.
4. Select OAuth2 from Event type.
5. Select the Email OTP Method and Chain or any other required chains you wish to use with NAM.
   
   

NOTE: You need to notate the Client ID and Client secret while configuring the Advanced Authentication server in Access Manager. You cannot view the Client secret later, therefore you must make a note of this value.

Configure the Advanced Authentication Server Details in Access Manager

1. Login to the Access Manager Console.
2. Click Devices | Identity Servers | Shared Settings | Advanced Authentication.
3. Specify the domain name or IP address of the Advanced Authentication server and port in Server Domain.
4. Select Integrate using OAuth under OAuth Event Configuration.
5. Specify the Event Name, Client ID, and Client Secret.
   
   
6. Click Apply.
   
7. Verify that the endpoint has been created in the Advanced Authentication server. Go to the Advanced Authentication administration portal and verify that the hostname or domain name of the Identity Server cluster is displayed as the endpoint under Endpoints.
   
8. In Access Manager, go to Dashboard and click Certificates | Trusted Roots to verify if the Advanced Authentication server certificate is available. If the certificate is not available, then perform the following steps to import the certificate:
   1. Click Certificates | Trusted Roots | Auto-Import from Server.
   2. Specify the server IP/DNS, port, and certificate name.
   3. Click OK.

9. Make sure the same user store or repository is being used in the Advanced Authentication server.

Configure a Second-Factor Authentication Method in Access Manager (NAM)

This solution allows Access Manager to perform the first factor authentication when protecting a resource using the standard Secure Name/Password Contract.  For second-factor authentication, we will use Advanced Authentication using the Email OTP that we already setup above.

The following steps show how to setup second-factor authentication:

Note: For this solution, we only need to create a class and method for the AAF second-factor authentication. The method will be called from a risk-based authentication policy (see below).

Create a new Class

1. Login to the Access Manager Console.
2. Create a new class.
3. Click Devices | Identity Servers | Edit | Local | Classes.
4. Click New, then specify the name for the class and select Advanced Authentication Generic Class for the Java class
5. Click Next | Finish.
   

Create a new Method

1. Click Devices | Identity Servers | Edit | Local | Methods | New.
2. Select the class you created above.
3. Specify a user store.
   
   

Configure a Risk-Based Authentication Method and Contract in Access Manager (NAM)

Now that we setup a second-factor authentication class and method, we also need to setup a Risk-Based Authentication class, method, and contract.

The following steps show how to setup the Risk-Based Authentication class, method, and contract:

Create a new Class

1. Login to the Access Manager Console.
2. Create a new class.
3. Click Devices | Identity Servers | Edit | Local | Classes.
4. Click New, then specify the name for the class and select Risk-based Auth Class for the Java class
5. Click Next | Finish.
   

Create a new Method

1. Click Devices | Identity Servers | Edit | Local | Methods | New.
2. Select the class you created above.
3. Uncheck “Identifies User”
4. Specify a user store.
   
   
   

Create a new Contract

1. Click Devices | Identity Servers | Edit | Local | Contracts | New.
2. In URI, specify a value that uniquely identifies the contract from all other contracts. This value is used to identify this contract for external providers and is a unique path value that you create.
3. In Methods, add the Advanced Authentication method that you created in the preceding step.
4. Click Apply | OK.
   
   
5. On the Authentication Card tab (or next from the wizard), enter the display Text, select an Image, uncheck Show Card
   
   
6. Update Identity Servers.

Configure a Risk-Based Authentication Policy in Access Manager (NAM)

Now that we setup second-factor authentication class, we need to call it from a Risk-Based Authentication policy.

The following steps show how to setup the Risk-Based Authentication policy:

Add a Risk Policy

1. Click Policies > Risk-based Policies > Risk Policy.
2. Click the Create Risk Policy icon.
3. Enter the Policy Name and Description
4. Specify the name for the IDP cluster and select Risk-based Auth Class for the Authentication class.
5. Under Policy Rules, click Action – Create Rule. Choose the Last Login Rule
   
6. Configure the Last Login Rule.
   Note: Be sure to check Secure Cookie (needed for MS Edge).
   
7. Set the Risk Score to 100 (when rule condition is not met). This score will be set also if the Last Login cookie does not exist.
   
8. Under Risk Levels, click Action – Add Risk Level
   
9. Configure the risk level to invoke second-factor authentication and reduce the score to “0” after authentication. Choose the AAF “Email OTP” class you setup earlier.
   
   
   
10. The final policy should look like this:
    

Configure an AG Authorization Policy in Access Manager (NAM)

Now that we setup both the second-factor authentication and risk-based authentication, we need to trigger the process flow by invoking from an AG Authorization policy on a protected resource.

The following steps show how to setup the Authorization policy:

Add an Authorization Policy

1. Click Policies > Master Container > New.
2. Create a new Authorization Policy – Specify a name and choose Access Gateway: Authorization from the dropdown list.
3. The policy will be defined with 2 rules. The first rule checks if the “Email Address” exists. If true, invoke the RBA Contract that you created in the earlier steps:
   
   
4. The second rule is a fall-through rule. In case the email does not exist, redirect the user to SSPR to update their profile:
   In this case, the user is redirected to the SSPR CommandServlet to update their profile. After completed, the user is forwarded to AG Logout.
   
   For Example: https://app.mydomain.com/sspr/private/CommandServlet?processAction=checkAll&forwardURL=https%3A%2F%2Fapp.mydomain.com%2FAGLogout
   
5. Assign the Authorization Policy you just created to a protected resource.
   

Test Scenarios

To test the solution, login with a user that does not have an email address. You should be redirected to SSPR to fill out profile information. Next, test with the same user again. This time you should be prompt for an Email OTP for second-factor authentication. After entering the Email OTP, verify that the Last Login Cookie was created in the browser. Now login with the user again. Since the Last Login cookie exists and is not expired, you should be allowed access to the protected resource without being prompt for second-factor authentication:

Scenario #1:  Test User has no Email Address

1. Launch URL for protected resource.
2. You should be redirected to the IDP for primary authentication
   
3. Login with the test user that does not have an email address.
4. You should be redirected to SSPR to update profile information
   
5. Complete profile and logout.
   
   

Scenario #2:  Test User has Email Address and accessing protected resource for first time

1. Launch URL for protected resource.
2. User should be redirected to the IDP for primary authentication
   
   
3. User should be prompt for second-factor authentication.
   
   
4. Enter Email OTP and click Sign In.
5. Verify the user is allowed access to protected resource.
6. Verify the Last Login cookie was set in the browser.
   
   

Scenario #3:  Test User has Email Address and accessing protected resources again.

1. Launch URL for protected resource.
2. User should be redirected to the IDP for primary authentication
   
3. Verify the user is allowed access to protected resource and was not prompt for second-factor authentication.

This article can be downloaded as a PDF:

 PDF