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.
It isn't a change, it's an addition. AuthPlugin will be kept
indefinitely, certainly at least until all users in trunk are
obsoleted by equivalent ExtAuth plugins (which may well be never).
Ah. That's good. I have a good feeling I'll be moving to the new system as I
definitely like some of the ideas in it so far. I especially like that the
extension will be passed the exact username string typed by the user. I have
some open bugs regarding that.
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.
First off, if this is desirable for LDAP, it's desirable for other
auth systems too. Therefore, in ExtAuth, this feature would be added
to the core code, *not* individual extensions, so that it could be
used by *all* backends. The LDAP-specific stuff should only deal with
stuff that is *really* specific to LDAP, like connecting to the LDAP
server and mapping MediaWiki auth info to however LDAP stores things.
That makes sense. My only concern is that this will require extension
developers to dive into core to add features they'd normally add to their
own extension. This isn't necessarily a bad thing, as their changes could
benefit everyone.
Second, I'm not sure what you mean by
"disables auto-creation, but
still allows auto-authentication". The user must be authenticated as
*some* user that exists in the MediaWiki database, no? How does
auto-authentication work in this case?
This might be the same as $wgAutocreatePolicy. The default is
'login', which autocreates accounts if a user logs in, their auth
information doesn't match any local account, and it does match an
external account. You can also set it to 'never', which never
autocreates local accounts (so they have to be manually linked, which
doesn't work yet); and 'view', which will try to autocreate from
cookies or such if supported by the backend.
Setting it to 'never' would likely fit this situation; I believe this is the
correct use case (I've never used this functionality personally).
You mean, you just take the group name strings
returned by LDAP and
assign them to the user as MediaWiki groups? That's an interesting
idea, provided there are no conflicts. It would be a lot simpler than
using auto-promote. However, it could cause problems if group names
were weird, like with spaces or something, since a lot of code
probably assumes they look like typical MediaWiki group names.
Still, I think this is a better approach. Currently this isn't
actually implemented at all in ExtAuth, so it could be changed to the
method you describe easily enough.
I add users into the groups; I don't add groups to users. I do this by:
1. Getting a list of all groups ($user->getAllGroups()), and a list of
groups the user is in ($user->getEffectiveGroups())
2. I iterate through the list of all groups and:
2a. Add the user into the wiki group if they are in the external group
2b. Remove the user from the wiki group if they are in the wiki group, but
no longer in the external group
Effectively, I'm synchronizing the groups every login.
This means the admin must choose which groups they want to synchronize by
creating them in LocalSettings.php using $wgGroupPermissions, by adding
permissions to the group.
I do have functionality to add all groups to $wgGroupPermissions (via
$wgLDAPGroupsPrevail), so that other extensions can use the groups, but that
code is *really* expensive, as sometimes users are in hundreds of groups;
I'm unfortunately not exaggerating about the hundreds of groups, I've done a
support request where someone had users that had 500+ groups.
The LDAP
plugin can add users to the LDAP database. Is this
also going
to support that?
That's a possible feature, although I don't think it's in any of my
design documents. For many backends it would be impractical, but it
would make sense for LDAP. I mostly designed this to allow
authentication on my site's wiki from vBulletin, another web app, so
the design is probably skewed toward that, but I'm pretty sure it's
flexible enough that it could be adjusted to support LDAP well.
Some extensions use this to manage an external database that all their
applications use. It is a fairly esoteric feature, but I have users that use
it in production. I personally have never used the feature past testing.
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).
This is part of the design for ExternalAuth, although it hasn't yet
been implemented. It's necessary for any backend that doesn't have
username restrictions as rigid as MediaWiki, or that uses
incomprehensible usernames. Even if you're just authenticating to an
external MediaWiki, it's necessary to resolve conflicts. (In
particular, this is necessary for vBulletin, since that permits
characters like / in names, but it's not so essential, since most
names don't have them -- which is why it's not implemented yet.)
Well, the proposal mentions allowing the user to choose their own username.
That is fine for some extensions (OpenID does this, for instance), and it
may even be useful for the LDAP plugin, but I'd like to ensure the plugin
can choose the name without giving the user an option.
It would be *really* nice if this worked for both regular, and
auto-authentication, as right now it only works for auto-authentication; I
use this for a semi-anonymous user feature, but it only works for auto-auth:
http://ryandlane.com/blog/2009/06/18/semi-anonymous-users-in-mediawiki-using
-the-ldap-authentication-extension/
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.
From ExternalAuth's perspective, an "id" can be any unique, stable
identifier. It's used to store the information "MediaWiki user 13099
is associated to external user 32769". A "username" is expected to be
something human-readable, which is actually used for login, but which
may change from time to time (due to renaming). id's are stored in a
varchar(255) and are not required to be numeric.
In particular, I think LDAP could just use an id equal to the
username, since LDAP usernames are supposed to be stable, right?
Actually, no. LDAP usernames are not assumed to be unique, or stable.
Generally, usernames are based on some combination of a person's name.
People's names can change for various reasons (marriage, legal name change,
etc.). When a person's name changes, their username changes with it. LDAP
entries are assumed to have some unique identifier that is often different
than the username. In the Posix schema, this is uidNumber. In Active
Directory, it is often the Security Identifier (SID), but may also be the
userAlternativeName attribute, which is often the case in smart card
infrastructures.
In the Posix schema, this is guaranteed to be an integer, but in Active
Directory, it will most likely be a string, and can be fairly long.
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)
This sounds like a good idea. An implementation idea would be to add
a new method ExternalUser::getAuthenticationErrors(), like
Title::getUserPermissionsErrors(), and use that in core code instead
of authenticate(). The new method could wrap authenticate() in the
base class, so classes that didn't need such fancy control could still
just use authenticate().
That sounds like a good idea.
2. Ability to
rename a local account when the external
account is renamed
Sounds like a good idea, but how would you detect that the external
account was renamed? Would you expect the external auth source to
push this info to MediaWiki, or should MediaWiki detect it when the
user next logs in? How should MediaWiki detect it -- remember the
external username, and update the local one if the external one is
different from what was remembered? Presumably it would just abort
silently if there's some conflict (e.g., new name not usable by
MediaWiki, or already taken).
The current ExtAuth implementation only stores the foreign id locally,
not the name. If the external name changes, and the new external name
isn't taken locally, you can log in to MediaWiki using either the new
or old name, IIRC -- if you try the new one, it will authenticate you
as the external user, then notice that that already has a local
account and log you in as that. But your MediaWiki username will
remain the same as the old name unless you're renamed on MediaWiki.
This works for now, but would be nice to change.
I implemented this in my extension, and tested it, but never publisized it,
since it relied on the rename user extension, and I wasn't totally sure I
wasn't going to cause massive data corruption if there was some
incompatibility I didn't foresee.
The LDAP plugin detects the external account was renamed the following way:
On account creation, the plugin records the external ID. On authentication,
the plugin queries LDAP, and gets the username back. If the username is
different than the local account, the plugin renames the account, or blocks
login, which should inform the user to contact the site admin. If the new
username is already taken, the plugin blocks login, which should inform the
user to contact the site admin.
Allowing the user to choose a new name in this situation wouldn't really
make sense, as the extension is assuming the external username matches the
local one. Keeping the name the same is also really problematic for most
organizations using LDAP, as usernames may be re-used.
This actually makes me think of another case that needs to be handled. If
the local database has a username that is the same as a username in LDAP,
but has an external ID recorded that is different from what is in LDAP, the
account in LDAP was likely deleted, but the username was re-used. The plugin
should block login in this situation, so that the admin can rename the
account to something like "Username (deleted)" or "Username (was
<uid>)".
This is important from an auditing perspective.
All of this assumes that account renaming can be initiated reliably from an
authentication extension. This isn't currently possible. Why isn't
RenameUser part of core?
User renaming, blocking, etc. should likely be a configurable option, as
some features (such as the semi-anonymous example above), assume the
username to be different.
3. Local group
name size increased in the schema (bug 11057) so that
all external groups can be synced properly
I forgot that MediaWiki group names have to be so short. Maybe
autopromote is a better idea after all for backends that might have
long group names. But that should be fixable, anyway, I hope.
Well, from the bug, it looks like the schema was set to be modified to have
255 character names, but it never happened. It is really unlikely for groups
to be longer than 255 characters.
Respectfully,
Ryan Lane