Conditional Multi-Factor

The Conditional Multi-Factor action adds a condition after the authenticator has run. The condition decides if additional factors are required. This means it is a dynamic way of adding additional factors to the authentication.

It can be configured to operate in three different condition modes:

Mode Description
Attribute Enable Condition Checks for a boolean attribute and runs second factor if true.
Attribute ACR Condition Checks for an attribute containing an ACR, that ACR is used as the second factor.
Subject Condition Matches the subject against a rule-set. Picks second factor based on the rule configured for the match.

Attribute Enable Condition

The Attribute Enable Condition mode runs a predefined second factor if the condition is met.

The condition is an attribute from the authenticator or previous actions that is set to true. When true, the MFA action will run that second factor before letting the user through.

The attribute the action looks for by default is named requireSecondFactor but can be configured to any attribute name.

A common use is to configure another action before the Conditional Multi-Factor action to look up an attribute about the user. If the requireSecondFactor has the value true the second factor is triggered.



The second factor to use when condition is true is statically configured on the action along with the attribute name to look for.


Fig. 108 Configuration of the Attribute Enable Condition

Attribute ACR Condition

With the Attribute ACR Condition mode, you allow the user to configure their preferred second factor. This is done out of band, and placed in a data source or other place where the actions can find the attribute.


Example: The user wants SMS to always be enabled as a second factor when logging in. This can be achieved by adding the ACR for the SMS authenticator configured to the users data. By default the Conditional Multi-Factor action looks for the ACR in the attribute named secondFactorAcr (this can be changed via configuration).

When that attribute is found, the ACR is looked up, and if it matches an existing authenticator, it will be triggered. If there is no authenticator matching the ACR, the action will fail and the user will not be able to log in.


If the ACR found for a user does not exist in the current configuration the authentication for that user will fail.


Only the attribute name to look for is needed for configuration. By default it is set to secondFactorAcr. The authenticator to run is taken from this ACR value and matched against available authenticators in the profile.


Fig. 109 Configuration of the Attribute ACR Condition

Subject Condition

In the Subject Condition mode the username (subject) is matched against a set of regular expressions. Each condition has an associated authenticator that will run when the condition matches. Only the first matching condition will run, so order is important.

This can be useful when authenticating internal and external users with the same flow. External users could be configured with a different second factor than internal users.

Another use-case is when separating username and password in two different authenticators. Depending on the username the password may need to be validated against different backend. By matching on the username, we can call a second factor that verifies the password against the relevant source.


An ordered list of regular expressions and what authenticator to run when a match is found.


Fig. 110 Configuration of the Subject Condition