Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Authentication.

Authentication: Difference between revisions

From MoodleDocs
m (→‎Common settings: formatting)
(Added *Uniquelogin authentication to limit users to one simultaeous session)
 
(47 intermediate revisions by 15 users not shown)
Line 1: Line 1:
==Managing user authentication==
Location: ''Administration > Users > Authentication > Manage authentication'' in 1.9


There are several ways to manage user authentication. These are called Authentication plugins and include:
Authentication is the process which allows a user to login to a Moodle site. [[Site policies]] determines if users must login before reaching the [[Front Page]].


*[[Manual accounts]]
 
*[[No login]]
==Setting the authentication method==
*[[Email-based authentication|Email-based self-registration]]
[[Image:authentication plugins.png|thumb|Choosing an authentication plugin in Moodle 1.8 (only shows top of Authentication page)]]
*[[CAS server (SSO)]]
To set the authentication method:
*[[External database authentication|External database]]
 
*[[FirstClass authentication|FirstClass server]]
#Access ''Administration > Users > Authentication > Manage authentication'' in 1.9.
*[[IMAP authentication|IMAP server]]
#On the Manage authentication page, click on the closed eye icon to enable your chosen [[Authentication|authentication plugin(s)]]. In Moodle 1.8 onwards, you can choose to use more than one authentication plugin (see Multi-authentication below). Use the up/down arrow icons to arrange the plugins in order, with the plugin handling the most logins at the top of the page.
*[[LDAP authentication|LDAP server]]
#If you have chosen [[Email-based self-registration]] in active authentication plugins section, then scroll down to the common settings section, , in the self registration drop-down menu select "Email-based self-registration". Potential users will then be presented with a "Create new account" button on the login page.
*[[Moodle Network|Moodle Network authentication]]
#If you have courses with guest access, set the Guest login button to show.
*[[NNTP authentication|NNTP server]]
#Click the "Save changes" button.
*[[No authentication]]
#Click on Settings opposite the authentication plugin(s) you have chosen.
*[[PAM (Pluggable Authentication Modules)]]
#Configure the required settings and click the "Save changes" button.
*[[POP3 server]]
 
*[[RADIUS authentication|RADIUS server]]
==Authentication methods==
*[[Shibboleth]]
 
*[[NTLM authentication|NTLM/Integrated Authentication (3rd party plugin)]]
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 authentication|External database]] - account details are located on an external database
*[[FirstClass authentication|FirstClass server]] - account details are located on an external FirstClass server
*[[IMAP authentication|IMAP server]] - account details are located on an external IMAP server
*[[LDAP authentication|LDAP server]] - account details are located on an external LDAP server
*[[MNet|Moodle Network authentication]] - how different Moodle sites can connect and authenticate users
*[[NNTP authentication|NNTP server]] - account details are located on an external NNTP 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 authentication|RADIUS server]] - account details are located on an external RADIUS server
*[[Shibboleth]] - account details are located on an external Shibboleth server
*[[NTLM authentication|NTLM/Integrated Authentication]] (contributed plugin prior to Moodle 1.9; is part of the LDAP authentication plugin from 1.9 onwards).
*[[Uniquelogin authentication]] to limit users to one simultaeous session
 
==Authentication types==
 
===Internal authentication===
This type of authentication is used when Moodle stores users' passwords and other details in local Moodle database.  Authentication plugins such as manual and email are indicate as internal authentication
 
===External authentication===
Other authentication plugins (such as: LDAP or POP3) are indicate as external authentication.  With this type of authentication, user's details are not required to be stored in local Moodle database and user's password field will be labeld as 'not cached'.


==Multi-authentication==
==Multi-authentication==
{{Moodle 1.8}}From Moodle 1.8 onwards, multi-authentication is supported. Simply click on the closed eye icon to enable a particular plugin.
From Moodle 1.8 onwards, multi-authentication is supported. Each authentication plugin may be used to find a username/password match. Once found, a user is logged in and alternative plugins are not used. Therefore the plugin which handles the most logins should be moved to the top of the page in order that less load is put on authentication servers.
 
Each authentication plugin may be used to find a username/password match. Once found, a user is logged in and alternative plugins are not used. Therefore the plugin which handles the most logins should be moved to the top of the page in order that less load is put on authentication servers.


==Common settings==
==Common settings==
Most of these settings are self-explanatory.


