I'd like to discuss the proposed change to the authentication plugin system (http://www.mediawiki.org/wiki/ExternalAuth). As proposed, I don't see how I'll be able to keep most of the functionality in the LDAP extension.
I don't disagree that policy and implementation shouldn't be mixed, but core shouldn't be making all policy decisions. For instance, there is an option in the LDAP extension ($wgLDAPDisableAutoCreate) that disables auto-creation, but still allows auto-authentication. Essentially, it says, if the user exists in LDAP, but not in the local directory, don't automatically create the local account. Some administrators want to create accounts for users in the wiki locally, even though they already have accounts in LDAP.
Will getGroups() assign users to whatever groups the backend returns? The way I'm currently doing this is adding users to groups if they are available groups in the wiki (if they've been defined in $wgGroupPermissions). I don't use auto-promote at all.
The LDAP plugin can add users to the LDAP database. Is this also going to support that?
The LDAP plugin allows a user to authenticate with one username, but have the username created be something else. This is absolutely a must-have for auto-authentication, where a user might authenticate with Kerberos or an SSL certificate. If a user authenticates with an SSL certificate, their username may be something insane, like a numeric ID with special characters. The LDAP plugin would search the LDAP directory for another attribute that should be used for the username. Notice that you don't necessarily want to treat the auto-auth name as an ID either. You may pull both a new username, and a unique ID from the LDAP server; this is an especially likely scenario in a large organization, where a user may have a global unique ID, but in some places they may have a locally unique ID (think mergers).
There are situations where newFromId( $id ) and getId() won't work. Active Directory (AD) is a case where it is unlikely to work for most people. By default AD does not allow anonymous searches. There are two ways to handle this:
1. Use a proxy agent (AD administrators *hate* this) 2. Bind as the user first
In the second case, newFromId( $id ), and getId() will only work if authenticate( $password ) is called first. In fact, many things require the user to be authenticated before another action can happen.
From the LDAP server's perspective, MediaWiki *is* the user binding.
A few things I'd really like to see fixed with any new system are:
1. Extensions being able to display error messages (bug 16524) 2. Ability to rename a local account when the external account is renamed 3. Local group name size increased in the schema (bug 11057) so that all external groups can be synced properly
Respectfully,
Ryan Lane