Enforce MFA for Internal Users but not for External Customers

Knowledge Solutions
, , ,
1

Problem statement

Is it possible to define a policy that issues an MFA challenge to internal corporate users but not to external customers?

Solution

Actions can be used to define a policy that will discriminate between two or more sets of users.

Let us start by looking at an example that shows how to enforce the use of MFA according to a specific condition:

/**
 * @param {Event} event - Details about the user and the context in which they are logging in.
 * @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
 */
exports.onExecutePostLogin = async (event, api) => {
  // Require MFA for anyone logging in from North America.
  if (event.request.geoip.continentCode === "NA") {
    api.multifactor.enable("any");
  };
};

In this particular example, the policy requires the use of MFA for anyone logging in from North America.
This example can be used as a starting point. The Action can be further customized to meet specific operating requirements.

The general approach would be to implement some type of filter condition within the Action code. If that condition is satisfied, then enforce ( or skip ) the requirement for MFA, using using the API object:

api.multifactor.enable(provider, options)

Here are some possible approaches that make use of the Post-login Event Object trigger. This object provides contextual information about a single user logging in via Auth0:

  1. If the customer accesses the tenant using a dedicated connection ( not shared with other users ), then use the ‘event.connection’ property to implement a filter

  2. If the customer has been assigned its own Organization, then use the ‘event.organization’ property

  3. Use of the ‘event.user’ property opens up several possibilities:

  • ‘app_metadata’ , ‘user_metadata’ : when a user is created, it is possible to insert a metadata item such as ‘require_mfa’ or ‘no_mfa’ into the user’s metadata
  • ‘multifactor’ : the list of multi-factor authentication (MFA) providers with which the user is enrolled. Be careful with this one: the list would be empty for external customers, as there is no requirement to use MFA. But then at a later date, requirements may change and it may be necessary to add another group of customers that should trigger an MFA challenge
  • ‘event.request’ : if the customer requests will originate from a single NAT IP address, this approach would work. But note that the 'event . request .``ip' does not reflect the 'auth0-forwarded-for' header, used as part of ROPG flows. As such, Actions do not currently get access to the actual client IP when a middleman like a proxy or a back-end server sends the request to Auth0.

These are not the only possible options. The Event Object documentation page describes other properties that are a good fit for a specific use case.

More complex requirements can be implemented through the use of multiple conditions that trigger an MFA challenge ( e.g. Organization AND IP address)

Related References

1 Like