===Self registration===
===Self registration===
If you wish users to be able to create their own user accounts i.e. self-register then select Email-based self-registration from the drop-down menu.
 
If you wish users to be able to create their own user accounts, i.e. self-register, then select Email-based self-registration (or any other enabled plugin that can support self registration, like LDAP) from the drop-down menu. This will result in a "Is this your first time here?" instructions and a "Create new account" button being displayed on the login page.
 
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 (see below). 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 with that plugin. Selecting Email-based self-registration as the self registration method allows potential users to self register.
 
===Guest login button===
 
You can hide or show the guest login button on the login page. Hiding the guest login button disables [[Guest role|guest access]] to the Moodle site, however logged-in users can still enter any courses which allow guest access without being required to enrol.
 
===Alternate login URL===
===Alternate login URL===
This should be used with care, since a mistake in the URL or on the actual login page can lock you out of your site. If you do mess it up, you can remove the entry from your database (table mdl_config) using e.g. phpmyadmin for mysql.


==Locking profile fields==
This should be used with care, since a mistake in the URL or on the actual login page can lock you out of your site. If you do mess it up, you can remove the entry from your database (table mdl_config) using, e.g., phpmyadmin for mysql.
To prevent users from altering some fields (e.g. students changing profile information to inappropriate or misleading information), the site administrator can lock profile fields.
 
===Forgotten password URL===
 
{{Moodle 1.9}}In Moodle 1.9 onwards, if your lost password handling is performed entirely outside of Moodle (for example, only by a help desk), you can set the url of that service here. Anybody pressing a "lost password" link in Moodle will be redirected to this URL. Note that this will disable '''all''' of Moodle's lost password recovery options regardless of authentication method(s) in use.
 
===Allowed and denied email domains===
 
Authentication may be restricted to particular email domains when using [[Email-based self-registration]] so that, for example, only students with a university email can login.
 
(Note: Prior to Moodle 1.9, the allowed and denied email domains settings can be found in ''Administration > Server > [[Email settings|Email]]''.) ('It should be:- Administration > User > Manage Authentication')
 
===Restrict domains when changing email===
 
In Moodle 1.9.3 onwards, you can choose to enforce email domains only when users create an account using [[Email-based self-registration]] i.e. after creating an account, users may change their email to a different domain.
 
===ReCAPTCHA===
 
