Configuring Your Service Provider for Two-Factor Authentication

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.

1. Configure Two-Factor

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.

1. Modify the default SSO element This will ensure that all virtual hosts on an SP require two-factor authentication.

2. Modify the Host element This will require two-factor authentication for an SP with multiple virtual hosts on a host-by-host basis.

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

Modify Default SSO Element

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">
   SAML2 SAML1
</SSO>

If two-factor authentication will protect your entire SP, ensure that your SP is configured to require a Shibboleth session.

Modify Host Element

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.

Add an Attribute to the SessionInitiator Element

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"/>
</SessionInitiator>

2. Verify Two-Factor Configuration

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.

On Apache:

On IIS: