Auth systems/SUL2

Current System

 * When a global user logs in to a local wiki, CentralAuth will inject images on the result page to attempt to log the user into other WMF projects
 * Images for each wiki in $wgCentralAuthAutoLoginWikis are generated
 * The images call Special:AutoLogin with a token, which is used to setup the session associated with this user
 * The user gets a top-level-domain cookie for each wiki, which expires in 1 day
 * On logout, the session are deleted

Current Issues

 * In the existing scheme, many mobile browsers (70%) do not accept the cookie for the foreign wikis when the user hasn't visited that wiki directly
 * Firefox 22 will block third party cookies as well
 * At minimum, users need to be logged into commons.wikimedia.org and wikidata.org to take advantage of mobile and visualeditor features

Proposed Solution

 * A central domain where global users would have a session / cookie
 * After logging in on the local wiki, CentralAuth would redirect the user to the centraldomain to set the cookie
 * On each wiki, anonymous users would have some javascrpt that contacts the central domain to determine if the user is logged in
 * If the user is logged in, update the UI or redirect the user to finish building their session
 * If the user is not logged in, set a cookie/local storage so the wiki doesn't attempt the check again
 * Since each user will call this service once per session, we can estimate a load of about 193 calls/second
 * Special:UserLogin will always check the central domain for a session, and show a successful login message if the user is logged in
 * Local wikis will also provide an api where a user can request a short-lived token, which can be used for authentication to another wiki's api. This will allow users to talk to the api of other wikis in the cluster as the global user.
 * To limit the potential for abuse, the token should not live more than a few seconds, will only be valid for a single target wiki, and will expire after use.
 * So this is pretty much like what Special:AutoLogin does? And I'd guess that the client would be having to get another token for every request to the other wiki, since XMLHTTPRequest's attempt to set cookies probably will be blocked too. How would that interact with CORS preflight OPTION requests, if bug 41731 ever gets fixed?
 * Pretty close to Special:AutoLogin, although I'd like the expiration to be a few seconds instead of minutes. We can make sure it's long enough that the client can do a preflight and the request before it times out. And yes, the client would need to request a new token per call.
 * If the token expires after a single use, won't the preflight will "eat" the token so it won't be valid for the actual flight?
 * I don't think the token will be sent in the OPTION call (assuming your doing a post, and that is why you need the preflight), so I don't think it would be consumed at that point. But that's just from reading the spec and doing a little playing around in firefox. We could probably allow it to be used twice if it's an issue.
 * That depends if it's a GET or POST, of course, and note the API already requires the "origin" parameter be included in the query string even for a POST. I guess the question there is whether the preflight also would ever need to be authenticated.

Rollout Plan

 * Setup the central wiki
 * Modify centralauth's interaction with the login to redirect to central wiki and set the central cookie; continue to use Special:AutoLogin images temporarily.
 * Enable autologin javascript on all wikis
 * Disable Special:AutoLogin