[[Image:New account form with captcha element.png|thumb|New account form with CAPTCHA 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.
 
ReCAPTCHA keys can be obtained from http://www.google.com/recaptcha by [https://www.google.com/recaptcha/admin/create signing up for an account] (free) then entering a domain. The public and private keys provided can then be copied and pasted into the ''recaptchapublickey'' and ''recaptchaprivatekey'' fields in the manage authentication common settings, and the changes saved.
 
In addition to setting reCAPTCHA keys, email-based self-registration should be set as the self registration authentication plugin in the manage authentication common settings and the reCAPTCHA element should be enabled in the [[Email-based self-registration]] settings.
 
==Profile fields data mapping and locking==
Most (but not all) authentication plugins that use an external source for the user account details allow us to retrieve some user profile details (like first name, last name, email, etc.). By using the Data Mapping section on those authentication plugins configuration page we can configure what, when and how to manage all those user profile details.


[[Image:Authent-data-map-fname.jpg|Data Mapping Options]]
[[Image:Authent-data-map-fname.jpg|Data Mapping Options]]
*These fields are optional. You can choose to pre-fill some Moodle user fields with information from the LDAP fields that you specify here.  If you leave these fields blank, then nothing will be transferred from LDAP and Moodle defaults will be used instead.  In either case, the user will be able to edit all of these fields after they log in.
*'''Update local''': If enabled, the field will be updated (from external auth) every time the user logs in or there is a user synchronization. Fields set to update locally should be locked.
*'''Lock value''': If enabled, will prevent Moodle users and admins from editing the field directly. Use this option if you are maintaining this data in the external auth system.
*'''Update external''': If enabled, the external auth will be updated when the user record is updated. Fields should be unlocked to allow edits.  Note: Updating external LDAP data requires that you set '''binddn''' and '''bindpw''' to a bind-user with editing privileges to all the user records. It currently does not preserve multi-valued attributes, and will remove extra values on update.


If you are using a mixture of authentication types (such as IMAP and manual), then the fields you lock in the authentication options will only apply to the type of authentication indicated by the drop down box at the top of the screen. Remember to test the field locking by logging in with the proper type of account!  If you test with a manual account but have set the field locking to apply to IMAP accounts, you will not be able to tell if it worked!
These fields are optional. You can choose to pre-fill some Moodle user fields with information from the external authentication source (if you are using one), from the fields that you specify here. If you leave these fields blank, then nothing will be transferred from the external authentication source and Moodle defaults will be used instead. In either case, the user will be able to edit all of these fields after they log in.
 
In addition to specifying how to fill this fields, we can set how to update them (in both directions, to Moodle or from Moodle), and whether we want to lock them (so the user cannot modify their value) or not:
 
*'''Update local''': When the user field will be updated from the external authentication source:
** '''On creation''': when the user account is created during the first login
** '''On every login''': every time the user logs in (or there is a user synchronization, for those authentication plugins that support it). Fields set to update locally should be locked.
*'''Update external''': When the external authentication source will be updated from the user field:
** '''Never''': never update the external authentication source from Moodle.
** '''On update''': the external authentication source will be updated when the user profile is updated. Fields should be unlocked to allow edits.
*'''Lock value''': To prevent users from altering some fields (e.g. students changing profile information to inappropriate or misleading information), the site administrator can lock profile fields. It's usually a good idea to lock profile fields if you are maintaining this data in the external authentication system.
** '''Unlocked''': The field is unlocked and can be edited by the user at any time.
** '''Unlocked if empty''': The field is unlocked if it is empty, but once the user fills in some information, it becomes locked and cannot be edited any more.
** '''Locked''': The field is locked and cannot be edited by the user.
 
If you are using a mixture of authentication types (such as IMAP and manual), then the fields you map and lock in the authentication options are specific to that particular authentication plugin. Each authentication plugin has its own set of mapped and locked fields.
 
Remember to test the field locking by logging in with the proper type of account!  If you test with a manual account but have set the field locking to apply to IMAP accounts, you will not be able to tell if it worked!


==See also==
==See also==
*[[Authentication FAQ]]
*Multi authentication in [[Upgrading to Moodle 1.8]]
*Multi authentication in [[Upgrading to Moodle 1.8]]
*[http://moodle.org/mod/forum/view.php?id=42 Using Moodle: User authentication] forum
*Using Moodle [http://moodle.org/mod/forum/view.php?id=42 User authentication forum]
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=95559 Do users need e-mail addresses?] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=97938 Admin approving self registrations?] forum discussion


[[Category:Authentication]]
[[Category:Authentication]]


[[eu:Erabiltzaileen_autentifikazioa]]
[[fr:Authentification]]
[[fr:Authentification]]
[[de:Authentifizierung]]
[[ja:認証]]

Latest revision as of 17:56, 16 April 2016

Location: Administration > Users > Authentication > Manage authentication in 1.9

Authentication is the process which allows a user to login to a Moodle site. Site policies determines if users must login before reaching the Front Page.


Setting the authentication method

Choosing an authentication plugin in Moodle 1.8 (only shows top of Authentication page)

To set the authentication method:

  1. Access Administration > Users > Authentication > Manage authentication in 1.9.
  2. On the Manage authentication page, click on the closed eye icon to enable your chosen authentication plugin(s). In Moodle 1.8 onwards, you can choose to use more than one authentication plugin (see Multi-authentication below). Use the up/down arrow icons to arrange the plugins in order, with the plugin handling the most logins at the top of the page.
  3. If you have chosen Email-based self-registration in active authentication plugins section, then scroll down to the common settings section, , in the self registration drop-down menu select "Email-based self-registration". Potential users will then be presented with a "Create new account" button on the login page.
  4. If you have courses with guest access, set the Guest login button to show.
  5. Click the "Save changes" button.
  6. Click on Settings opposite the authentication plugin(s) you have chosen.
  7. Configure the required settings and click the "Save changes" button.

Authentication methods

Authentication methods (also known as authentication plugins) include:

Authentication types

Internal authentication

This type of authentication is used when Moodle stores users' passwords and other details in local Moodle database. Authentication plugins such as manual and email are indicate as internal authentication

External authentication

Other authentication plugins (such as: LDAP or POP3) are indicate as external authentication. With this type of authentication, user's details are not required to be stored in local Moodle database and user's password field will be labeld as 'not cached'.

Multi-authentication

From Moodle 1.8 onwards, multi-authentication is supported. Each authentication plugin may be used to find a username/password match. Once found, a user is logged in and alternative plugins are not used. Therefore the plugin which handles the most logins should be moved to the top of the page in order that less load is put on authentication servers.

Common settings

Self registration

If you wish users to be able to create their own user accounts, i.e. self-register, then select Email-based self-registration (or any other enabled plugin that can support self registration, like LDAP) from the drop-down menu. This will result in a "Is this your first time here?" instructions and a "Create new account" button being displayed on the login page.

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 (see below). 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 with that plugin. Selecting Email-based self-registration as the self registration method allows potential users to self register.

Guest login button

You can hide or show the guest login button on the login page. Hiding the guest login button disables guest access to the Moodle site, however logged-in users can still enter any courses which allow guest access without being required to enrol.

Alternate login URL

This should be used with care, since a mistake in the URL or on the actual login page can lock you out of your site. If you do mess it up, you can remove the entry from your database (table mdl_config) using, e.g., phpmyadmin for mysql.

Forgotten password URL

Moodle1.9

In Moodle 1.9 onwards, if your lost password handling is performed entirely outside of Moodle (for example, only by a help desk), you can set the url of that service here. Anybody pressing a "lost password" link in Moodle will be redirected to this URL. Note that this will disable all of Moodle's lost password recovery options regardless of authentication method(s) in use.

Allowed and denied email domains

Authentication may be restricted to particular email domains when using Email-based self-registration so that, for example, only students with a university email can login.

(Note: Prior to Moodle 1.9, the allowed and denied email domains settings can be found in Administration > Server > Email.) ('It should be:- Administration > User > Manage Authentication')

Restrict domains when changing email

In Moodle 1.9.3 onwards, you can choose to enforce email domains only when users create an account using Email-based self-registration i.e. after creating an account, users may change their email to a different domain.

ReCAPTCHA

New account form with CAPTCHA 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.

ReCAPTCHA keys can be obtained from http://www.google.com/recaptcha by signing up for an account (free) then entering a domain. The public and private keys provided can then be copied and pasted into the recaptchapublickey and recaptchaprivatekey fields in the manage authentication common settings, and the changes saved.

In addition to setting reCAPTCHA keys, email-based self-registration should be set as the self registration authentication plugin in the manage authentication common settings and the reCAPTCHA element should be enabled in the Email-based self-registration settings.

Profile fields data mapping and locking

Most (but not all) authentication plugins that use an external source for the user account details allow us to retrieve some user profile details (like first name, last name, email, etc.). By using the Data Mapping section on those authentication plugins configuration page we can configure what, when and how to manage all those user profile details.

Data Mapping Options

These fields are optional. You can choose to pre-fill some Moodle user fields with information from the external authentication source (if you are using one), from the fields that you specify here. If you leave these fields blank, then nothing will be transferred from the external authentication source and Moodle defaults will be used instead. In either case, the user will be able to edit all of these fields after they log in.

In addition to specifying how to fill this fields, we can set how to update them (in both directions, to Moodle or from Moodle), and whether we want to lock them (so the user cannot modify their value) or not:

  • Update local: When the user field will be updated from the external authentication source:
    • On creation: when the user account is created during the first login
    • On every login: every time the user logs in (or there is a user synchronization, for those authentication plugins that support it). Fields set to update locally should be locked.
  • Update external: When the external authentication source will be updated from the user field:
    • Never: never update the external authentication source from Moodle.
    • On update: the external authentication source will be updated when the user profile is updated. Fields should be unlocked to allow edits.
  • Lock value: To prevent users from altering some fields (e.g. students changing profile information to inappropriate or misleading information), the site administrator can lock profile fields. It's usually a good idea to lock profile fields if you are maintaining this data in the external authentication system.
    • Unlocked: The field is unlocked and can be edited by the user at any time.
    • Unlocked if empty: The field is unlocked if it is empty, but once the user fills in some information, it becomes locked and cannot be edited any more.
    • Locked: The field is locked and cannot be edited by the user.

If you are using a mixture of authentication types (such as IMAP and manual), then the fields you map and lock in the authentication options are specific to that particular authentication plugin. Each authentication plugin has its own set of mapped and locked fields.

Remember to test the field locking by logging in with the proper type of account! If you test with a manual account but have set the field locking to apply to IMAP accounts, you will not be able to tell if it worked!

See also