Skip to content Skip to site navigation Skip to service navigation

How to Configure Multi-Factor and forceAuthn Applications

This feature is in effect as of March 30, 2018, when login and two-step authentication changed.

Introduction

Stanford's Identity Provider (IdP) provides the authentication service required to make Web Single Sign-On (SSO) at Stanford work. The Identity Provider implements multi-factor authentication (MFA) by requiring a first-factor (username/password or certificate) and then a second-factor (DUO MFA). There are several ways you, as a Service Provider maintainer, can affect this authentication process.

Different Authentication Experiences

The MFA Authentication Context can be used by Service Providers (SPs) to request that Identity Providers perform MFA in one of the ways described below, and by the Identity Provider to notify SPs that a particular MFA context was used.

In a SAML assertion, compliance is communicated by asserting the AuthnContextClassRef as follows (in order of increasing frequency of re-authentications):

Authentication Experience Authentication Context and Details
Depending on a user's Duo settings, users must Duo authenticate only if they have not authenticated in the last 24 hours or in the last 90 days. Context: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

This is the default context your SP will use if it does not explicitly set one of the others. This context will require a user to Duo authenticate every day unless the user has checked the "Remember me for 90 days" check box in the Duo client, in which case they will only need to authenticate if they have not authenticated in the last 90 days. See also the How to Log In Faster page.
Users must Duo authenticate unless they have already done a Duo authentication in the last 24 hours. Context: https://refeds.org/profile/mfa

This requires a Duo authentication once per day even if the user checked the "Remember me for 90 days" check box in the Duo client. Note that the user needs to do only one Duo authentication in a day to cover all sites using this Authentication Context.
Users must Duo authenticate regardless of previous Duo authentications. Context: https://saml.stanford.edu/profile/mfa/forced

The user will be asked to Duo authenticate at your site regardless of any other Duo authentications they may have done earlier that day at other sites, even Duo authentications at sites using this same Authentication Context.
Users must Duo authenticate and complete a first-factor re-authentication. Context: forceAuthn=true

This sets the ForceAuthn attribute in the SAML Authentication request to "true". The user will be prompted for first factor and second factor re-authentication (bypassing SSO). This context is meant to be used by itself: if you use forceAuthn=true do not use any of the other above authentication contexts.

Configure multi-factor authentication (Duo MFA) for a Shibboleth SP

You can configure two-factor authentication into your Shibboleth SP in various ways. Each way involves making changes to the shibboleth2.xml file used for SP configuration.

Examples

Example 1: Modify the default SSO element to apply to all applications/virtual hosts on this SP requiring MFA during the current IdP session.

<SSO entityID="https://app1.stanford.edu/"
    authnContextClassRef="https://refeds.org/profile/mfa">SAML2</SSO>

Example 2: Modify the Host element to require MFA for a specific virtual host during the current IdP session

This requires two-factor authentication for an SP with multiple virtual hosts on a host-by-host basis. The following example will require app1 to enforce MFA but not app2.

<Host name="app2.stanford.edu" />

<Host name="app1.stanford.edu"
     authnContextClassRef="https://refeds.org/profile/mfa"
     authType="shibboleth"
     requireSession="true" />

Example 3: Always require MFA(Duo) for this application 

This custom profile will require the users to immediately verify their second factor for the current application .  

<SSO entityID="https://app3.stanford.edu/" 
authnContextClassRef="https://saml.stanford.edu/profile/mfa/forced">SAML</SSO>

Configure Shibboleth SP to request forceAuthn (Forced Authentication)

For some applications with high security requirements it might be beneficial to break the Single Sign-On feature and require a re-authentication of the user. This can be achieved by using a SAML2 SessionInitiator with the content parameter forceAuthn. The users will need to go through both first factor and second factor authentication.

This SAML2 SessionInitiator parameter will force the user to authenticate at the Identity Provider, even if he or she still has a valid Single Sign-On session. In combination with a Service Provider's logout handler, this feature is especially useful for applications often used at public terminals/kiosks. It allows logged-in users to log out from a web application (but please also read How to Log Out From a SAML Application).

Warning: Do NOT specify forceAuthn=true and override the AuthnContext at the same time. It is not supported.

 

Example

Example 1: Require ForceAuthn via  <SSO> elements

To use the forceAuthn parameter, replace the simplified <SSO> elements in shibboleth2.xml with:

<Sessions lifetime="600" timeout="300" maxTimeSinceAuthn="5"
         relayState="ss:mem" checkAddress="false"
         handlerSSL="true" cookieProps="https">

 <SSO entityID="https://example1.stanford.edu/"
      forceAuthn="true">SAML2</SSO>

   <!-- other settings ... -->
</Sessions>

The "maxTimeSinceAuthn" checks that the authentication (username/password, or certificate, or something else) happened within the last x seconds (the example here set it to 5 seconds), and the "forceAuthn" attribute is set to true so the login server knows to ignore the user's request to perform SSO logins.

Last modified January 7, 2019