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 use Cardinal Key as first-actor to authenticate | Context: urn:oasis:names:tc:SAML:2.0:ac:classes:X509 - or - Context: urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient - or - Context: https://saml.stanford.edu/profile/cardinalkey The user is required to authenticate with a valid Cardinal Key to access the site. |
| 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). |
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).
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.
