MFA enforcement

Sign in via ProxyIdP can be additionally secured by enforcing the use of Multi-factor authentication (MFA). The exact forms of MFA supported by ProxyIdP as well as the role of ProxyIdP in this process are described in more detail on the Multi-factor authentication page in the developer section. This page is concerned with various forms of MFA enforcement supported by ProxyIdP and how to set them up.

The process of MFA enforcement is implemented in accordance with REFEDS MFA profile. In this context, ProxyIdP is an Identity Provider (IdP) which performs the MFA and returns the result - a message communicating success or failure of MFA as a response to the authentication request sent by the Service Provider (SP).

Enforcing MFA can be achieved in several ways:

1. Enforce MFA for each user and service

The most basic case where MFA is performed when any given user wants to access a resource or a service provided by the SP. The authentication flow can be undertaken in multiple ways, most commonly using SAML or OIDC messages. Initially, the service provider sends an authentication request to the IdP containing an Authentication Context Class Reference demanding the use of REFEDS MFA profile.

Using SAML, this can be accomplished by setting the <AuthnContextClassRef> (ACR) tag to the REFEDS MFA profile url:

<samlp:RequestedAuthnContext Comparison="exact">
  <saml:AuthnContextClassRef>https://refeds.org/profile/mfa</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

Using OIDC, the authentication request needs to be dispatched with value of the optional attribute acr_values set to https://refeds.org/profile/mfa:

GET /authorize?
    response_type=id_token
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &acr_values=https://refeds.org/profile/mfa

ProxyIdP adheres to the REFEDS MFA profile and recognizes these requests as prompts to trigger MFA.
IdP attempts to perform MFA and returns the result in a corresponding manner.

In case MFA was initated using SAML the IdP sends back a SAML <Response> containing a <Status> set to Success if user was successfuly authenticated:

<samlp:Status>
  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>

If MFA wasn’t successfully performed, the resulting <Response> from the IdP will contain a <StatusCode> NoAuthnContext:

In case MFA was initated using OIDC the IdP returns an ID Token containing an acr claim with the Authentication Context Class the user has satisfied by the authentiaction. The OIDC documentation also includes examples of requesting and receiving the ID Token. Apart from the returned ID Token, the authentication response can also be obtained from the introspection endpoint of ProxyIdP in accordance with OAuth 2.0 Step Up Authentication Challenge Protocol. Authentication response queried from the introspection endpoint also includes the acr claim as well as auth_time claim specifying when the authentication took place.

In case MFA can not be performed yet because the user doesn’t have any valid tokens (second factor) to authenticate with, user will be redirected to a token registration page and the error response will not be returned. Error response returns, for example, when the authentication request contains an unknown Authentication Context.

These steps are can be used with any SP. We provide general guides for setting up Shibboleth SP3 and SimpleSAMLphp service providers. Configuration of each individual SP’s ACR tags in SAML approach may differ slightly. For example, Shibboleth SP3 covers these specifics in their documentation. SimpleSAMLphp also provides documentation for configuring authentication using SAML2 tags in their SP. Possible questions about details of MFA profile may be answered on REFEDS MFA profile FAQ page. Especially relevant portion might be the SP operator page of the FAQ.

2. Enforce MFA for specific services (step up)

Step up authentication might be used in cases when stronger but less user-friendly multi-factor authentication is not needed right away. User can log in to the application using a single factor and be allowed to carry out less sensitive tasks. In this case, the SP should send out a regular authentication request to the IdP without enforcing the use of MFA.

In case the user needs to perform a more sensitive operation, the SP can trigger another authentication request, this time using the REFEDS MFA profile described in the first section, thus enforcing the use of MFA. ProxyIdP will perform authentication only using the second factor since the user has already been authenticated by the first factor. These two different authentications with separate factors together constitute MFA as complete. If the request is successful, the SP can elevate user’s privileges.

If users don’t have any MFA tokens, they will be redirected to a token registration page without an error response.

3. Enforce MFA for specific users (step up)

Using just REFEDS MFA profile described in the first section will cause MFA to be enforced for each individual user. Specifying more granular enforcement rules for users can be achieved by using the step up approach described in the second section.

The basic idea behind the step up approach described in the second section was to trigger MFA for anyone when specific services were being accessed. However, this same principle can be used when a specific user is trying to access any service.

Allowing the user to log in using only a single factor and immediately enforcing a step up will effectively result in a regular MFA flow from the point of view of the user. User will be prompted to log in using their credentials and their second factor exactly once. Therefore, selective enforcement of the step up authentication for some users can be used for specifying the scope of MFA.

# TODO - move to technical docs or remove
Authswitcher module for simpleSAMLphp service provider.

Users in Perun contain an attribute rpCategory which defines a service category they belong to. MFA can be enforced for selected service categories in Authswitcher configuration. This effectively allows enforcement MFA to be limited to single individuals as well as subsets of users belonging to certain categories.

More details about all the possible customizations of MFA enfocement can be found in the Authswitcher README.

4. Enforce MFA for specific users of a service (Perun attribute)

Some service providers are not able to perform step up authentication but still wish to have more control over the access to their resources. This can be achieved using attributes in Perun.

Resources in Perun contain an attribute proxyMFAEnforced. Setting this attribute’s value to True triggers automatic enforcement of MFA for any users belonging to a Group assigned to this Resource trying to sign in to the service provider represented by a Facility. More information about setting up this attribute and its effects can be found in the attribute setup guide.

5. User-enforced MFA

MFA doesn’t necessarily need to be enforced only by the service provider. Users have a level of individual control if they want to increase their security. Using Perun’s User profile page, users can choose additional protection by enforcing MFA use on all of the services, selected categories of services or even individual services. This way, users can opt in to secure their accounts even if it’s not required by the service provider.