Wikimedia (Wikipedia) single sign-on

[Martin Atkins]

Brion Vibber wrote:
> 
> Well, I'm not totally sure that it is, but it's worth looking at. :)
> There are several problems we're trying to solve/prevent/reduce:
> 
> 1) Having to create an account on each project is annoying
> 2) Having to log in on each project is annoying
> 3) Malicious persons registering a username on another project to
> impersonate a known user is annoying
> 4) Legitimate persons registering the same username on different
> projects is annoying

Note that OpenID doesn't magically solve problem 2. Since all of the
wikipedia sites are on different domains, the user will have to run
around and type their OpenID identity on each of them to log in.

Of course, as you said in the paragraph I snipped, cookie transfer by
some MediaWiki-provided means would help here.

> But sadly we didn't do that initially, and transitioning to such a
> system creates conflicts that are difficult to resolve automatically
> (with thousands of active users and hundreds of thousands of registered
> accounts, manual resolution by admins is something we want to minimize).

How I would do it:
(conflicts with some of your concerns, but I'll come to that in a moment)

* Add an OpenID Identity Server to MediaWiki. Each site runs its own,
identifying its own users. Users can now (assuming an OpenID consumer is
also in place) log in with their en.wikipedia.org login at
eo.wikiwhatever.org. These are your "transition" identities. The user
must pick one of the sites he has an account at already and make it his
home site, logging in there first and then OpenID-ing everywhere else.

* Run a separate identity server somewhere generic. wikimedia.org seems
reasonable. This will deal with your new user space and become the
primary namespace as far as the sites are concerned. New users will be
encouraged (or forced?) to make accounts here rather than on an
individual site.

* Deal with "well known" identity URLs by transforming them into
something pretty for display. "Mart" at wikimedia.org might just get
displayed as "Mart", while "Mart" at en.wikipedia.org might get
displayed as "Mart [en.wikipedia.org]" or something of the like.

* Deal with unknown identity URLs using conventions similar to those
that the Consumer library will help you with. www.livejournal.com/~frank
becomes "frank [livejournal.com]", http://frank.livejournal.com/ becomes
"frank.livejournal.com" and so on.

> The next simplest way is to create a new parallel user space which is
> shared between all our projects, and encourage/force migration of
> accounts to that shared space. This, too, is fraught with peril:
> 
> * If you allow a gradual migration rather than an immediate switch, how
> do you visually distinguish account types? (if at all)
> * How should usernames be displayed such that they don't suck?
> * Where do user home pages go? Do you change the old links or do they
> still work?

I think the most important problem, which you've not mentioned here, is
that there will almost certainly be a scramble for usernames on the
generic site. Mart at en.wikipedia and Mart at es.wikipedia will
probably both want "Mart", and it'll just be up to whoever gets there
first. Also, some more prolific users might be beaten to the punch by
imposters registering the name beforehand.

This can be mitigated to a certain extent by requiring people to do an
OpenID login from their old home site as part of the signup process.
Force them to have the same name, and display on the user's info page
(at least for a little while) from whence they came. This doesn't solve
the en.wikipedia vs. es.wikipedia conflict, but it does give existing
users a headstart at getting the names they are known by before the
"unwashed masses" get in there. After a few weeks you can open it up
completely and let everyone sign up with whatever name they like.

As for your other points, displaying OpenID identities remains a bit of
an unsure business. The Perl consumer library provides a simplistic
function which attempts to make them display-friendly, but it can't
handle all cases. Clearly if you have multiple namespaces you can't just
display "the username". As soon as you have multiple namespaces, it
doesn't really matter whether those are handled by OpenID or by some
other mechanism: you've got to visually distinguish them somehow.

> I don't know if we could use it internally though.

>From the concerns you've raised here, OpenID doesn't have any major
drawbacks over a home-roled single signon solution. If you're only
allowing one namespace then you can just special-case your own namespace
to display bare usernames. It saves you reinventing the wheel for the
protocol to check if a user is the right user, and you want to implement
OpenID anyway, right? That just leaves some mechanism to transfer the
session cookie to your seven (?) different second-level domains
magically on login.

This is, of course, assuming that you aren't considering just having one
shared user database and relying on all of your servers living on the
same LAN. That would certainly be simpler, but doesn't give you much
flexibility.