[Wikitech-l] Changing CentralAuth login - New proposal

Roan Kattouw wrote: CORS does seem to be the way to go. I have drafted a new proposal below which attempts to fix several bug in our way of doing central login. ---- Create a multilingual wiki for handling logins, available as https://login.wikimedia.org/ https://login.wikipedia.org/ https://login.wikiversity.org/ etc. On clicking pt-login at http://xx.yyy.org you would be sent to https://login.yyy.org/wiki/Special:Userlogin (with proper uselang and full url returnto parameters) If it is a user SULed there with the right password It performs a number of CORS POST requests[1] to each https://login.yyy.org with yyy all the upper domain levels, which set full or partial login cookies depending on the doman trust. If the source wiki is on a lower trust domain it is target of an additional login. As a last login step, it resets the continue link, which would otherwise login you through a series of redirects. else if it is a valid local unattached account The password is verified by impersonating the source wiki. The CORS steps above are done with just the source wiki as target. Visiting a page with full login cookies would log you in, autocreating the account, etc. (no changes) Visiting a page with partial login cookies (and no logout) would remove the cookie, replace the visited page with a lightweight page (We are processing your login) which connect using CORS to https://login.<project>.org setting your credentials and reloads to the full page [2]. There's a redirect-driven fallback. *************************************************** What are you naming full and partial login cookies? A full login cookie is one that automatically logs you in. Those would be centralauth_Token and centralauth_User, used as we currently do. A partial login cookie is one that sets just centralauth_User (and unsets the logged out one) so that it doesn't allow credential thief [3]. The loginwiki still sets a httpsonly cookie for itself in such case. What kind of content would you put on that wiki? None. That's not a wiki designed to be edited. We could allow editing the login messages using its MediaWiki namespace or force everything to go through translatewiki. It would use its local load.php to avoid mixed content warnings. It can be later reused for other purposes, such as managing global preferences, though. We would need to change all our infrastructure to support https wikis! All requests will be uncacheable [4], it doesn't need a squid/varnish in front of it. I would begin by placing a single server with multiple interfaces and slowly moving the wikis to use it. Why use it with several domains? That way, it can securely set cookies for the source wiki even if the browser doesn't support CORS [5]. It is also more consistent than delegating on one wiki for setting the subdomain cookies. The users shouldn't be taken out of their wiki By keeping the project domain, they are unlikely to feel that they are sent to a completely different site. The skin look and feel will be the same as the wiki from which they come. The only difference would be the sidebar, which we can fetch from the source wiki, or replace with password related topics. Which CORS policy does it need? The proposed can work securely by relying just in cookies and queries, so it would work with even a * Access-Control-Allow-Origin. It's probably safer to set it to *.wikipedia.org, *.wikimedia.org etc. Can JSONP be used instead of CORS? All of the above protocol could be performed with JSONP, but then it would be vulnerable. 1 - Using simple POST requests does not need preflight queries. 2 - It would be possible to add an iframe fallback for older browsers. 3 - It can also be a completely different boolean cookie if matching username with the ip is a concern. 4 - Except CSS/JS ones. 5 - That means a redirect return for domains with partial logins.