Multi-Factor Authentication / Two-Step Login

Overview 

Multi-factor authentication is a method of confirming a user's claimed identity in which he is granted access to a service only after successfully presenting two or more pieces of evidence (or factors) to an authentication system. The factors can be:

  • Knowledge: Something the user and only the user knows
  • Possession Something the user and only the user has
  • Location: somewhere the user is

In accordance with other identity providers like Google SWITCH uses the term two-step login in all communication with end users on web pages and in eMails. The term two-step login is believed to be more intutitive, more friendly and less technoid that multi-factor authentication.

Currently supported methods

The following methods are currently supported as second factor:

  • Sending one-time password via SMS
  • Time-based one time passwords - TOTP*

As backup or recovery methods edu-ID supports

  • One-time recovery codes

With SWITCH edu-ID it is planned to support more MFA methods/protocols like FIDO in the future.

*) In order to use the TOTP method, a user has to install a TOTP app on the mobile phone. TOTP is a generic, non-proprietary protocol which is supported by numerous apps on all smartphone platforms. One well known app is the "Google Authenticator".

edu-ID two-step login: the user experience

For edu-ID end-users the multi-factor authentication (MFA) feature is called "Two-Step Login". A user must first initialize it before he can use it. An edu-ID end-users can enable it on the My edu-ID page in the section 'Enhanced Security Settings'. SWITCH edu-ID will guide users through the process of setting up and performing all required Two-Step Login procedures with their mobile phone.

If Two-Step Login was enabled by a user he first authenticates with username and password when accessing a service. If the service requires it, the user is asked in a second step to provide a one-time code as a second factor:

Two-Step-Login-Entering-Code

The one-time code is either sent to the user's mobile phone as an SMS text message or it is a time-based one-time password (TOTP) that is generated by an app, which typically runs on the user's mobile phone. Alternatively, the user can also enter one of several one-time recovery codes that he was asked to store safely when Two-Step Login was initialized.

When services request Two-Step Login, SWITCH edu-ID will enforce the following: users are required to authenticate as normal with username and password, but will then be prompted to enter an additional code (i.e. SMS or TOTP one-time token). This second step may not be required, if Two-Step Login was performed by the same user not more than 7 days ago on the same web browser.

More details on the Two-Step Login are also available on the Two-Step Login FAQ edu-ID page.

Requiring two-step login

When will a user be required to login with a second factor?

Case 1 - SP requires two-step login

In this case, an SP enforces strong authentication for all users who get access. A user who has not configured two-step login will be asked to do so in order to be able to access to the service. Read the chapter configuring an SP below to learn how it is done.

Case 2 - The user protects his/her account with two-step login:

In the my edu-ID service a user has the possibility to require two-step login for all access to all SPs. Hereby the personal account is effectively protected against phishing attacks.

 

