LMS Multi Factor Authentication

Overview

Multi-Factor Authentication (MFA) adds extra checks to the LP LMS login so that a username and password alone are not enough to get in. Each check is called a factor. Some factors ask the user to do something, such as enter a code from an authenticator app on their phone. Others run automatically in the background, such as checking whether the user for what role they hold.

Because the factors can be combined, MFA can be applied where it matters most. For example, you can require site managers to use an authenticator app while learners continue to log in as they do today.

Why use MFA?

• Reduce the risk of compromised accounts. A stolen or guessed password is not enough to log in when a second factor is required.
• Protect high-privilege users. Accounts that can change site settings, see learner data or manage users can be held to a higher standard than everyday learners.
• Roll out at your own pace. MFA can be introduced in stages, so users have time to set up their factors before anything is enforced.

How to get MFA set up

MFA is configured for you by the Learning Pool implementation team. This keeps the setup safe: a wrongly configured MFA plugin can stop users, including site managers, from logging in, so it is set up and tested by people who do this regularly.

1. Contact your Account Manager. Let them know you would like MFA enabled on your LP LMS site.
2. Your Account Manager raises a request. They will raise an SPOE with the implementation team on your behalf.
3. The implementation team contacts you. They will arrange a conversation to understand who needs MFA, which factors suit your users and how you would like to roll it out.
4. The plugin is configured and tested. The implementation team sets up MFA to match your requirements and tests it before it affects your users.

How MFA works

MFA uses a points system. Each factor is worth a number of points, and a user needs 100 points to log in. The implementation team decides how many points each factor is worth, based on your requirements.

• Automatic factors are checked first and need nothing from the user, for example a role check.
• Input factors are checked next and ask the user to do something, for example enter a code from an authenticator app.
• If the user reaches 100 points, they are logged in. If they cannot reach 100 points, they are not.

This is what makes MFA flexible. A learner might reach 100 points from automatic factors alone and never see an extra step, while a site manager only reaches 100 points after entering a code from their authenticator app.

Available factors

The table below summarises the factors available on LP LMS. Each one is described in more detail after the table, with examples of where it is useful.

Authenticator App

Users enter a six-digit code from an authenticator app on their phone. The code changes every 30 seconds. This uses the open Time-based One-Time Password (TOTP) standard, so it works with Google Authenticator, Microsoft Authenticator, Authy, Duo and any other app that supports the standard. This is the strongest factor available and the one most organisations use as their main second factor.

Example: A training provider requires every site administrator to enter a code from Microsoft Authenticator each time they log in.

Role

Checks whether a user holds any of the roles you choose. Users without those roles get the points for this factor and continue as normal. Users with those roles do not, so they must complete another factor such as the Authenticator App. This is usually used for high-privilege roles such as Site Manager.

Example: An organisation wants only Site Managers to use MFA. Learners log in as they do today, while Site Managers must also enter a code from their authenticator app.

Non-administrator

Gives the points for this factor to any user who is not a site administrator. Administrators do not receive the points, so they must complete another factor. It is a simple way to require MFA for administrators only, without affecting anyone else.

Example: A small organisation with three site administrators wants those three accounts protected, with no change for its 2,000 learners.

Authentication Type

Gives the points to users who log in with a chosen authentication method. Some login methods, such as single sign-on (SSO)  already include their own MFA check. This factor means those users are not asked to complete MFA twice.

Example: Employees log in through the company's Oauth2 SSO, which already enforces MFA, so they go straight in. External contractors who log in with a username and password must use an authenticator app.

User Capability

Works in a similar way to the Role factor, but is based on a specific permission rather than a role name. Any role given this permission will not receive the points, so users with that role must complete another factor. This suits sites with many custom roles, where it is easier to mark the roles that need MFA than to list them all.

Example: A site has several custom manager and reporting roles. Each of these roles is given the MFA permission, so all of them must use an authenticator app.

Cohort

Applies MFA to members of the cohorts you choose. A cohort is a group of users defined at system or course category level. Users in the chosen cohort must complete another factor to log in.

Example: A healthcare organisation wants staff who can access sensitive compliance records to use MFA. These users are already in a "Clinical Leads" cohort, so MFA is applied to that cohort only.

Email

Sends a short-lived code to the user's email address, which they enter to log in. This is quick to adopt because users need nothing new. It offers less protection than an authenticator app, because a user's email password is often the same as, or linked to, their LP LMS password.

Example: Seasonal staff who do not have company phones are sent an email code as their second factor.

Grace Period

Lets users log in without completing MFA for a set period, such as seven days, so they have time to set up a factor. 

Example: MFA goes live on the 1st of the month with a 14-day grace period. Users who have not set up an authenticator app by the 15th are then required to do so before they can log in.

IP Range

Gives the points to users logging in from a trusted network, such as your office or VPN. Users on that network do not need to do anything extra. Away from the trusted network, they must complete another factor.

Example: Staff working in the office log in as normal. When they work from home, they are asked for a code from their authenticator app.

Login Banner

Shows a policy or notice that users must read and accept each time they log in. Unlike the standard site policy, which is accepted once, this appears on every login. It is usually added alongside other factors rather than counting towards the 100 points.

Example: A public sector customer must show an acceptable use notice on every login. Users accept it before reaching their dashboard.

No Other Factors

Lets users log in as normal until they have set up another factor, such as the Authenticator App. Once they have, they must use it every time. This is the safest way to introduce MFA, because no one is locked out while they are getting set up.

Example: An organisation encourages all users to set up an authenticator app over a month. Users who have set one up must use it from then on, and anyone who has not yet done so can still log in.

Trust This Device

After a user completes MFA, they can mark the device they are using as trusted. They will not be asked for MFA again on that device for a set period. This reduces repeat prompts for users who log in from the same computer every day.

Example: A manager who logs in several times a day from their work laptop completes MFA once, then is not asked again on that laptop for 30 days.

Example setups

Factors are usually combined. These examples show common approaches. The implementation team will recommend the right combination for your site.

Setting up an authenticator app

Once MFA is live, each user sets up their own authenticator app. You may want to share these steps with your users.

1. Install an authenticator app on your phone, such as Google Authenticator or Microsoft Authenticator.
2. Log in to LP LMS, click your profile and select Multi-Factor Authentication Preferences.
3. On the Available Factors page, click Setup App.
4. Enter a Device Label, usually the name of your phone, so you can recognise it later.
5. Open your authenticator app and scan the QR code shown on screen. In Google Authenticator, tap the + button in the bottom right corner to scan.
6. Enter the six-digit code shown in your app into the Verification code box and confirm.

From then on, when you log in you will be asked for the current code from your app.

Next steps

To get MFA set up on your LP LMS site, contact your Account Manager. They will raise an SPOE with the implementation team, who will be in touch to discuss your requirements.