Shibboleth at NC State » Technical Documentation » Multi-Factor Access

Multi-Factor Access

Our NCSU Identity Provider (shib.ncsu.edu) can be asked to require a multi-factor login for any user trying to authenticate to a Service Provider. This is implemented following the guidelines provided for REFEDS MFA.

When a user attempts to login to a site that requires MFA, the IdP will ask for the user's password to login for the first factor. It will also ask for the user to sign in to Duo for the second factor. If the user does not have an active Duo profile, they will blocked from accessing the service provider.

If the Duo service is temporarily unavailable at the time of login, sites that requires MFA will not be accessible. The assertion that an MFA login was used cannot be issued when that is not the case.

Why require MFA?

When you require an MFA login for your website or application, you add an extra layer of protection against abuse by stolen accounts. Users are frequently tricked into giving away their passwords at Phishing websites. It is much harder for an attacker to steal both the password and access to the second factor.

Note that by current policy, all NCSU employees must enroll in Duo. NCSU students may enroll in Duo but they are not required to do so at this time. Any user who enrolls in Duo will be required to perform a mutli- factor login when using Shibboleth from then on, regardless of whether or not the SP asks for MFA. If you have an application that is heavily used by students, keep this in mind when deciding whether or not you need to require MFA logins.

Asking for MFA in .htaccess

The simplest way to configure your website or application to require MFA is to add the configuration to your .htaccess rules. These rules can also be used in Apache config files like a vhost definition block. The rules to require MFA for login are:

AuthType shibboleth
ShibRequestSetting requireSession true
ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa
Require authnContextClassRef https://refeds.org/profile/mfa

Both of the last two lines are needed to enforce the MFA requirement. The first line tells the IdP that your SP wants to require MFA login by the user. The second line tells the webserver that if the user logged in but did not use MFA somehow, they should not be allowed to access the site.

If you want to combine these rules with other login requirements, you need to use an httpd 2.4 RequireAll block. For example, this rule set will ensure that only staff can login, and only if they used their MFA during the login.

AuthType shibboleth
ShibRequestSetting requireSession true
ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa
<RequireAll>
  Require authnContextClassRef https://refeds.org/profile/mfa
  Require shib-attr SHIB_AFFILIATION staff@ncsu.edu
</RequireAll>

Using MFA with Lazy Sessions

You may choose to use Lazy Sessions to enable Shibboleth access while not requiring it to force a login to establish a session. In that case, you should have some sort of code checking the attributes that are returned before creating a session. You will need to make a few adjustments to your configuration to support MFA logins.

Your .htaccess entry does not change. It is still something like:

AuthType shibboleth
ShibRequestSetting requireSession false
require shibboleth

When you create a login link for your application, you may need to add the authnContextClassRef parameter to the URL. That will request the login server enforce the requirement for an MFA login.

Once the user has logged in and returned to your application, you need to check the context that was used to verify that MFA was indeed called. The Shibboleth SP should pass the authentication context as the environment variable Shib-AuthnContext-Class. The two contexts that we use are:

# MFA was used - this is what you want
[Shib-AuthnContext-Class] => https://refeds.org/profile/mfa

# Password login without MFA - you should not allow this session
[Shib-AuthnContext-Class] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

If a user tries to start a session with any context different from the MFA one listed, you should either redirect them to the login URL with the MFA context as suggested above, or give them a page letting them know that MFA is required to use your application.

TODO LIST

This document is not complete. Some ideas for more topics...