This chapter will teach you how to manage users in your Moodle system. We will first look at what information is stored for each user and how we can extend their profiles. We will then perform several standard user actions before dealing with cohorts. Finally, we will deal with a wide range of user authentication mechanisms. We will cover the following topics:
The following diagram shows a high-level overview of the aforementioned topics (users, cohorts, and authentication) and how they are connected:
Figure 5.1 – Users, courses, and authentication – a high-level overview
By the end of this chapter, you will be able to manage all aspects of user accounts and user authentication. This is a lot to take in, so we’d better get going!
Other than guests, each user has a profile containing information about them. We will first deal with the information stored for each user and how it is organized in Moodle.
You can view your own profile by selecting the Profile item in the drop-down menu beside your name at the top of the screen. Click on the Edit profile link in the User details section to change your profile details. To modify the profiles of other users, click on the Edit icon beside their name by navigating to Site administration | Users | Accounts | Browse list of users.
Moodle user profiles are divided into pre-defined categories, which cannot be changed via the Moodle user interface:
In addition to these static profile field categories, Moodle allows us to create user-defined profile categories and fields. Before dealing with custom profile fields, we will cover the pre-defined fields grouped by the aforementioned categories.
The following screenshot shows the profile fields of the General category:
Figure 5.2 – User profile fields – General
Most of these items are self-explanatory, but there are a few things you need to know about each of them. Here is a brief description of each profile element, along with tips to use them effectively:
If you wish to use the email address as the username, consider the Allow login via email option (at Site administration | Plugins | Authentication | Manage authentication). That way, users have two alternatives to log in, their username and their email address.
Important note
If your users don’t already have a unique identifier that can be (re)used as their Moodle username, such as an email address or a staff ID, it is highly recommended to develop a consistent naming scheme for usernames, for example, firstname.lastname for smaller institutions or startyear.firstname.lastname.index for larger organizations.
Important note
An incorrect authentication method prevents users from logging in, or even completely deletes their account!
Important note
Account suspension is not the same as enrolment suspension. The former affects users and the latter, individual course enrolments.
If Password policy is enabled (in Site administration | Security | Site security settings), the password must adhere to this policy. Refer to Chapter 13, Ensuring Moodle Security, for more details on password policy.
Some organizations still do not make use of email addresses. As it is a mandatory field, there are two typical workarounds in this scenario.
The first option is to develop a unique dummy email address scheme or void email addresses solely used for identification purposes. While this solves the problem technically, it limits the user experience significantly because communication among users or notifications generated by Moodle cannot be sent.
The second alternative is to activate duplicate email addresses (enable Allow accounts with same email in Site administration | Plugins | Authentication | Manage authentication) and have users with an email address responsible for groups of learners, for example, a teacher for a class or a supervisor for workers. While this approach is not ideal from a privacy perspective – user-specific messages could potentially be read by multiple persons – at least somebody knows what is going on and can then communicate it to the intended recipients.
Additional fields might appear in the user’s profile, for example, Preferred theme or Email charset, but this requires the settings to be changed elsewhere. We will mention these when the respective topics are being dealt with.
The second category is called User picture, and, as the name suggests, it deals with the image attached to a user’s profile.
Simply drag it to the New picture pane or select the image from the file picker to upload a new picture. The image cannot be larger than the maximum size listed; if your image is too large, it is recommended to reduce its size to a minimum of 100 x 100 pixels. The supported formats are GIF, PNG, and the JPEG family; however, be careful with transparent backgrounds as they might cause issues in some browsers.
The Picture description field is used as an alt tag, a description of the image used for nonvisual browsers; it is in conformance with accessibility guidelines.
Figure 5.3 – User profile fields – User picture
Once a picture has been assigned, it will be shown in place of the None label. To remove the picture, check the Delete checkbox, and the picture will be removed when the profile information is updated.
Moodle will automatically crop the image to a square and resize it to 100 x 100 pixels for the larger view and 35 x 35 pixels for the smaller thumbnail view.
Important note
Two thumbnails are created automatically during the upload process, which reduces the file size to approximately 4 KB. An administrator can view all the uploaded user pictures via the <moodleurl>/userpix URL.
Moodle also supports Gravatars, so-called globally recognized avatars. Once you select the Enable Gravatar option on Site administration | Users | Permissions | User policies, Moodle will attempt to fetch a user profile picture from gravatar.com if the user has not uploaded an image.
If you suspect that your learners will likely misuse this feature by uploading inappropriate images, you can disable the functionality. Go to Site administration | Security | Site security settings and tick the Disable user profile images checkbox. Remember that once this feature is disabled, pictures cannot be assigned to any users (except the administrator), nor will it be possible for teachers to represent groups in courses with images.
This Additional names section comprises the following fields:
Interests, such as hobbies or professional activities, can be entered one by one. To remove a tag, select its label. The given List of interests represents tags displayed in the user’s profile. You can find more information on tagging at docs.moodle.org/en/Tags and in Chapter 9, Configuring Educational Features.
Figure 5.4 – User profile fields – Interests
More personal details are grouped under the Optional category:
Some organizations rename unused fields to ones required in their setup. For more information on this, refer to the Localization section in Chapter 10, Configuring Technical Features.
This concludes the explanation of pre-defined user profile fields. The list can be extended by custom fields covered in the following section.
Moodle allows new arbitrary fields to be added to user profiles. We have already described the management of user-defined fields in the previous chapter when we dealt with custom course fields. Since the exact mechanism is used for user profile fields, we only deal with account-specific idiosyncrasies.
We just learned that profile fields are organized into categories (for instance, General, User picture, Interests, and Optional). Additional categories can be created, and user-defined fields can be placed within these new categories. This feature can be found by navigating to Site administration | Users | Accounts | User profile fields.
Unlike in custom courses, a default category, called Other fields, is already present, which can be deleted or renamed via the standard Moodle icons. To create a new category, click the Create a new profile category button at the bottom of the user profiles once the profile fields have been added.
The five profile field types in courses (checkbox, date/time, drop-down menu, text area, and text input) exist for users, plus one more: social. Let us go through the differences in the field-specific settings:
If you upgrade from Moodle 3.x and any of these services are populated, they will be retained and converted automatically.
Figure 5.5 – User profile fields of type social
Each field type in user-profile fields has the same parameters as custom course fields with three notable differences:
To demonstrate how user profile fields work, let’s assume a school where you wish to extend the user profile with a new profile category called Parental responsibilities comprising fields such as Contact person and Relationship:
Figure 5.6 – User profile fields example
This completes the subsection dealing with custom user profile fields, extending standard user profiles. The third and last component of user profiles is user preferences, which we will cover next.
Some more fields technically belong to the user profile, but they have been placed in the Preferences section, which can be accessed via the drop-down menu beside the user icon in the toolbar. The reason why this has been done is that you can disallow users from editing their profile altogether (via the moodle/user:editownprofile capability) and let them specify preferences via dedicated forms:
The default preferences of some settings (email, forums, and content bank) can be specified by navigating to Site administration | Users | Accounts | User default preferences.
This completes the section on user profiles, where we covered standard and custom profile fields and briefly looked at various user preferences. Now that we know what a user profile looks like, let’s start interacting with users.
So far, you have learned what type of user information Moodle holds and how to extend the data stored in each profile. Now, it is time to work with existing users on your system, which consists of browsing and filtering user accounts and applying bulk actions.
The quickest way to view your Moodle user accounts is by navigating to Site administration | Users | Accounts | Browse list of users. Initially, a list of users is displayed, ordered by First name. Thirty users are shown at a time, and, if applicable, you can navigate via the « and » links or jump directly to another page by selecting a number. Each column can be sorted in ascending or descending order by clicking on the column header.
Figure 5.7 – Browsing user accounts
You can view an individual’s profile by clicking on a user’s name. In addition to the fields we introduced in the first section of this chapter, you can see Login activity showing First access to site, Last access to site, and the Last IP address login took place from.
You can specify which identity information (username, ID number, email address, phone numbers, department, institution, city, and country) about the users is shown in this list and other places. Go to Site administration | Users | Permissions | User policies and select the fields that should be shown in the Show user identity list. This only applies to users with the moodle/site:viewuseridentity capability.
Important note
To masquerade as another user, use the Log in as option in a user’s profile.
When you look at the profile of another user account, you will see a Log in as link in the Administration pane, which lets you masquerade as another user. This feature is useful when tracking down issues you cannot locate as an administrator. To view all the user profile fields of a user or modify any of them, as discussed earlier, click on the Edit profile link. To modify any of the user’s preferences, select the respective link.
Go back to the user list and click on the standard Delete icon in the rightmost column to delete a user. A confirmation screen has to be answered before the user is irreversibly removed. Actually, the user is only removed from Moodle’s user interface. Internally, the user is retained in the database with the deleted flag turned on, which is necessary so that certain user contributions don’t disappear, for instance, forum posts. Technically, a user account can be reinstated by changing the delete flag manually in the database.
To suspend a user account, toggle the Show/Hide icon, which triggers the account suspension, as discussed in the User profile fields section.
Related to browsing accounts is filtering, which narrows down the number of user entries you are dealing with. This refinement mechanism is particularly helpful on sites with a large number of user accounts.
We may often be required to search for a particular user or a set of users. Moodle provides a flexible filtering mechanism to refine the list of displayed users. In basic mode, you can filter by the user’s full name, which is the first and last name combined. The following filter operations are available, all of which are case insensitive:
For example, when adding a filter, such as User full name starts with “cl”, all users whose name begins with cl are displayed. Take a look at the following screenshot:
Figure 5.8 – Filtering user accounts I
You can see that the added filter is now active, which becomes more useful once multiple filters have been added (switch to advanced mode via the Show more… link). Now, we can apply filters to a wide range of fields:
Figure 5.9 – Filtering user accounts II
For instance, in the preceding screenshot, we look for all users whose username starts with 22 (assuming the naming scheme starts with the year of entry) and whose account has been suspended. Using this mechanism, it is possible to add as many filters as required.
Every time a filter is added, it will be shown in the Active filters frame and applied to the user data in Moodle.
Figure 5.10 – Filtering user accounts III
Here, three self-explanatory filters have been added. It is now possible to delete individual filters (select the filter and click on the Remove selected button) or Remove all filters.
The filter criteria for text fields have been described earlier in this section. Depending on the field type, some additional operations can be used, as listed in the following table:
Figure 5.11 – Filtering operations
The Authentication criterion offers a selection of all the supported authentication methods. We will deal with these later in the chapter. If user profile fields have been specified, an additional User profile fields criterion is shown, offering a choice of all the user-defined fields (as specified earlier).
The current filter settings are saved and can be used the next time you log in. Not only that but they are also saved for bulk user actions, which are covered in the next section.
Bulk actions allow an administrator to perform a single action on multiple users, for example, forcing a password to change or sending a message. To illustrate how bulk user actions work, have a look at the user actions funnel depicted in the following diagram:
Figure 5.12 – Bulk user actions funnel
The three layers of the funnel have the following characteristics:
Various bulk actions can then be applied to this group of chosen user accounts by going to Site administration | Users | Accounts | Bulk user actions.
Figure 5.13 – Bulk user actions I
The screen contains three main sections. The first two parts are the familiar New filter and Active filters sections. Interestingly, filters already created will also show up on this screen since they have been saved.
The third part displays the users that match the specified filter criteria in the All filtered list. Before you can do anything with the users, you must move them to the All selected list using the Add to selection button. In the preceding screenshot, all users except one have been moved across. To move them back to the All filtered list, select the users and click the Remove from selection button. Two shortcut buttons exist, which allow you to add all users from the All filtered list to the All selected list and use Remove all to move them in the opposite direction.
The advantage of this approach is that you can apply several filters in succession and select the respective users, for example, in a setting where the usernames start with the year of entry. Suppose you wish to select all the users from 2022 and 2023, filter for all usernames that start with 22, and select all the entries that show up in the results. You can then delete the filter and repeat the filtering with the value 23.
When the Go button for the With selected users... drop-down menu is clicked, the operation selected will be performed on the users from the All selected list. The available operations are shown in the following table:
Figure 5.14 – Bulk user actions II
Now that we know how to deal with existing users, let’s look at how they are added to the system.
There are two ways to manually create accounts for users to get access to your system:
In the following three sections, you will learn how to perform and support each type.
To add user accounts manually, go to Site administration | Users | Accounts | Add a new user. Alternatively, you can navigate the list of users and select the Add a new user button at the bottom of the screen. You will see the same form you saw earlier when you edited the user’s profile.
Important note
Adding users manually should be the exception, not the rule. It is highly recommended to automate the process.
You should avoid adding individual users manually as much as possible, as it is a very time-consuming, cumbersome, and potentially error-prone procedure. However, there are situations when you cannot avoid it, for example, when a student joins a school halfway through the term or an external trainer requires access to Moodle but is not part of the organization’s staff database.
If you have more than one user to add, use Moodle’s batch uploading facility, which we will look at next.
Uploading users in bulk allows importing multiple user accounts from a text file or updating user accounts that already exist in your system.
Learner information is often available in existing applications, such as the internal student management information system or HR database, which can export data to an Excel spreadsheet or directly to a text file. The data represented in the CSV file is then loaded to the Moodle database, and, if specified, users are enrolled in courses and added as members to cohorts. This process is shown in the following workflow diagram:
Figure 5.15 – Bulk user upload
You will find excellent and detailed instructions on uploading and updating users in batch mode at docs.moodle.org/en/Upload_users. We will focus on the key elements and upload workflows to supplement the well-documented feature.
Before uploading users, you must generate a text file conforming to a specific format. Its general format is a Comma Separated Value (CSV) file, a flat text file format. While creating CSV files manually (using a plain text editor or a spreadsheet application) is possible, the files are usually generated automatically by a system hosting the user data.
The format of a text file is as follows:
An example of a valid input file is as follows:
username, password, firstname, lastname, email
galmond, pwd, Graham, Almond, [email protected]
earmstrong, pwd, Eleanor, Armstrong, [email protected]
jarnold, pwd, Joanne, Arnold, [email protected]
The first line contains the list of provided fields, while the remaining three lines represent individual users to be uploaded.
Moodle’s upload function supports the following types of data fields:
We will be going through each field type to understand better how Moodle’s user batch upload works and how you can use it in your setting.
When adding new users, only firstname and lastname are compulsory. When updating records, only username is required. You might recall that the user profile has a few more compulsory fields, such as the username or email address. A default value must be specified via a template if these fields are not provided. We will deal with templates later in this chapter.
The sample file is an example of an input file containing five fields, including the required firstname and lastname.
The password value is required unless Create password if needed and send via email has been enabled. If this is the case, a welcome email with a one-off password will be sent to the respective user the next time the cron process runs.
Note
If you set password to changeme, the user will be forced to change the password when they log in for the first time. A better way to do this is using the Force password change option.
As the name suggests, optional fields do not have to be specified—if they are not included in the text file, default values are taken, if present. These optional fields are as follows:
Figure 5.16 – User upload (optional fields)
It is crucial to include empty fields when the default setting has to be used. These must be left empty even if it is the last field in each record. An empty field is represented by two consecutive commas, as shown in the sample file:
username, password, firstname, lastname, email, city
galmond, changeme, Graham, Almond, [email protected], Kyiv
earmstrong, , Eleanor, Armstrong, [email protected],
jarnold, , Joanne, Arnold, [email protected], Doha
A city field has been added in the preceding sample file, and the default city has been set to Paris. After uploading the file, the city value for Graham Almond is set to Kyiv, and that for Joanne Arnold is set to Doha. The city value for Eleanor Armstrong has been left empty and will be set to the default value of Paris. Some password fields have also been left empty.
Any user-defined fields you have specified (in our case, those for parental responsibilities) can also be used as part of the batch upload process. Each field must be preceded by profile_field_; for instance, the field representing the Skype ID would be labeled profile_field_skype_id.
Custom fields are treated in precisely the same way as optional fields. If specified, the values are taken; otherwise, default values will be used, if present.
Enrolment fields allow you to assign roles to users; you can enrol them in courses and assign them to groups. Roles will be covered in detail in Chapter 6, Managing Permissions, Roles, and Capabilities.
Each course has to be specified separately by course1, course2, course3, and so on. The course name is the course’s short name and the only compulsory enrolment field. Each corresponding type, role, group, enrolment start time, enrolment period, and enrolment status must have the same postfix: type1, role1, group1, enroltimestart1, enrolperiod1, and enrolstatus1 correspond to course1.
It is further possible to set a user’s role in a course. Each role has a role short name and a role ID, either of which can be specified. If the type is left blank or no course is specified, the user will be enrolled as a student. The enrolment period sets the enrolment duration in terms of days; the enrolment status suspends a user from a course when it’s set to 1.
If you want to assign users to groups in a course (group1 in course1, group2 in course2, and so on), you have to specify the group name or ID. If a specified group does not exist, it will be created automatically.
The following example demonstrates some of the enrolment features:
username, course1, role1, course2
galmond, Advanced, editingteacher, Staff
earmstrong, Advanced, examiner, Staff
jarnold, Basic, 3, Staff
The course1 field and its corresponding role1 and course2 are optional enrolment fields. Graham Almond (galmond) will be assigned the editingteacher role in the Advanced course, and Eva Armstrong (earmstrong) will be assigned the examiner role. Jonny Arnold (jarnold) will be editingteacher (the role ID is 3) in the Basic course. All three users will be assigned the student role in the Staff course (no role has been specified, hence the default is set).
Cohort fields allow you to add users as members to cohorts. Like enrolments and groups in courses, the field name has to be suffixed by a counter: cohort1, cohort2, and so on. An example file snippet is as follows:
username, firstname, lastname, cohort1, cohort2
pupil1, Pupil, One, 7a, drama
pupil2, Pupil, Two, 7a, archery
Users can be added to system cohorts as well as context cohorts. Cohorts will be dealt with after this main section.
If you need to assign users a system role, you must specify this via sysrole1, sysrole2, and so on. The field’s value has to be shortname of the role, for instance, manager or coursecreator.
You can also unassign a system role from a user by preceding the role name with the minus symbol, for example, -manager or -coursecreator.
The following special fields are supported:
Special fields are the last category of text file format. Once you have created your user file, it is time to upload users to Moodle, which we will tackle next.
Uploading users is a four-step process, as shown in the following diagram:
Figure 5.17 – User upload workflow
The workflow comprises the following four steps:
We already covered step 1 in the previous subsection, so let’s jump straight to the second and third phases. To upload or update users in batch mode, go to Site administration | Users | Accounts | Upload users, where the following settings are available:
Figure 5.18 – Upload users configuration
Once this screen has been confirmed, you will see the following four sections:
Remember that not all settings exist for all upload types; they will remain hidden if they are not applicable. The following table shows which settings are available for which upload type:
Figure 5.19 – Upload users settings
Here is a brief description of each Upload users setting:
Default values have been mentioned a few times so far; now, it is time to deal with them alongside templates.
Moodle’s user batch upload function supports default values that are used if no value has been set. Default values cover all user profile fields that can be uploaded as well as user-defined custom fields.
Each text-based field can be populated using a template. This feature is helpful for optional fields, such as the URL of students’ websites, and is compulsory for required fields if they’re not specified in the CSV file, for example, username and email. Moodle will warn you if the latter is the case. For example, in the following screenshot, Username template has not been provided, which is indicated by the red warning message:
Figure 5.20 – Template missing
The template (or pattern) will create a value based on the values of other fields and the standard characters you specify. A template can comprise the following content:
The following table hopefully clarifies the preceding concepts:
Figure 5.21 – Template content
There are four replacement values, indicated by a percentage. For example, if the username should be the first name of a user, followed by a period, and then the surname, the template would look like %f.%l.
Four modifiers can be included between the % sign and any of the three code letters (l, f, and u), where the hash represents a decimal number. The last template is an example embedding the replacement values inside other text; in this case, it is a URL representing a user’s home page.
This completes the third step of our user upload workflow. The last step is to load and review the actual user data.
Once all the settings have been specified, the default values have been provided, and the Upload users button has been pressed, Moodle will finally start the actual importing process.
Important note
It is highly recommended that you create a test file with a smaller number of dummy records first to ensure that the syntax is correct.
Moodle displays a large table that contains all the user fields that have been added and/or changed. It also shows the status of each field, including any problems or errors that have occurred.
A message is displayed at the end of the results screen, summarizing the upload process. It contains the number of users created and updated, those with a weak password (according to the password policy), and the number of errors. Take a look at the following screenshot:
Figure 5.22 – Reviewing upload results
It is recommended that you immediately identify invalid user accounts and modify their user settings manually or fix the upload file and do a re-run.
Bulk user operations provide a versatile means to create and update textual user data. However, one type of user information that CSV files cannot process exists: profile images. Moodle comes with a dedicated feature that deals with user pictures. Let’s take a look at it in the next section.
As described so far, the process of uploading users does not support profile images; instead, user pictures must be uploaded separately. The workflow to upload user images is simple yet effective, as depicted in the following diagram:
Figure 5.23 – User pictures upload workflow
The upload user picture tool can be found at Site administration | Users | Accounts | Upload user pictures. The images to be uploaded have to be archived in a ZIP file. Each image filename inside the compressed file must conform to the following format: attribute.ext.
The User attribute to use to match pictures field is set to any of these values: username, idnumber, or (the internal user) id. This attribute is used to match the picture to an existing user, and you have to select the attribute in the respective pull-down menu. ext is the filename extension (.jpg, .gif or .png). The image filenames are not case sensitive.
Figure 5.24 – Upload user pictures
For example, if the username consists of the first name’s initial and a surname (%1f%l, if expressed in template style), the valid filenames are psmith.png, lcohen.png, and mstripe.png. If the users exist, the pictures will be added to their profiles; otherwise, they will be ignored. If a picture already exists for a user, it will only be replaced if you have enabled the Overwrite existing user pictures? option.
So far, we have only looked at individual users on an account-by-account basis. Moodle thrives on being a learning system that supports communication and collaboration among learners and teachers. To support working together, users can be arranged in two ways: groups and groupings at the course level, and cohorts at the system or category level. We have already come across groups in the previous chapter and during the user batch upload, so let’s have a closer look at cohorts now.
We have already come across cohorts in Chapter 4, Managing Courses and Enrolment, and in the introductory diagram of this chapter.
Important note
Cohorts are groups that are used to logically cluster related users.
So far, we mainly mentioned cohorts in the context of enrolments; however, cohorts are utilized by Moodle in various places, such as the following:
Zooming in on the cohort element, we can see its structure and properties:
Figure 5.25 – Cohorts (high-level)
Let’s have a closer look at how to create and manage cohorts. To do this, navigate to Site administration | Users | Accounts | Cohorts.
Figure 5.26 – Available cohorts
The details of each cohort and its standard actions (hide, delete, edit, and assign) are provided. The All cohorts tab provides an almost identical view, displaying system and category cohorts.
To create a cohort, select the Add new cohort tab and specify the cohort’s properties. Context is the scope of the cohort that indicates where the cohort can be used; the options are System (global or site-wide) and a selected category. Cohort ID is optional, but it is good practice to set this as it will be used for different operations, such as when adding bulk users.
Figure 5.27 – Adding a cohort
Once you have added a cohort, you will return to the list of all cohorts. Now, you should add members to it by selecting the Assign icon, which will display the familiar user selection screen to add or remove cohort memberships.
Important note
Removing users from a cohort will unenrol them from all courses where cohort synchronization has been enabled!
Instead of adding cohorts manually, you can perform this task in a batch via the Upload cohorts tab. The principle is the same as adding users in batch mode, as described in the previous section. Here is a sample file representing the cohorts used earlier:
name, contextid, idnumber, description, visible
7a, 1, 7a, All students from class 7a, 1
7b, 1, 7b, All students from class 7b, 1
7c, 1, 7c, All students from class 7c, 1
Temp, , , Used as a placeholder, 0
You can find details on uploading cohorts, including optional and additional fields, at docs.moodle.org/en/Upload_cohorts.
Now that you know everything about user accounts and the information stored about them, let’s look at how to authenticate them with Moodle.
Authentication is the process of getting access to a system. 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 staff, and OAuth2 for students, but it wishes to manage part-time users locally.
In the second half of this chapter, we will explore user authentication and the overall management of authentication plugins before covering common authentication settings. Then, we will deal with all authentication methods, which have been grouped into four categories: internal, external, provider, and system.
Remember the basic authentication workflow we looked at in Chapter 3, Exploring Courses, Users, and Roles. Now, we can have a look at a more complete picture, as shown in the following diagram:
Figure 5.28 – Authentication workflow
Let’s start from the top, where the user enters their user credentials, for example, username and password. Bear in mind that this could take place automatically, for example, in a single sign-on setup or via a service provider login. 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 credentials are valid.
If the user profile doesn’t exist, which is often the case the first time a user attempts to log in, Moodle checks for any enabled and configured external provider-based authentication mechanisms. If there is a valid entry, an account will be created, 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 or via a provider, 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 Site administration | Plugins | Authentication | Manage authentication. You will see a list of available authentication plugins. Each plugin can be activated/deactivated by toggling the show/hide icon. The settings for each type discussed in this section are accessed by their respective links or directly through the link in the plugins menu once the authentication method is active.
You can also change the order in which Moodle attempts to authenticate users via the up and down arrows.
Important note
The order in which authentication plugins are applied will impact how long it takes for users to log in, so make sure that the main ones are at the top.
The Users column gives you an indication of the number of registered users for each authentication mechanism.
Figure 5.29 – Authentication plugins
Additional authentication methods are supported by external plugins on moodle.org/plugins/?q=type:auth, for example, OpenID and SAML2. Once installed (refer to the Installing third-party add-ons section in Chapter 8, Understanding Moodle Plugins), they will appear in the list alongside all the core authentication methods. It is not recommended that you remove plugins via the Uninstall option—delete them at the system level instead.
The following diagram illustrates a clustering of Moodle authentication plugins:
Figure 5.30 – Authentication plugins grouping
This grouping also forms the structure of the remainder of the chapter, starting with common authentication settings all mechanisms share.
First, let’s look at the common authentication settings, which you will see under the list of available plugins. Whatever your preferred authentication system(s) is, several common settings apply across all methods:
Important note
Ensure to disable guest access to your Moodle system to prevent unwanted registrations.
Some common authentication settings will make more sense once we have dealt with the authentication methods they impact. Let’s start with internal authentication methods.
Internal authentication methods handle all authentication within Moodle; no other system is connected. There are two internal authentication methods: manual accounts and email-based self-registration.
Manual account authentication is simply the verification at login that the entered user credentials (username and password) stored in Moodle are correct.
Important note
The main Moodle administrator account is always a manual account.
There are two types of settings for all manual accounts created: password expiry and the locking of user fields. Both can be changed by navigating to Site administration | Plugins | Authentication | Manual accounts.
Figure 5.31 – Manual accounts settings
Password expiry lets you choose how long a password is valid via the Password duration setting before it has to be changed by a user. Notification threshold lets you specify when a user is notified of the password rotation.
You can lock fields for accounts that are manually created or uploaded via batch files. This locking mechanism is helpful whenever you do not want users to be able to change specific data in their user profiles—young students may misuse the Description field, the ID number may be used internally to link to other systems, the company might have provided the email address, and so on.
By default, all fields are Unlocked. If a field is Locked, the user will not be able to change its value. If you lock any compulsory fields, you either have to ensure they are populated correctly, or you set their lock state to Unlocked if empty. The latter will force the user to enter the value the next time they log in and lock the field afterward.
Accounts verified by the manual authentication method are usually created manually or via user batch upload. Both operations have been described in detail in the first part of this chapter, where the latter effectively automates manual account creation. Two other authentication mechanisms mimic adding user accounts manually: web services, which we deal with in the System authentication methods section later on, and Email-based self-registration, which we cover next.
Moodle supports a mechanism that allows users to create accounts without any intervention or knowledge of the administrator. When new users sign up with Moodle via the Create new account button on the login screen, they can choose their new username and password. Once this step has been completed, a confirmation mail is sent to the user’s email address, containing a secure link that must be confirmed to activate the account. The signup screen looks like this:
Figure 5.32 – Self-registration signup screen
We explained how to add more items to the signup screen (via the Display on signup page option) when dealing with user-defined profile fields. This feature is often invaluable in commercial training settings when additional data, such as the learner’s address, a participant’s dietary requirements, or a customer number, has to be gathered.
Moodle supports a reCAPTCHA mechanism activated on the pictured signup screen. The facility is used to avoid automated signups by bots. To enable this facility, you must sign up for an account at www.google.com/recaptcha, add the public and private key in Common settings in the Manage Authentication area, and enable the reCAPTCHA element.
Important note
The PHP cURL extension must be installed for reCAPTCHA to work.
The same locking settings can be set for self-registration as for manual accounts (go to Site administration | Plugins | Authentication | Email-based self-registration). Also, the same restrictions apply as described earlier. Additionally, you have the Enable reCAPTCHA element option.
If a user policy has been specified when you navigate to Site administration | Users | Privacy and policies | Policy settings, a link to the agreement with the confirmation checkbox is shown on the signup screen. We will deal with more complex user consent handling as part of the GDPR set up in Chapter 14, Complying with Data Protection Regulations.
If the confirmation email cannot be sent, for instance, because of technical issues, go to the list of users, where you will find two links beside the account entry: one to confirm the account and one to resend the email.
Before we move on to the next authentication method, here is a short checklist for setting up self-registration (apart from enablement, all steps are optional):
Figure 5.33 – Checklist for self-registration
Allowing users to register accounts on your site comes with a degree of risk since you have no control over who – humans or bots – is coming to your site (assuming it is publicly accessible). Therefore, it is highly recommended to test self-registration thoroughly and regularly check your new users list.
Now that we have covered internal authentication, it is time to look over the (Moodle) fence and deal with external methods.
External authentication methods require a separate, connected system to handle authentication. We will cover two external authentication methods in detail (LDAP and databases) and two more we only briefly describe (CAS and Shibboleth).
In the previous chapter, we had already seen a basic introduction to LDAP when dealing with course enrolment. Now, let’s look at how it can be utilized for single sign-on (SSO) authentication. We will only cover the basic LDAP settings and exclude advanced setups, such as multiple LDAP servers and secure LDAP. These configurations are documented in great detail at docs.moodle.org/en/LDAP_authentication.
The principle of the LDAP authentication method is relatively 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.
Important note
The PHP LDAP extension must be installed on the server for LDAP authentication to work.
Go to Site administration | Plugins | Authentication | LDAP server to see the settings, which also cover Active Directory (Microsoft’s implementation of LDAP). There is a significant number of parameters that you must 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. Contact your system administrator if you are unsure where to locate some of the required information.
Two parts must be populated to make Moodle work in your LDAP setup: server settings and data mappings, discussed in the following paragraphs.
There are ten sections of LDAP server settings that have to be provided:
The second half of the admittedly very long screen contains the LDAP data mapping. It is common for user profile information to be stored in the LDAP server. To connect user profile fields and the Active Directory, a mapping has to be provided by specifying their counterparts in the directory 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:
Figure 5.34 – LDAP authentication (data mapping)
If you provide the field information, you will have to set four parameters for each data field, as follows:
If you use Microsoft’s Active Directory MS-AD, check out the data mapping section in docs.moodle.org/en/LDAP_authentication for details.
Setting up LDAP authentication can be a bit of trial-and-error. Verifying that the connection works can be assisted by the Test setting facility located in the list of available authentication plugins. More detailed error messages will be displayed, which will help you identify any SSO connection issues.
When using LDAP, you might encounter 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. There are two ways around this conundrum:
LDAP is effectively a specialized and lightweight database for authentication purposes. Authentication against LDAP is very similar to authentication against external databases, which is the topic of the following subsection.
Most large organizations use a student or management information system—either open source (good), proprietary (bad), or developed in-house (worst)—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 directly to their database. A mechanism that has proven valuable is the read-only view, which has several advantages:
The external database authentication method contains two types of parameters that you have to provide by going to Site administration | Plugins | Authentication | External database: connection settings and data mappings.
Figure 5.35 – External database authentication
The database connection settings have been amended with good explanations. Contact your database administrator if you are unsure where to locate some of the required information.
Important note
Some databases, such as Oracle, are case sensitive, and field names must be provided with the correct casing for the database link to work correctly.
The second half of the settings screen contains the data mapping. User profile information is stored in the external database. To connect 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, and default values are used if you leave any fields blank.
Most facilities covered in the LDAP section are also available for external database authentication:
To sum up the topic, here is a checklist for external authentication methods:
Figure 5.36 – Checklist for external database authentication
Hopefully, the previous two subsections gave you an insight into how external authentication mechanisms work in Moodle. Two more methods fall in the same category: CAS and Shibboleth.
Moodle supports some additional external SSO authentication methods that are not utilized as often as LDAP, external databases, and OAuth 2; we only briefly touch upon them:
All authentication mechanisms covered so far are either internal to Moodle (manual accounts and self-registration) or usually local to the organization but external to Moodle (LDAP or database). Moodle also supports provider-based authentication services via OAuth 2, which we will cover next.
OAuth 2.0 is the de facto industry standard protocol for user authorization. OAuth 2 authentication enables users to access Moodle via buttons on the login page using their credentials from popular service providers, such as Google, Microsoft, Facebook, and LinkedIn.
Figure 5.37 – Authentication via OAuth 2 service providers
Before we dive into the configuration of service provider-based authentication, have a look at the interaction diagram, which illustrates how OAuth 2 works in a Moodle context:
Figure 5.38 – OAuth 2 interactions
An OAuth service provider is an external system (“in the cloud”) that provides identity (via the authorization server) and API access (via the resource server) by issuing OAuth access tokens to a client (Moodle). Let’s go through the interactions from top to bottom:
The preceding interaction process is a very crude summary of how OAuth 2 authentication works in Moodle, but this should be sufficient to understand the overall concept. OK, enough of the high-level stuff; let’s start setting up service provider authentication.
The first step is to configure OAuth 2 services in Site administration | Server | Server | OAuth 2 services.
Figure 5.39 – OAuth 2 services
At the bottom, you can see all supported service providers. Select the respective button to add a preconfigured service, which will direct you to the form to create a new service. The service specifications are already populated – all you must do is add the Client ID and the Client secret details of the respective service provider.
How do you get the client ID and secret? The issuer provides these, so setup must be done at their end, not in Moodle. There is a Service provider setup instructions link for the six supported prominent OAuth 2 providers at the top of the screen.
Important note
It is recommended to leave all fields at their default values for pre-defined service providers, except Client ID, Client secret, and Service base URL.
If you wish to set up a service provider not listed, you can create a Custom service. The form is identical to the pre-defined services but without any pre-populated values. You find details about the purpose of each parameter at docs.moodle.org/en/OAuth_2_services.
Once the service has been created (pre-defined or custom), the standard actions are available in the Edit column, plus two more actions that require some more explanation:
Once the service provider has been configured properly, it can be used by the OAuth 2 authentication plugin, which has to be enabled at Site administration | Plugins | Authentication | Manage authentication. Like all other authentication plugins, OAuth 2 lets you configure any locked fields, and there are no additional configuration options as the service provider setup controls all behavior.
As with other authentication methods, let’s conclude the section with a checklist, which hopefully comes in useful when you have to configure OAuth 2 authentication:
Figure 5.40 – Checklist for OAuth 2 authentication
We have now covered all the authentication mechanisms that ship with Moodle and belong to the first three pillars of our authentication plugin grouping. The fourth category comprises system authentication methods, which we are covering next.
Moodle contains authentication methods, which are required by certain features to function correctly:
This concludes the section on user authentication. While there has been a lot of content, you are highly likely only to require information on manual accounts plus the method(s) you are utilizing in your organization. Since no two authentication setups are the same, you will soon be familiar with all the quirks and idiosyncrasies of your authentication infrastructure and the plugin(s) that connect it.
A last piece of advice: be on good terms with your system, database, and network admins. They will grant you access to your LDAP directory or the organization’s authentication database system and open up the ports you need to connect to service providers and web services. Buy them a coffee or bribe them with other niceties!
Phew! That was a lot to take in for one chapter.
The first part of this chapter demonstrated the different ways Moodle provides to manage users. We first looked at what information is stored for each user account and how their profiles can be extended. We then performed several standard manual and bulk user actions before dealing with cohorts.
In the second part, we dealt with different types of user authentication, namely internal, external, service providers (via OAuth 2), and system. Due to the variety and complexity of authentication methods, we covered prominent plugins in more detail than others.
Authentication has become a complex topic, and we only touched upon methods supported in Moodle core. Other methods such as Microsoft Azure AD or Open ID as well as mechanisms such as two-factor authentication, one-time passwords, and user key authentication are beyond the scope of this already packed chapter and are catered for via plugins at moodle.org/plugins/?q=type:auth.
One aspect of authentication we didn’t mention at all is multi-tenancy. Assume a setup where different users have to connect via different authentication mechanisms of the same type; for instance, staff authenticates via SAML_internal, and customers and partners via SAML_external. There are two options for how this can be facilitated:
The next step is to grant user roles, that is, the rights as to what they are allowed to do and what they are not. This will be dealt with in the next chapter.
3.149.249.252