MFA with SSO -Dynamically enforce MFA on the ServiceNow side based on the Identity provider response

[Randheer Singh]

From the San Diego release onwards, MFA can be enforced with SSO logins as well with the help of the adaptive authentication step-up authentication feature. 

1. This feature is helpful if the identity provider (IdP) does not support MFA for all users or some users.
2. An administrator can create policy conditions to enforce MFA based on user group membership or role for all or a specific IdP.

In this article, we will discuss how MFA can be dynamically enforced on the ServiceNow side if not enforced on the IdP side based on the attributes shared by the IdP as part of the SAML response/OIDC token.

The idea is that based on MFA attributes received in the login response, we will update the “enable multifactor authentication” flag on the sys_user record through the IdP user provisioning transform map. And once the flag is updated, we will leverage AA policy to dynamically enforce MFA based on the “enable multifactor authentication” flag.

Step 1: Install the plugin and enable the feature with system properties.

1.  Adaptive Authentication (com.snc.adaptive_authentication) plugin
2. Integration - Web Authentication (com.snc.integration.webauthn) plugin (optional to enable FIDO2-based MFA)
3. Enable these system properties
   1. Name - Enable Authentication Policy (glide.authenticate.auth.policy.enabled)  Value - Yes
   2. Name - Enable Multi-factor authentication (glide.authenticate.multifactor) Value - Yes
   3. Name - Enable Multi-Factor Authentication with SSO (glide.authenticate.mfa.with.multisso.enabled)  Value – Yes 

Step 2: Configure Step-up authentication policy

We will configure the policy for step-up authentication in the MFA context. The default policy is a step-up authentication policy; if one of the conditions associated with the step-up authentication policy evaluates to true, the user will be enforced with MFA.

In the policy condition, we can select the IdP. We must add another condition with the out-of-the-box available filter “User Based MFA” is true.

Step 3: Configure the Identity provider record

set “Update User Record Upon Each Login” as true.

Step 4: Configure Identity provider user provisioning transform map

In the field-maps associate, the custom attribute name is received from the IdP with the enable_multifactor_authn field of the sys_user table.

Note: The custom attribute will be available automatically if it is part of the SAML response.

Sample SAML response with custom attribute mfa_required

sys_user record's enable_multifactor_authn field will be updated on each user login based on the attribute shared by the IdP.

Step 5: Disable the business rule “Clear Multifactor Auth Settings” on the sys_user table.

Without disabling this, users will be forced to set up the authenticator app every time.

After following these five steps, the user will start seeing the MFA validation screen if the IdP has indicated that MFA has not been enforced at their end through the SAML response attribute.

Note: Modern IdPs have support to send MFA enforcement information as part of the SAML response.

Okta Documentation

https://developer.okta.com/docs/reference/api/sessions/#amr-object

Similar customization can be made for OIDC-based IdP as well. We can have a custom claim to receive the MFA enforcement information there.