Skip to content Skip to site navigation Skip to service navigation

How to Support Multi-Factor and forceAuthn Applications

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

Configure Shibboleth SP to request multi-factor authentication (Duo MFA)

Stanford University uses Duo MFA to implement multi-factor authentication (MFA), and Stanford Identity Provider (IdP) supports multi-factor authentication in a federated context such as REFEDS MFA Profile. Additionally, a customized forced second factor profile is also provided to satisfy applications that require in-place MFA verification. Finally, forceAuthn (forced Authentication) that requires immediate first factor and second factor verification is also supported.

The MFA Authentication Context can be used by Service Providers (SPs) to request that Identity Providers perform MFA as defined below, and by IdPs to notify SPs that MFA was used.

In a SAML assertion, compliance is communicated by asserting the AuthnContextClassRef as follows:

Authentication Context Details
https://refeds.org/profile/mfa This profile will ensure the users have a valid MFA during the current IdP session.
urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken  TimeSyncToken is deprecated and listed here for backward compatibility. It will be removed in the future. This legacy profile will ensure the users have a valid MFA during the current IdP session.

https://saml.stanford.edu/profile/mfa/forced
This custom profile will require the users to verify their second factor for the current application immediately.
forceAuthn=true This will enable ForceAuthn attribute to be true for the <samlp:AuthnRequest>. This will prompt the users 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. 
Note: TimeSyncToken is deprecated and listed here for backward compatibility. It will be removed in the future.

 

You can integrate 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 which will apply to all applications/virtual hosts on this SP to require MFA during the 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 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.

Warning: Do NOT specify forceAuthn=true and override 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 May 1, 2018