In all cases: when entering the code in the login process a user has the option to save the MFA session for a certain time period (Checkbox: Don't ask again for one week). The user will then not be asked to enter a MFA code for a week if he/she uses the same browser.

Configuring an SP for two-step login

To request Two-step Login for users, a SAML Service Provider needs to request the SAML2 Authentication Context class https://refeds.org/profile/mfa, which is a standard profile used in academic identity federations around the world. This profile specifies the requirements that the multi-factor authentication mechanism has to meet.

In case a SAML Identity Provider does not support this profile, it will display an error message to the end-user. In case of the edu-ID Identity Provider, Two-Step Login is supported but an edu-ID user might not have activated it yet. In the latter case, the user is instructed (after username/password authentication) how to enable Two-Step Login and how to continue to access the service. Therefore, all that a service administrator has to do is to request MFA authentication. However, consider that you might shy away users if you enforce Two-Step Login.

Request two-step login with a SWITCHaai Shibboleth service provider 

The Shibboleth Service Provider is the most frequently used SAML implementation in SWITCHaai and worldwide in academic identity federations. Requesting multi-factor authentication can be achieved via the following options:

By configuration:

The Shibboleth Service Provider can automatically enforce that users must successfully be MFA-authenticated to access certain directories or files. This can either be achieved via an Apache config or .htacess directive (more examples here) like the following one that requires the edu-ID user to perform the Two-Step Login/MFA and to be a staff member:

<Directory /var/www/mfa-secured>
  AuthType shibboleth
  ShibRequestSetting requireSession true
  ShibRequestSetting entityID https://eduid.ch/idp/shibboleth
ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa <RequireAll> Require shib-attr affiliation staff Require authnContextClassRef https://refeds.org/profile/mfa </RequireAll> </Directory>

or for non-Apache web servers within the Shibboleth SP itself via an XML Access Control rule in the RequestMap element like in this example:

<RequestMap applicationId="default">
    <Host name="example.org">
        <Path 
          name="mfa-secured" 
          authType="shibboleth"
          requireSession="true"
          entityID="https://eduid.ch/idp/shibboleth"
          authnContextClassRef="https://refeds.org/profile/mfa">
            <AccessControl>
                <AND>
                    <Rule require="affiliation">staff</Rule>
                    <Rule require="authnContextClassRef">https://refeds.org/profile/mfa</Rule>
                </AND>
            </AccessControl>
        </Path>
    </Host>
</RequestMap> 

In both above cases, the Shibboleth Service Provider will ensure that users can access the protected content only if they successfully could be authenticated with Two-Step Login.

On demand via URL:

An application can also request Two-Step Login on demand. It just needs to send the user to a Shibboleth SessionInitiator (default is /Shibboleth.sso/Login) with the GET request parameter 'authnContextClassRef' and the value 'https://refeds.org/profile/mfa'. In case of an edu-ID user, Two-Step Login would be enforced by sending the user to the following relative URL on a host example.org with a Shibboleth Service Provider installed:

https://example.org/Shibboleth.sso/Login?entityID=https%3A%2F%2Feduid.ch%2Fidp%2Fshibboleth&authnContextClassRef=https%3A%2F%2Frefeds.org%2Fprofile%2Fmfa

By adding an additional 'target' GET parameter to the above URL, a URL can be specified to which the user should return after authentication.

When the user returns authenticated, the application code must check that the web server environment variable 'Shib-AuthnContext-Class' contains the value 'https://refeds.org/profile/mfa'. Only then, this on-demand method ensures that multi-factor authentication was successfully enforced.

With other SAML service providers

Other SAML Service Providers can request that the user uses Two-Step Login by sending an authentication request that requests the SAML authententicationContextClass https://refeds.org/profile/mfa.

A SAML authentication request then would look like this:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    [...]
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    Version="2.0">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">#SP EntityID#</saml:Issuer>
  <samlp:NameIDPolicy AllowCreate="1" />
  <samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://refeds.org/profile/mfa</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Example services

An example service that requests Two-Step Login (for users that enabled it) is the My edu-ID profile management web site. Also, the AAI Attribute Viewer can request Two-Step login on demand (click on "Request Login with MFA" after you logged in with username/password only) or use this enforcing link.

MFA with three factors

If the (network) location of a user is also considered as a factor, it is very easy to enforce a three-factor authentication also requiring the user to be in a particular network on top of the Two-Step Login.

Sample access control rule for Apache:

<Directory /opt/www/administrator>
  AuthType shibboleth
  ShibRequestSetting requireSession true
  ShibRequestSetting entityID https://eduid.ch/idp/shibboleth
  ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa

  <RequireAll>
   # Require first factor: username and password
   Require valid-user

   # Require second factor: one-time code
   Require authnContextClassRef https://refeds.org/profile/mfa

   # Require third factor: be within own network
   <RequireAny>
     Require ip 203.0.113.0/24
     Require ip 202::/16
   </RequireAny>

  </RequireAll>
</Directory>