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:
- LDAP server settings: These establish the connection to the directory. LDAP servers with the SSL encryption are also supported.
- Bind settings: These specify details about the credentials needed to access the LDAP server. If you have multiple bases, it is recommended that you put them in order of importance as Moodle stops searching once it has found an entry. For example, if you have
ou=Studentsandou=Staffand your students make up 90% of the logins, it is recommended that you put them before their lecturers unless the staff is given priority. - Don't cache passwords: This specifies whether passwords are being stored in the Moodle database or not. This is useful because your LDAP server might not always be accessible, which would prevent users from logging in.
- User lookup settings: These describe how and where a user is stored on your LDAP directory. Make sure you select the correct User type. For multiple contexts, the same applies as for the distinguished name in the bind settings. It is important to set Search subcontexts correctly. If it is set to No, subcontexts will not be searched, but the search is potentially faster and vice versa.
- Force change password: This specifies whether and how passwords have to be changed by users when they first access Moodle.
- LDAP password expiration settings: These are concerned with password lapsing and how this is being dealt with.
- Enable user creation: Lets you activate a mechanism that's similar to self-registration, but in addition to this, an account is created with the values from your LDAP.
- Course creator: This specifies which LDAP user groups will have course creator permissions in Moodle.
- Cron synchronization script: This setting specifies what Moodle should do with local user accounts when these have been deleted on the LDAP server.
- NTLM SSO: This describes how in a Windows-based environment with MSAD active, NTLM, if configured correctly, supports single sign-on. That is, users logged in via the Windows domain do not have to reenter their credentials when accessing Moodle. Check out https://docs.moodle.org/en/NTLM_authentication for details.
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:
- A view can be prepared for Moodle usage, that is, only required fields are shown in the required format
- There's no write access to the database
- If the database schema of the information system ever changes, only the view has to be adapted, not Moodle
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:
- CAS Server(SSO): Central Authentication Service (CAS) is an open source authentication server that's based on Tomcat and supports single sign-on in a web environment. CAS is gaining in popularity, particularly in environments that comprise multiple authentication sources and consumers. It utilizes LDAP and, therefore, requires the PHP LDAP modules to be installed.
- First Class Server: By Open Text Corporation is a commercial client/server groupware, e-mail, online conferencing, voice/fax service, and a bulletin board system for Windows, Macintosh, and Linux. The product is used for the authentication of pupil accounts. In addition to some First Class-specific settings, user fields can be locked in the same way as described earlier.
- IMAP Server: Internet Message Access Protocol (IMAP) is a standard used by many e-mail servers such as Microsoft Exchange. The user contact information in the server is used for Moodle authentication. In addition to some IMAP-specific settings, user fields can be locked in the same way as described earlier.
- NNTP Server: Network News Transfer Protocol (NNTP) is mainly used to transfer articles and Usenet messages between news servers. Its user details are used for Moodle authentication.
- PAM: Pluggable Authentication Modules (PAM) is yet another authentication scheme that maps user information onto a higher-level application interface. PAM is open source and has been adopted as the authentication framework of the Common Desktop Environment. It is currently supported by all the main Linux derivatives. The PHP PAM Authentication module has to be installed on the Moodle server.
- POP3 Server: Post Office Protocol version3 (POP3) is a standard used by many e-mail servers. The user contact information on the server is used for the Moodle authentication. In addition to some POP3-specific settings, user fields can be locked in the same way as described earlier.
- RADIUS Server: Remote Authentication Dial In User Service (RADIUS) is a protocol to control access to various network resources. It supports authentication, authorization, and accounting and is used by Internet Service Providers.
It is necessary for the
Auth_RADIUSmodule to be installed on the server. - Shibboleth: Shibboleth is a SAML-based open source middleware that provides Internet single sign-on across organizational boundaries. Privacy and security as well as its flexibility in terms of multi-setups, are at the heart of Shibboleth, which is the main reason for its growing popularity. However, the price to pay is a complicated setup process that has been detailed in the readme file at https://moodle.org/auth/shibboleth/README.txt of your Moodle site.
More information on Shibboleth can be found at http://www.internet2.edu/products-services/trust-identity-middleware/shibboleth/.
- Web services authentication: This plugin is for users who are authenticated via external clients communicating with Moodle via web services (take a look at Chapter 16, Moodle Networking for details). The authentication plugin has no settings.
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:
- No login: This plugin has no settings and cannot be disabled. Its purpose is to suspend a user from logging in to your Moodle system. This is done in the user's profile where you have to select the authentication method in the Choose an authentication method drop-down list.
- No authentication: When this method is enabled, users can create accounts without any kind of authentication or e-mail-based confirmation. It is highly recommended that you do not use this method since it creates a very insecure Moodle site, and should only be used for testing or development purposes.
Only user fields can be locked in the same way as described earlier.
- Moodle Network authentication: Moodle networking allows the connection of multiple Moodle sites in a peer-to-peer or hub style. Chapter 16, Moodle Networking has been dedicated to the details of this powerful feature.