Skip to main content

Search

#happiness exists

Open LMS | Enabling multi-factor authentication (MFA)

In OpenLMS, we can easily enable multi-factor authentication. This authentication is a security measure that requires users to verify their identity using two or more factors (password, fingerprint, another device)

To enable MFA, go to Site administration > Plugins > Admin tools > Multi-factor authentication > Manage multi-factor authentication (MFA). A table will be displayed with each of the factors that we can enable, a switch to enable them, a weight, and their configuration.

Moodle has a series of recommendations and example configurations on this page that can help you decide how to do this.

First, below the table you will find a checkbox to enable this plugin.

Also choose the lockout threshold (the number of times a user can try to log in with MFA before the account is locked), and add the URLs that do not redirect to MFA. This can be useful if you want users connecting from the institution's building not to have to use MFA, while those connecting remotely do have to use it.

You can also add help information for users.

Managing authentication factors

Let's return to the table. Do you see the weight of each factor? This weight controls how many factors users must pass when logging in.

All users will need to have 100 points by adding up the factors they use.

If you set two factors, both with 100, the user will need to pass one or the other. If the factors have 50 points each, the user will need to pass both.

In the table, you will see that there are factors where the user does not have to use anything, such as being within an IP range or the authentication type. These are handled first, during the login process. The other factors are then evaluated one by one, in order of weight, until the user reaches the required 100 points (or all factors fail and access is denied).

Choosing authentication factors

There are multiple factors that we can choose from. Here we list the most common ones:

  • Email. This factor asks the user to copy a temporary code received by email during login. This code is generated automatically during the login process, sent to the email address registered in the profile of the user accessing the system, and is valid for a configurable amount of time.
  • Authentication app.  This factor requires the user to install an authentication app on a mobile device and configure it to use this factor. The app will generate a temporary code for the user. This code must be entered in Open at the time of login.
  • IP range. This factor checks the IP address from which the user is connecting to verify the identity of the user logging in. It requires no configuration other than adding the range in the configuration field. The user will not need to do anything. If the IP address is contained within the range, the login and password combination will be sufficient to access the system. If it is outside the range, another factor will be requested.
  • SMS delivery. This option requires a code to be received via SMS messaging on the user's phone during the login process. This code must be entered together with the password to authenticate.

You can also configure factors that control or filter who must log in with MFA, such as:

  • Non-administrators.  This factor requires only administrators to have MFA enabled, while the rest of the users do not need it. It simply awards the points associated with this factor to all users who are not administrators.
  • Authentication type. This factor is useful for requiring two-factor authentication only for users who use a certain type of authentication. For example, if one group of users uses internal logins while the rest uses a login via SAML, we could enforce MFA only for those using the internal logins (since SAML also provides this functionality).
  • Role. Allows only users with certain roles to access the system with two-factor authentication, without affecting the rest.
  • Cohort. As with the others, this allows us to select cohorts for which MFA use is enforced.

Other factors provide additional flexibility, for example, by giving users the opportunity to mark a device as trusted during authentication. This means that MFA will not be requested for a specific period of time.

Examples

Email verification:

  • Enable MFA
  • Enable the email factor with 100 points
  • Enable trusted device to allow the device to be saved for a certain period of time.
  • Inform users.

Email or authentication app verification:

  • Enable MFA
  • Enable the email factor with 100 points
  • Enable grace period with 100 points as well. This allows users time to configure the app. Use the banner in this way to remind users that MFA will soon be mandatory
  • Enable authentication app with 100 points
  • Enable trusted device 
  • Inform users

If, instead of offering email or an app, we want both to be used together, we will assign 50 points to email and authentication app instead of 100.

Recommendations

To create a good user experience, we recommend enabling the grace period if any of the factors you have configured require configuration by users, such as an authentication app. This will give them time to configure everything before MFA becomes mandatory.

If MFA is optional, enable No other factors. Users who do not have any other factors can access the system using only their password.

Use IP ranges if your users mostly access the system from the same network, enforcing MFA only when they access it from a different network (at home, while traveling)

Comments

0 comments

Please sign in to leave a comment.