forked from moodle/moodle
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.txt
180 lines (114 loc) · 5.45 KB
/
README.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
This directory contains authentication modules.
Each of these modules describes a different way to
check that a user has provided a correct
- username, and
- password.
Even when external forms of authentication are being used, Moodle still
maintains the internal "user" table with all the associated information about
that user such as name, email address and so on.
Multiauthentication in Moodle 1.8
-------------------------------------
The active methods are set by the admin on the Configuration page. Multiple
authentication plugins can now be used and ordered in a fail-through sequence.
One plugin can be selected for interactive login as well (which will need to be
part of the enabled plugin sequence).
email - authentication by email (DEFAULT METHOD)
- user fills out form with email address
- email sent to user with link
- user clicks on link in email to confirm
- user account is created
- user can log in
none - no authentication at all .. very insecure!!
- user logs in using ANY username and password
- if the username doesn't already exist then
a new account is created
- when user tries to access a course they
are forced to set up their account details
nologin - user can not log in, login as is possible
- this plugin can be used to prevent normal user login
manual - internal authentication only
- user logs in using username and password
- no way for user to make their own account
ldap - Uses an external LDAP server
- user logs in using username and password
- these are checked against an LDAP server
- if correct, user is logged in
- optionally, info is copied from the LDAP
database to the Moodle user database
(see the ldap/README for more details on config etc...)
imap - Uses an external IMAP server
- user logs in using username and password
- these are checked against an IMAP server
- if correct, user is logged in
- if the username doesn't already exist then
a new account is created
pop3 - Uses an external POP3 server
- user logs in using username and password
- these are checked against a POP3 server
- if correct, user is logged in
- if the username doesn't already exist then
a new account is created
nntp - Uses an external NNTP server
- user logs in using username and password
- these are checked against an NNTP server
- if correct, user is logged in
- if the username doesn't already exist then
a new account is created
db - Uses an external database to check username/password
- user logs in using username and password
- these are checked against an external database
- if correct, user is logged in
- if the username doesn't already exist then
a new Moodle account is created
--------------------------------------------------------------------------------
Authentication API
------------------
AUTHENTICATION PLUGINS
----------------------
Each authentication plugin is now contained in a subfolder as a class definition
in the auth.php file. For instance, the LDAP authentication plugin is the class
called auth_plugin_ldap defined in:
/auth/ldap/auth.php
To instantiate the class, there is a function in lib/moodlelib called
get_auth_plugin() that does the work for you:
$ldapauth = get_auth_plugin('ldap');
Auth plugin classes are pretty basic and should be extending auth_plugin_base class.
They contain the same functions that were previously in each plugin's lib.php file,
but refactored to become class methods, and tweaked to reference the plugin's instantiated
config to get at the settings, rather than the global $CFG variable.
When creating new plugins you can either extend the abstract auth_plugin_base class
(defined in lib/authlib.php) or create a new one and implement all methods from
auth_plugin_base.
The new plugin architecture allows creating of more advanced types such as custom SSO
without the need to patch login and logout pages (see *_hook() methods in existing plugins).
Configuration
-----------------
All auth plugins must have a config property that contains the name value pairs
from the config_plugins table. This is populated using the get_config() function
in the constructor. The settings keys have also had the "auth_" prefix, as well
as the auth plugin name, trimmed. For instance, what used to be
echo $CFG->auth_ldapversion;
is now accessed as
echo $ldapauth->config->version;
Authentication settings have been moved to the config_plugins database table,
with the plugin field set to "auth/foo" (for instance, "auth/ldap").
Method Names
-----------------
When the functions from lib.php were ported to methods in auth.php, the "auth_"
prefix was dropped. For instance, calls to
auth_user_login($user, $pass);
now become
$ldapauth->user_login($user, $pass);
this also avoids having to worry about which auth/lib file to include since
Moodle takes care of it for you when you create an instance with
get_auth_plugin().
The basic class defines all applicable methods that moodle uses, you can find
more information in lib/authlib.php file.
Upgrading from Moodle 1.7
-----------------------------
Moodle will upgrade the old auth settings (in $CFG->auth_foobar where foo is the
auth plugin and bar is the setting) to the new style in the config_plugin
database table.
Upgrading from Moodle 1.8
------------------------------
user_activate() method was removed from public API because it was used only from user_confirm() in LDAP