This document is for U-M information technology staff members. It details how to configure Shibboleth-enabled services to use two-factor authentication.
About Two-Factor Authentication and Shibboleth
Two-factor authentication requires a user to log in with a username, password and a second factor, such as a Duo two-factor option. You can configure your U-M Shibboleth Service Provider (SP) to use two-factor authentication to provide greater security for your service. Your service must be using SAML2 to take advantage of two-factor authentication.
Note: If your SP allows individuals from other InCommon institutions to log in, for example using a discovery service, the Shibboleth Identity Providers (IdPs) used by these institutions may not support two-factor authentication configured in this way. Due to this issue, the associated individuals may not be able to log in to your SP.
You can integrate two-factor authentication into your Shibboleth SP in many ways. Each way involves making changes to the shibboleth2.xml file used for SP configuration.
- Modify the default SSO element This will ensure that all virtual hosts on an SP require two-factor authentication.
- Modify the Host element This will require two-factor authentication for an SP with multiple virtual hosts on a host-by-host basis.
- Add a new attribute to the SessionInitiator element This requires two-factor authentication at the IdP session level. Use this option if you have highly specific requirements for your Shibboleth sessions other than the default.
If your SP is configured to support multiple virtual hosts (for example, sample1.umich.edu but also sample2.umich.edu), modifying the SSO element will require two-factor authentication on all virtual hosts.
Modify the default SSO element:
<SSO entityID="https://shibboleth.umich.edu/idp/shibboleth" authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken">
If two-factor authentication will protect your entire SP, ensure that your SP is configured to require a Shibboleth session.
For Windows SPs, update the RequestMapper element in the shibboleth2.xml file.
For Linux SPs, use httpd.conf in Apache.
If your SP is configured to support multiple virtual hosts, but only some of those hosts will require two-factor authentication, modify the Host element, rather than the SSO element to configure two-factor authentication on a host-by-host basis. This example requires sample.umich.edu to use two-factor authentication, but not example.umich.edu.
Modify the Host element for each host that will use two-factor authentication:
<Host name=”example.umich.edu” />
<Host name =”sample.umich.edu” authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken" authType=”shibboleth” requireSession=”true” />
This modification also configures your SP to require a Shibboleth session for each host.
Require two-factor authentication at the IdP session level by adding an attribute to the appropriate SessionInitiator element:
<!-- Token auth at U-M-->
<SessionInitiator type="Chaining" Location="/SecureLogin" isDefault="false" id="duo" relayState="cookie" entityID="https://shibboleth.umich.edu/idp/shibboleth" authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken" >
<SessionInitiator type="SAML2" template="bindingTemplate.html"/>
After authentication, your application's session environment will include specific attributes indicating the authentication method actually used by the IdP. This information, including any attributes that are pushed to the SP, will be contained in the session environment for the duration of a user’s session.