Now that you know everything about users and the information that is stored about them, let's look at how to authenticate them with Moodle. So far, we have only dealt with manual accounts, which are activated by default after the installation of Moodle.
Moodle supports a significant number of authentication types. Furthermore, Moodle supports multi-authentication, that is, concurrent authentication from different authentication sources. For example, your organization might use an LDAP server containing user information for all your full-time students and staff, but it wishes to manage part-time users manually.
Remember the basic authentication workflow we looked at in Chapter 3, Courses, Users, and Roles. Now, we can have a look at a more complete picture, as shown in the following diagram:
Let's start at the top where the user enters their user credentials, that is, username and password. Bear in mind that this could take place automatically, for example, in a single sign-on setup. Moodle checks whether a profile exists for the user. If it does and the account is authenticated via an internal mechanism, Moodle only has to check whether the password is valid.
If it doesn't exist, which is the case the first time a user attempts to log in, Moodle checks for any enabled and configured external authentication mechanisms. If there is a valid entry, an account will be created, and any existing data for which a mapping exists will be copied to the local user profile and access will be granted.
Once the profile exists and authentication is external, Moodle checks whether the credentials are valid for the set authentication method. If this is the case, any modified data in the source will be updated and access will be granted.
To access all the authentication plugins, go to Plugins | Authentication | Manage authentication. You will see a list of Available authentication plugins. Each plugin can be activated by clicking on the closed eye icon. If you click on the open eye icon, it will be deactivated again. The settings for each type, which are discussed in this section, are accessed by their respective links or directly through the Site administration block once the settings are active.
You can also change the order in which Moodle attempts to authenticate users via the up and down arrows. The order in which authentication plugins are applied will have an impact on how long it takes for users to login, so make sure that the main ones are at the top. The Users column gives you an indication about the number of users for each authentication mechanism. Alternatively, you can arrange them in order of fail through if any of your authentication mechanisms might be disconnected, which would prevent other users from logging in, too.
Additional authentication methods are supported by external plugins on https://moodle.org/, for example, OAuth and SAML. Once installed (refer to Installing third-party add-ons section in Chapter 8, Moodle Plugins), they will appear in the list alongside all the core mechanisms. It is not recommended that you remove plugins via the provided Uninstall option—delete them at system level instead.
First of all, let's have a look at the common authentication settings, which you will see under the list of available plugins. Whatever your preferred authentication system(s) are, there are a number of common settings that apply across all mechanisms.
Setting |
Description |
---|---|
Self registration |
Here, you specify which plugin is used for self-registration (refer to the next section for details). |
Allow login via email |
Users can either log in via their username or e-mail address as long as the latter is unique. |
Allow accounts with same email |
In some settings, users will have to share the same e-mail address. If enabled, be aware of the fact that user-specific messages will be potentially read by multiple persons, for instance, the password change confirmation e-mail. |
Prevent account creation when authenticating |
Some authentication mechanisms, for instance, LDAP, support the creation of new accounts if they're not present. If this is prevented, you will need to ensure that the accounts are created by other means. |
Auto focus login page form |
When enabled, the cursor on the login page will always jump directly to the username input field if empty, or to the password field otherwise. |
Guest login button |
By default, guest access to your Moodle system is allowed. If you disable this, which is recommended for most educational and commercial sites, the guest login button will not be shown on the login screen. |
Limit concurrent logins |
You can specify the number of simultaneous browser logins. Once the number has been exceeded, the oldest session will be terminated. This is useful in exam scenarios where you might want to allow only a single concurrent login. |
Alternate login URL |
By default, users have to log on to Moodle via the standard login screen. However, to change the source of the login credentials (username and password), enter the correct URL here. This is necessary if you wish to have a login block on a separate web page, such as your home page. Details of this mechanism are shown in Chapter 7, Moodle Look and Feel. |
Forgotten password URL |
Moodle has a built-in mechanism to deal with lost or forgotten passwords. If you use an authentication method that has its own system to do this, you have to enter its URL here. |
Instructions |
It is good practice to provide information on how to sign up for the system and what format the username should have (this only applies to self-registration). There are default instructions if it's left blank. |
Allowed email domains |
You can restrict the e-mail domains for self-registration that are allowed on your system when new user accounts are created, for example, |
Denied email domains |
Similarly, you can specify which e-mail domains are not allowed on your system. |
Restrict domains when changing email |
If enabled, the two e-mail domain settings, mentioned earlier in the table, will be applied when an e-mail address is changed. |
ReCAPTCHA public key |
This is the key to display the reCAPTCHA element on the signup form (refer to the Email-based self-registration section). |
ReCAPTCHA private key |
This is the key to communicate with the reCAPTCHA server (refer to the Email-based self-registration section). |
If enabled by the administrator, Moodle supports a mechanism that allows users to create an account without any intervention or knowledge of the administrator. When a new user signs up with Moodle via the Create new account button on the login screen, they can choose their own new username and password. Once this step has been completed, a confirmation mail is sent to the user's e-mail address, containing a secure link to a page where the user has to confirm the account. The signup screen looks like this:
When dealing with user-defined profile fields, we saw how to add more items to the signup screen (the Display on signup page option) in the Profile fields section. This is often invaluable in commercial training settings when additional data, such as the address of the learner or a customer number, has to be gathered.
Moodle supports a reCAPTCHA mechanism that has been activated on the preceding signup screen. The facility is used to avoid automated signups by bots. In order to activate this facility, you will have to sign up for a free account at http://www.google.com/recaptcha/intro/index.html, add the public and private key provided in Common settings in the Manage Authentication area, and enable the reCAPTCHA element, as shown in the Common authentication settings section.
The same locking settings can be set for self-registration as for manual accounts (go to Plugins | Authentication | Email-based self-registration). Also, the same restrictions apply as described earlier. Additionally, you have the option to Enable reCAPTCHA element.
If a site policy has been specified when you navigate to Security | Site policies, a link to the agreement with the confirmation checkbox, I understand and agree, is shown on the signup screen.
We have already seen a basic introduction to LDAP in the previous chapter when we dealt with enrolments. Now, let's look at how it can be utilized for authentication. We will only cover the basic LDAP settings and exclude advanced setups, such as multiple LDAP servers and the secure LDAP. These are discussed in greater detail in the Moodle Docs at https://docs.moodle.org/en/LDAP_authentication.
The principle of the authentication method is rather simple but effective—if the entered username and password are valid, Moodle creates a new user account in its database if it doesn't already exist. Once it does exist, that is, from the second login onwards, the credentials are checked against LDAP for validity.
Go to Plugins | Authentication | LDAP server to see the settings, which also cover Active Directory (Microsoft's implementation of LDAP). There are a significant number of parameters that you have to set to communicate with an LDAP server. The settings have been amended with detailed explanations (which I will not repeat). Instead, additional information is provided wherever applicable. If you are not sure where to locate some of the required information, contact your system administrator.
There are two types of parameters that have to be populated to make Moodle work in your LDAP setup, namely, settings and mappings, which are discussed in the sections that follow.
There are nine sections of LDAP settings that have to be provided:
ou=Students
and ou=Staff
and your students make up 90% of the logins, it is recommended that you put them before their lecturers unless the staff is given priority.It is common for user profile information to be stored in the LDAP server. In order to connect the two, user profile fields and Active Directory, a mapping has to be provided where a counterpart in the directory has to be provided for each field in Moodle (including user-defined profile fields). All the fields are optional. Default values are used if you leave any of the fields blank:
If you provide the field information, you will have to set four parameters for each data field, as follows:
Setting |
Description |
---|---|
Field name |
This is the field name in the external database representing the value in Moodle. |
Update local |
For each external user, information is stored locally. You can update this information on creation (this is faster but potentially not up to date) or every login (this a bit slower but it's always up to date). |
Update external |
If a user updates the value of the data field in Moodle, you can decide whether you want to write this information back to the external database (on update) or not (never). Often, the external database is a read-only view, which will prevent Moodle from updating data in it. |
Lock value |
You can specify whether the value can be modified by the user. The setting is identical to the lock field, which was explained earlier. |
If you use Microsoft's Active Directory, check out the Data Mapping section in https://docs.moodle.org/en/LDAP_authentication for details.
When using LDAP, you might come across a situation where you wish to assign courses to users before they have logged in to the system for the first time. This scenario regularly applies before the start of the academic year. The problem is that the local user accounts do not exist yet, and you cannot access this information as it is only stored in the external directory. A way around this is to create the user accounts via batch files and set the auth
field to ldap
. You can effectively mimic the initial logging in of each user.
The same applies to all external authentication mechanisms, including external databases, which are covered next.
Most large organizations use a student or some form of management information system—either open source, proprietary, or developed in-house—which holds information about staff and learners. It makes perfect sense to utilize this data for authorization to Moodle. Since all information systems use a database at their core, all we have to do is to get access to the relevant data.
IT departments are usually not too keen for external systems to connect to their database. A mechanism that has proven valuable is the read-only view. This has a number of advantages:
The external database authentication method contains two types of parameters that you have to provide by going to Plugins | Authentication | External database, namely, connection settings and data field mappings.
The database connection settings have been amended with good explanations. If you are not sure where to locate some of the required information, contact your database administrator.
If you experience problems establishing a connection between Moodle and the external database, you can run a test against the database via the Test settings option in the table of available authentication plugins. More detailed error messages will be displayed, which will help you identify the connection issue.
User profile information is stored in the external database. In order to connect the two—the user profile fields and the database—a mapping has to be provided where a counterpart in the external store has to be provided for each field in Moodle, including user-defined profile fields. All the fields are optional. Default values are used if you leave any of the fields blank.
This mechanism is identical to the one for the mapping of data in the LDAP setup, which we covered prior to this section.
In addition to the popular authentication mechanisms that we have dealt with so far, Moodle supports a number of additional external authentication methods as well as some internal ones, which we will cover in the following sections.
Due to the fact that these external authentication methods are not utilized as often as LDAP and external databases, we will only cover them in brief. Some pointers to websites for further information are as follows:
It is necessary for the Auth_RADIUS
module to be installed on the server.
More information on Shibboleth can be found at http://www.internet2.edu/products-services/trust-identity-middleware/shibboleth/.
Other external authentication modules are available as contributed third-party modules, for instance, OAuth and SAML. These can be found in the Downloads section on https://moodle.org/. More details on third-party add-ons will be covered in Installing third-party add-ons section in Chapter 8, Moodle Plugins.
Moodle provides three authentication methods, which are used by a range of internal operations:
Only user fields can be locked in the same way as described earlier.
18.189.189.67