Passwords are not enough. Add extra layers of security with two-step login.
Two-step login - also called two-factor authentication (2FA) or multi-factor authentication (MFA) - is a method of confirming a user's claimed identity in which she is granted access to a service only after successfully presenting two or more pieces of evidence (or factors) for authentication. 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".
The user experience
Setting up two-step login
Two-step login is always set up by the user for her own account.
A user must first initialize two-step login before it can be used. An edu-ID end-user 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.
Using two-step login
If two-step login was enabled by a user she 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:
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 she was asked to store safely when two-step login was initialized.
When a service requests 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 information for users is available on the two-step login FAQ edu-ID page.
User hasn't configured two step login but SP requires it!
In the case user has not configured two-step login, but the SP requires it the following happens:
- User opens SP web site
- User klicks edu-ID login button
- User is redirected to edu-ID login window
- User authenticates with username and password
- after sucessful authentication with the first factor a message is displayed that the user has to set up two-step login to use the service (see screenshot below)
- If the user klicks Continue, she is redirected to the two-step setup window in my edu-ID.
- The user sets up two-step login
- After sucessful configuration of one two-step login method the user is redirected back to the initial login window
- The user enters the two-step login code (TOTP or mTAN)
- The user is authenticated and redirected to the SP
Two-step login activation
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. SP administrators are invited to read the chapter about configuring an SP below to learn how this 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.
For OIDC Relying Parties, the setup of requiring two-step login is very simple as just the authorization URI has to be adjusted. The configuration therefore is documented in OpenID Connect - Development and Testing.
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:
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 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" 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.
By specifically triggering it via URL:
An application can also request two-step login when it is required for a specific user. 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:
- By adding an additional '
target' GET parameter to the above URL, a URL can be specified to which the user should return after authentication.
- The example link above shows a request to the edu-ID IdP (entityID=https://eduid.ch/idp/shibboleth). For classic SPs, the entityID as to be adapted to the IdP where the user was authenticated.
With other SAML service providers
SAML Service Providers other than Shibboleth can request two-step login by sending an authentication request that requests the SAML authenticationContextClass 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>
When the user returns authenticated, the application code must always 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 with two-step login was successfully enforced. Otherwise, users who authenticated with username/password only can access the application that would consider them as MFA authenticated. This could happen by misconfiguration of the Service Provider or the web application.
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 trigger two-step login by clicking on "Request Login with MFA" after you logged in with username/password only, or by using 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 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>