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:
|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.|
|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.
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.
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.
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.