This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.

An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth&gt;. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.

There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).

I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.

link() to linkToLocal() or some such longer name, link means other things in MediaWiki so it needs the longer name to avoid ambiguity.

Please change the schema and the configuration to allow for multiple external user providers, like we do for images with $wgForeignFileRepos. In my opinion, the fact that AuthPlugin couldn't do multiple user databases was its biggest architectural error. It's an error which is easy to avoid, so I'd hate to see it repeated in a rewrite. To support the feature would only need 100 lines or so of glue code, similar to RepoGroup.php.

This might be good enough as it is for Wikimedia deployment, but it's not good enough for a release. As soon as an interface is released, we're stuck with it forever. If you don't feel like working on it, it can be moved out to a branch for now.

I've done all the renames you've asked for. I haven't allowed multiple auth providers yet because I don't have any clear concept of who would use it, so I'm not sure how to design it. When you try to log in, should the software stop at the first external auth provider that returns true, or try to link the user to multiple accounts? If the user changes preferences, should it bubble up to everywhere the user is linked to? If the user isn't allowed to change local preferences when changing them externally fails ('global' in $wgAllowPrefChange), what if one provider fails but another doesn't? Should users be allowed to be linked to multiple auth sources at all, or is this unnecessary?

I don't think architectural changes would be needed in any event. The core part of the mechanism is very open-ended. If someone wants multiple auth mechanisms, I think the best way to do it would be to just write ExternalUser_Multiple. If it then turns out there's some other way of doing multiple auth sources that someone else wants, you could do some new class without everyone having to work around an awkward configuration format.