Hi there,
As part of the Moodle Community Hub project, I have been working here at Catalyst on getting Moodle to support multiple authentication plugins. There is an earlier thread over on the User Authentication forum.
The code was worked on in a 1.6 branch and has now been rebased to the 1.7 code. There is a git repository here, and tarball snapshots are also available if you are not using git/cogito.
Any suggestions/test reports/encouragement/withering criticisms etc. would be greatly appreciated.
NOTES:
The authentication admin interface has changed, and now resembles the Filters interface in that you can enable, disable and reorder each auth plugin, each of which has its own settings page.
The auth plugins are now classes, instantiated with a get_auth_plugin() function in lib/moodlelib, and all the functions that were in lib.php have been refactored as class methods. The auth plugin settings are now stored in the mdl_config_plugins table (along with the field locking options) keyed by the plugin field = 'auth/foo'. These settings are accessible through the class ->config variable, which is populated in the constructor at instantiation time. Thus $CFG->auth_foo_setting has been replaced by $authplugin->config->setting, where $authplugin = get_auth_plugin('foo')
More notes as they come to mind... All feedback welcome!
Cheers,
Jonathan
I'll give it a go this weekend 
Saludos. Iñaki.
Saludos. Iñaki.
Hi Johnathan
I have been reading all the posts on making Moodle capable of using Multiple Authentication methods as I have been asked to get one of our Moodle installs authenticating using Manual accounts and using LDAP auth as a fallback.
I believe your mods will allow this?
If so how much more work is required to get it to a level that can be used in a production site? I have been allocated time to get this working and I would rather spend it on mods that will make it back in to the main Moodle code as opposed to hacking it together. Is there any help I can offer in terms of coding or testing?
I have downloaded the Source Tree versions from
http://git.catalyst.net.nz/gitweb?p=moodle-r2.git;a=snapshot;h=mdl-mnet-multiauth
But am getting errors about files not existing, looks like the setup.php in /lib is missing from the snap shot. I havent used GIT before but am willing to if it will get me the best snapshot.
Here to assist to get to production level
Richard
I have been reading all the posts on making Moodle capable of using Multiple Authentication methods as I have been asked to get one of our Moodle installs authenticating using Manual accounts and using LDAP auth as a fallback.
I believe your mods will allow this?
If so how much more work is required to get it to a level that can be used in a production site? I have been allocated time to get this working and I would rather spend it on mods that will make it back in to the main Moodle code as opposed to hacking it together. Is there any help I can offer in terms of coding or testing?
I have downloaded the Source Tree versions from
http://git.catalyst.net.nz/gitweb?p=moodle-r2.git;a=snapshot;h=mdl-mnet-multiauth
But am getting errors about files not existing, looks like the setup.php in /lib is missing from the snap shot. I havent used GIT before but am willing to if it will get me the best snapshot.
Here to assist to get to production level
Richard
[...] authenticating using Manual accounts and using LDAP auth as a fallback. I believe your mods will allow this?
If I understand you right, you want the same users being authenticated by two different authentication backends. Right?
If this is so, the multiauth code won't allow you to do this, as Moodle asumes that a given user has only one authentication source at a time. So you can't have a user use manual authentication and LDAP authentication, not even as a fallback.
What the multiauth code allows for is having different users use different authentication sources simultaneously.
Saludos. Iñaki.
Hi Inaki
No sorry I may have not described what I need correctly. I need some users to be manually authenticated and other authenticated by LDAP. But ideally I'd like the first method of authentication to be Manual and if that fails, ie because the user does not exist in the Manual database Moodle performs an LDAP lookup.
Are you saying that you would have to pre populate the local users database and then assign each user to an authentication method?
Thanks
Richard
No sorry I may have not described what I need correctly. I need some users to be manually authenticated and other authenticated by LDAP. But ideally I'd like the first method of authentication to be Manual and if that fails, ie because the user does not exist in the Manual database Moodle performs an LDAP lookup.
Are you saying that you would have to pre populate the local users database and then assign each user to an authentication method?
Thanks
Richard
Richard, what you are describing will work with 1.8 out-of-the-box. That's exactly the scenario we wrote it for
You don't need to prepopulate the database.
You don't need to prepopulate the database.
Hi Martin
Fantatsic I will get 1.8 our beta site and test the authentication.
Richard
Fantatsic I will get 1.8 our beta site and test the authentication.
Richard
In reply to Iñaki Arenaza
Re: Multiple Authentication - Unreliable LDAP and fallback
by Martín Langhoff -
Iñaki, going off on a tangent here -- do you think it'd be interesting to have a patch that allows a special "unreliable LDAP server" mode in which auth/ldap...
- connects to LDAP with a very short timeout, so if the LDAP server is down or bogged down it'll return an error without much delay
- (optional) if the connect fails try connecting to a secondary LDAP server, again with a short timeout
- if all LDAP connections fail AND the user acct actually exists AND we have a hashed passwd for the user, then validate against the hashed passwd
(Personally, my LDAP servers are rock-solid and if not, I'll fix them
but I've seen people discuss this "unreliable LDAP" scenario time and again, and I don't think it is that hard to do a bit of failover at login time. All the other operations that touch the LDAP server won't really work, so things won't be 100% operational, but those are seldom used anyway.)
- connects to LDAP with a very short timeout, so if the LDAP server is down or bogged down it'll return an error without much delay
- (optional) if the connect fails try connecting to a secondary LDAP server, again with a short timeout
- if all LDAP connections fail AND the user acct actually exists AND we have a hashed passwd for the user, then validate against the hashed passwd
(Personally, my LDAP servers are rock-solid and if not, I'll fix them
In reply to Martín Langhoff
Re: Multiple Authentication - Unreliable LDAP and fallback
by Iñaki Arenaza -
do you think it'd be interesting to have a patch that allows [...]
Interesting yes. Possible no
There is currently no way to specify a timeout in ldap_connect() or ldap_bind() in PHP, so unless you patch the PHP LDAP module (nothing too complicated, AFAICT), you are out of luck.
And I'm still waiting for the PHP people to take my patch on paged results, so I wouln't hold my breath with this either...
Saludos. Iñaki.
In reply to Iñaki Arenaza
Re: Multiple Authentication - Unreliable LDAP and fallback
by Martín Langhoff -
Damn! I keep forgetting -- I made the same mistake in this same thread! I'm waaaay too used to the Perl's Net::LDAP libraries and I map what I use there to PHP. 
From reading a bit, LDAP_OPT_TIMELIMIT should do it, but it seems you only get to set it once you've established the connection. WTF!?
From reading a bit, LDAP_OPT_TIMELIMIT should do it, but it seems you only get to set it once you've established the connection. WTF!?
By the way, ignore all the multi-auth code from git.catalyst.net.nz -- the latest and greatest code for this is in the 1.8 beta. It's graduated to almost-production ready, so please tell us it works for you too
Go 1.8 GO!
Go 1.8 GO!
BTW I am about to commit a large auth cleanup patch into HEAD and 1.8dev tomorrow
Great! Can you split it into separate commits detailing what they are cleaning up? Big "this is a biiig pile of fixes" commits make life hard...
In 1.8 why can't you specify the domains allowed to register and barred from registering in email authentication - you could do this in 1.7
J.
J.
Do you mean following the example in config-dist.php or under /admin somewhere? Tell us more... (a lot more) so we can understand.
Sorry about the lack of detail. I can't see anything in config-dist.php in the latest CSV.
In admin under 1.7 (sorry I upgraded to 1.8 so I don't have a 1.7 install to refer to). There was an option to specify:
- domains for email authentication where a user when registering could only have an email address with e.g. .sch.uk or .gov.uk or school.area.sch.uk as we have in the UK.
- domains for email authentication which were banned
In 1.8 there is no option to either have a permit or deny list of domains for email authentication (unless I am missing something).
all the best
James
In admin under 1.7 (sorry I upgraded to 1.8 so I don't have a 1.7 install to refer to). There was an option to specify:
- domains for email authentication where a user when registering could only have an email address with e.g. .sch.uk or .gov.uk or school.area.sch.uk as we have in the UK.
- domains for email authentication which were banned
In 1.8 there is no option to either have a permit or deny list of domains for email authentication (unless I am missing something).
all the best
James
> In 1.8 there is no option to either have a permit or deny list of domains for email authentication (unless I am missing something).
I just checked my 1.8b and found the two settings "Allowed email domains" and "Denied email domains" under Server > Email in the Site admin block. Isn't what you're looking for?
Note that these settings would be more logically in the "Email-based self-registration" auth plugin.
See MDL-8613 and vote for it