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