Authentication
Authentication
Location: Administration > Users > Authentication
User authentication is about enabling people to login to your Moodle site.
Authentication methods
Authentication methods (also known as authentication plugins) include:
- Manual accounts – accounts created manually by an administrator
- No login – suspend particular user account
- Email-based self-registration – for enabling users to create their own accounts
- CAS server (SSO) – account details are located on an external CAS server
- External database – account details are located on an external database
- FirstClass server – account details are located on an external FirstClass server
- IMAP server – account details are located on an external IMAP server
- LDAP server – account details are located on an external LDAP server
- Moodle Network authentication – how different Moodle sites can connect and authenticate users
- NNTP server – account details are located on an external NTTP server
- No authentication – for testing purposes only
- PAM (Pluggable Authentication Modules) – account details come from the operating system Moodle is running on, via PAM (can only be used Linux/Unix).
- POP3 server – account details are located on an external POP3 server
- RADIUS server – account details are located on an external RADIUS server
- Shibboleth – account details are located on an external Shibboleth server
- NTLM/Integrated Authentication (contributed plugin prior to Moodle 1.9; is part of the LDAP authentication plugin from 1.9 onwards).
The authentication method is set in Administration > Users > Authentication > Manage authentication (or Administration > Users > Authentication prior to Moodle 1.9)
Manual accounts
Location: Administration > Users > Authentication >Manage Authentication
This authentication method requires the administrator to manually create all user accounts. It may be used together with the upload users tool (Admin>User>Accounts) which uses a text file.
No login
Location: Settings link in Administration > Users >Browser User > Profile
An administrator may “turn off” a user’s account by selecting “No Login” in the “Choose an authentication method setting” in the users profile in edit mode. This may need to be revealed with the “Show Advanced” button and the changes saved.
Different users have to have unique email addresses in their profile, even when email is not enabled. When the “No Login” setting is used, the account email may not be re-used to create another account. This essentially is a way to bar a particular user account from using Moodle for the duration that the account is assigned to this authentication type.
Email-based self-registration
Location: Settings link in Administration > Users > Authentication > Manage authentication
This authentication method enables users to create their own accounts if email-based self-registration is selected from the self registration drop-down menu in the common settings section on the manage authentication page. They then receive an email at the address they specified in their account profile to confirm their account.
Warning: Enabling self registration results in the possibility of spammers creating accounts in order to use forum posts, blog entries etc. for spam. This risk can be minimized by limiting self registration to particular email domains with the allowed email domains setting in Administration > Users > Authentication > Manage authentication (or in Administration > Server > Email prior to Moodle 1.9). Alternatively, self registration may be enabled for a short period of time to allow users to create accounts, and then later disabled.
Note: The Email-based self-registration authentication plugin must be enabled to allow users who previously self-registered to login. Selecting Email-based self-registration as the self registration method allows potential users to self register.
Enable reCAPTCHA element
A CAPTCHA is a program that can tell whether its user is a human or a computer. CAPTCHAs are used by many websites to prevent abuse from bots, or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs.
From Moodle 1.9.1 onwards, spam protection may be added to the email-based self-registration new account form with a CAPTCHA element – a challenge-response test used to determine whether the user is human.
In addition to enabling the reCAPTCHA element, email-based self-registration should be set as the self registration authentication plugin and reCAPTCHA keys should be set in the manage authentication common settings.
CAS server (SSO)
Location: Settings link in Administration > Users > Authentication
Overview
CAS is “Single Sign-on for the Web” and is developed by JA-SIG in an open-source, collaborative manner. CAS is very beneficial in environments where a number of different web applications share a set of common users. If all the web applications were “CASified” a user would log in once and would then be able to move between the various web applications without ever having to present authentication credentials again. CAS is similar to the Shibboleth authentication mechanism, but it is vastly simpler to set up and lacks a number of broader features like federated trust and authorization infrastructure.
The details for how CAS works are well documented, but CAS essentially works by configuring a web application (moodle.example.com) to not do authentication itself, but to instead forward unauthenticated users to a “CAS Server” (cas.example.com) which will then return an authentication token to the original web application (moodle.example.com). Moodle can extract the username from the token and then use its internal authorization mechanisms (roles, enrollments, capabilities) and user attributes (name, picture, etc.). The advantage is that the moodle.example.com service never has to handle passwords and that users, once they’ve authenticated the first time, can move seamlessly to another web application without having to present their credentials again.
Configuration
Assuming that you already have a working CAS server, configuration is fairly straightforward through the web interface.
One caveat for those converting from LDAP or other authentication mechanisms:
- For any user that you wish to authenticate with CAS but which already has been using Moodle, and thus has an entry in the Moodle database, you will need to change the value of the “auth” field for the user in the mdl_user table. So, if they used LDAP before, but now you wish for them to use CAS and their username is “foobar” you’ll need to edit the database with some SQL something like:
UPDATE mdl_user SET auth='cas' where auth='ldap' and username='foobar';Without this change the user will constantly be presented with a failed login message, but otherwise no clue as to why login failed even though their credentials were accepted by the CAS server.
External database authentication
Location: Settings link in Administration > Users > Authentication
This method uses an external database table to check whether a given username and password is valid. If the account is a new one, then information from other fields may also be copied across into Moodle.
This is done by mapping fields at the bottom of the database authentication page. Each data field in the user profile has a text field next to it. Enter the name of the column in the external database that maps to the profile data field.
Update Local – Specifies that the external data will be entered into the local field in question
- On Creation – specifies that this will only happen on the original login when the account is created for the first time.
- On Every Login – specifies that changes in the external data will be updated on the local Moodle field in question the next time the user logs in again.
Update External – Specifies just the opposite, meaning changes in the local Moodle field in question will update the corresponding field in the external database
- Never – Specifies this is disabled
- On Update – Enables this to happen if a change is made locally (additional configuration is probably required)
Lock Value – Only determines whether the local user can make a change in the Moodle field and does not affect the two settings above.
- Unlocked – A user can make changes locally in the Moodle field (assumably even if it contradicts the external database the next login would change it again if Update Local is set
- Locked – A user can never make changes
- Unlocked if empty – A user can only make changes if the field is not populated already from the external database (this would seem to indicate a user could only enter something into this field once and could not change it after saving)
Additional Notes
- Some of the things that apply to Upload users apply to the External database
- Set password to “changeme” to force password reset
- If you do this, it is critical that you provide a URL to change the password!
- Set password to “changeme” to force password reset
- Not all of the fields in the Upload users are available for the External Database authentication. The only available fields are the fields listed in the data mapping section of the admin page for the External Database connection.
FirstClass authentication
Location: Settings link in Administration > Users > Authentication
FirstClass is a client/server groupware, email, online conferencing, voice/fax services, and bulletin-board system for Windows, Macintosh, and Linux. FirstClass authentication uses the FirstClass Server for the authentication process i.e. to check for user accounts.
IMAP authentication
Location: Settings link in Administration > Users > Authentication
IMAP authentication uses a mailing systems IMAP protocol to check for users accounts. This allows direct integrations with technologies such as Microsoft Exchange servers.
LDAP authentication
Location: Settings link in Administration > Users > Authentication > LDAP Server
This document describes how to set up Lightweight Directory Access Protocol (LDAP) authentication in Moodle. We cover the basic, advanced and some trouble shooting sections to assist the user in the installation and administrating LDAP in Moodle.
Moodle Network
Overview
Moodle Network is a new feature found in the 1.8 release of Moodle. The network feature allows a Moodle administrator to establish a link with another Moodle, and to share some resources with the users of that Moodle.
The initial release of Moodle Network is bundled with a new Authentication Plugin, which makes single-sign-on between Moodles possible. A user with the username jody logs in to her Moodle server as normal, and clicks on a link that takes her to a page on another Moodle server. Normally, she would have only the privileges of a guest on the remote Moodle, but behind the scenes, single-sign-on has established a fully authenticated session for Jody on the remote site.
WARNING: Moodle Networking requires the use of xmlrpc. Please go to your phpinfo page if you are interested in using this and search for –with-xmlrpc. If your php has not been compiled with xmlrpc then you need to address that first! At present it appears that PEAR xmlrpc will not work.
Security
The Moodle network feature requires that your server has the Curl and OpenSSL extensions installed. When you install or upgrade to Moodle 1.8, your system will generate a new OpenSSL certificate for encrypted communication with other Moodles, and will thereafter rotate encryption keys on a monthly basis (approx).
Communication takes place over an XML-RPC transport, and the XML-RPC documents are wrapped first in an XMLDSIG (XML digital signature) envelope, and then in an XMLENC (XML encryption) envelope. The encryption all happens within PHP, and does not require an https (Apache SSL) server.
References:
A special mode can be enabled which would allow a machine with a specified IP address to make calls to the XML-RPC layer without using either encryption or signature envelopes. This mode is provided to enable Moodle to communicate with other software systems in which the integration of signatures and encryption might be prohibitively difficult. It is not envisioned that unencrypted inter-Moodle networking will ever be enabled.
Peer to Peer Network
This is the basic layout of the system. It can be very useful to run one Moodle per faculty or departments, each with its own user management, and yet permit users to roam across the Moodle installs… subject to permissions of course.
Setup
The instructions will cover 2 Moodle installations: MoodleA and MoodleB. Both are installed correctly and have never had a Moodle Network configuration.
Note: If you experience problems, ensure debugging is turned on in Site Administration > Server > Debugging. Extra diagnostic messages may be displayed (particularly from Moodle 1.9.2)
- Get them to talk to each other
- Ensure Admin > Server > Environment indicates you have curl installed
- If MoodleA and MoodleB are hosted in the same domain, ensure they have a different cookie prefix. Note that changing the cookie prefix will log you out! You can change the cookie prefix via Admin > Server > Session Handling.
- On both, go to Admin > Network > Settings and turn Networking ON.
- On MoodleA go to Admin > Network > Peers – put the URL of MoodleB under “Add New Host” and click Add.
- Do the equivalent on MoodleB.
- Get user roaming going
- On both, go to Admin > Users > Authentication and enable Moodle Network authentication plugin. Click on ‘Settings’ and enable auto_add_remote_users.
- On MoodleA go to Admin > Network > Peers, click on ‘MoodleB’, and click on ‘Services’. Enable SSO-IDP publish and subscribe, and SSO-SP publish and subscribe.
- Do the equivalent on MoodleB.
- On both, go to Admin > Users > Permissions > Define Roles, only roles that have “Roam to a remote Moodle moodle/site:mnetlogintoremote” will be allowed to roam. Grant the privilege as appropriate.
- On both, go to the homepage, and add the ‘Network Servers’ block.
- To test, it is recommended to use a different browser (even on a different machine) that is logged in to neither. Login to MoodleA with a non-administrator account that has the permissions to roam. You should see the Network Servers block, and clicking on it you should go to MoodleB with a newly autocreated account.
- Get remote enrolments going — this is optional. It allows administrator of MoodleB can enrol users that are “native” to MoodleB in courses in MoodleA, and viceversa.
- On both, go to Admin > Courses > Enrolment and enable Moodle Network enrolment plugin (click Save). Click on ‘Edit’ and enable ‘allow_allcourses’ or select some courses or categories to be remotely enrolled.
- On MoodleA go to Admin > Network > Peers, click on ‘MoodleB’, and click on ‘Services’. Enable Enrolment publish and subscribe.
- Do the equivalent on MoodleB.
- To use, in MoodleA go to Admin > Networking > Enrolments. You will see MoodleB listed. Click on MoodleB and you will see a list of courses that MoodleB offers for remote enrolment. Select the course you want, and then enroll the users you want to that course.
Connecting to a Community hub
A Community hub is a Moodle server that is configured to accept connections from other Moodle servers, and to provide a set of services to users of these other servers. This guideline will direct you to connect to a Community hub, assess the services it has to offer, and enable those services for your users.
Setup
- Get talking to the Hub
- Ensure that the Admin > Server > Environment page indicates you have curl and openssl installed
- Go to Admin > Network > Settings and turn Networking on
- Go to Admin > Network > Peers and enter the URL of Community Hub under “Add New Host”. Click Add
- The host details for the Community Hub should appear with the Site Name field already populated. Click Save changes
- The details will be written to your database and two new tabs will appear in this window: ‘Services’ and ‘Logs’. Click Services
- A list of services will appear, each with a checkbox for ‘publish’ and ‘subscribe’. Check the checkboxes for any services you want to publish or subscribe to
Using it
If the Community Hub has already enabled a service for you, there will be a tick alongside the appropriate checkbox, for example: if the Hub is publishing Moodle Networked Enrolment, then a tick will appear alongside the subscribe checkbox for this service. Note that in order to enable some functionality, prominently single-sign-on, you may have to publish a service, e.g. the Identity Provider service. The Community Hub will access this service on your Moodle, asking it to authenticate your users.
- Enable Roaming
- Subscribe to SSO (Service Provider) by checking the box
- Publish SSO (Identity Provider) by checking the box
- Click Save changes
- Go to Admin > Users > Permissions > Define Roles, and grant the capability Roam to a remote Moodle moodle/site:mnetlogintoremote to an appropriate role
- Go to Admin > Users > Authentication and enable the Moodle Network authentication plugin
- Go to your homepage, turn on editing, and add the ‘Network Servers’ block
- Using a different web-browser, log on as a non-admin user who inhabits the role you granted the roaming capability to
- Note that the Community Hub is listed in the Network Servers block on the homepage. Click on the link to that server
- Some of your user details will be transferred to the Community Hub server, and a browsing session will be started for you as if you had logged on there directly
- Enable Networked Enrolment
- Return to the web browser you’ve been using as the site administrator
- Go to Admin > Network > Peers and click on the entry for the Community Hub.
- Click on the Services tab
- Subscribe to Moodle Networked Enrolment
- Go to Admin > Courses > Enrolment and enable the Moodle Network enrolment plugin. Click Save changes
- Click on edit to view the details for networked enrolments.
- Go to Admin > Networking > Enrolments to see a list of Moodle servers that offer this service to you
- Click on a server name to view a list of courses that the server offers to your users
- Click on a course name, to view a list users that you can enrol in this course
- Enrol users
- Profit!
Running a Community hub
A Community hub is a regular Moodle site that runs in a special mode. As a Moodle Administrator, when you add another Moodle site to your list of network peers, your Moodle will contact that site to find out what it is called, and to request its public key for encrypted communication. Normally, the remote server will simply provide this information without making any record of the transaction.
A Community hub is different. As soon as you add an entry for a Community hub to your system, the Community hub will create an entry for your server in its list of hosts, and may immediately begin to offer services to the users of your site.
This section will guide you to set up a Community hub, and select services to offer to all comers.
Setup
- Enable Networking
- Ensure that the Admin > Server > Environment page indicates you have curl and openssl installed
- Go to Admin > Network > Settings and turn Networking on
- Go to Admin > Network > Peers and tick the checkbox for Register all hosts. Click on Save Changes
- On the same page, the first entry in your list of hosts should be All hosts. Click this link
- Click on Services and enable any services you want to offer to all comers
NNTP authentication
Location: Settings link in Administration > Users > Authentication
NNTP authentication uses the Usenet NNTP protocol to check for users accounts. This allows direct integration with technologies such as Microsoft Exchange, INN, DNews, Diablo, etc.
No authentication
Location: Settings link in Administration > Users > Authentication
With the “No Authentication” method enabled, a user can create an account without any kind of authentication from other systems, and with no email-based confirmation that the email address that they have provided is valid, or even exists!
This is a good way to create a very insecure Moodle site, and is not recommended.
This is an option that would normally be used only for testing purposes.
The configuration page for this option only offers the ability to lock fields, enable or disable guest access, and provide an alternative login page, in the same way as other authentication plugins.
PAM (Pluggable Authentication Modules)
Location: Settings link in Administration > Users > Authentication
This method uses PAM to access the native usernames on this server. You have to install PHP4 PAM Authentication in order to use this module.
POP3 server authentication
Location: POP3 server settings link in Administration > Users > Authentication
POP3 servers
POP stands for Post Office Protocol. This is used to describe how e-mail clients interact with mail servers. The POP3 server is a type of mail server used for incoming mail. In simple terms, POP servers provide a mail-drop service (a temporary mailbox to leave messages so they can be picked up at the recipient’s convenience.) When users connect to their ISP POP servers, their e-mail software interface with the server and download any messages for them. POP is only used to receive messages, it is not used to send them. In computing, local e-mail clients use the Post Office Protocol version 3 (POP3), an application-layer Internet standard protocol, to retrieve e-mail from a remote server over a TCP/IP connection. Many subscribers to individual Internet service provider e-mail accounts access their e-mail with client software that uses POP3.
POP3 server authentication
POP3 server authentication is a user authentication process i.e. enabling people to login to your Moodle site.
This method uses the POP3 mail server for the authentication process ie. check for users accounts.
Shibboleth
Location: Settings link in Administration > Users > Authentication
Shibboleth is an Internet2 Middleware Initiative project that has created an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure based on SAML. Federated identity allows for information about users in one security domain to be provided to other organizations in a common federation. This allows for cross-domain single sign-on and removes the need for content providers to maintain usernames and passwords. Identity providers (IdP’s) supply user information, while service providers (SP’s) consume this information and gate access to secure content.
Configuring Moodle to use Shibboleth
The README.txt file in the auth/shibboleth folder of your Moodle distribution contains set-up instructions.
Shibboleth in the UK
In the UK Becta and JISC have implemented an education federation using Shibboleth to provide single sign on. This means that education establishments in the UK using Moodle should be able to authenticate their users via Shibboleth IF their education organisation joins the UK Access Management Federation and their users’ identity is held by the identity provider the LA/RBC use. For maintained schools in the England and Wales this will probably mean contacting their Local Authority or Regional Broadband Consortium (RBC). A list of current UK federation members can be found here.