Brief description
We are planning to update MediaWiki authentication so all interaction with the login and signup forms happens on a shared domain. (See T348388: SUL3: Use a dedicated domain for login and account creation for details.) Will file a separate request about that soon, but there is a subtask we are trying to make a decision on which I thought was worth its own preview request.
You can find more details in T363695: Create a Wikimedia login domain that can be served by any wiki but in a nutshell, Wikimedia wikis use a dedicated domain for central login cookies. Currently this is login.wikimedia.org, which is set up as a standalone wiki. We are tasked with changing production authentication workflows so that, instead, the central cookie domain (currently involved in login redirect chains), must be the same domain as where the user interacts with the login of signup form. Meanwhile, users expect the login forms to be tailored to the local wiki where they are logging in from (i.e. localisation, branding, and interface customisation). We are considering achieving that by creating a new domain that's used for central login cookies, but is not its own wiki. Instead, it would be serving the local wiki's login from where the user clicked the login link, at an alternate URL. E.g. https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin being re-interpreted by MediaWiki as a request to https://en.wikipedia.org/wiki/Special:Userlogin with minor config differences. This re-interpretation would happen in the MediaWiki configuration layer.
Primary Contacts
What Security Team services do you anticipate needing?
We'll probably need an application security review for SUL3 as a whole. I don't think the shared domain approach separately needs further feedback.
What is the 'go live' date for deployment of this project
Probably end of Q1 or beginning of Q2 (so between 3-6 months). We plan to create the Beta cluster version of the shared domain nowish, to see if this approach causes any unexpected problems.
Technology overview
This is somewhat analogous to how our m-dot domains today are an alternate URL that our routing normalises to the canonical version, for MediaWiki to respond to (Apache and MediaWiki PHP don't see the m-dot hostname).
- At the Apache layer (ie. in operations/puppet), before the usual rewrite rules are applied, requets for the "sso" domain will rewrite away the first directory segment of the URL. E.g. /foo/w/index.php and /foo/wiki/X are rewritten to /w/index.php and /wiki/X respectively, so that we don't need to modify or duplicate other rewrite rules.
- multiversion: The logic for identifying the site / language is extended to recognise sso.wikimedia.org, using the first directory segment to identify the wiki, instead of the host name.
- wm-config: CommonSettings.php checks for the special host name and sets various configuration settings (e.g. $wgServer, $wgArticlePath, $wgScriptPath) accordingly.
- Various CentralAuth hooks limit the functionality available via this domain (only the special pages and API endpoints that are necessary for login, no articles or other requests permitted) and normalize the login page so that most links (help pages, etc.) use full URLs with the wiki's canonical domain.
Security considerations
- The main risk that we considered is using this special domain to access things that the attacker would otherwise not have access to, such as private wiki contents. This is prevented at multiple independent layers:
- CommonSettings.php is hardcoded to exit when the special domain is used but the wiki is not using CentralAuth.
- Functionality is limited only to public login- and signup-related special pages and API actions, which are public on our private wikis also.
- When a wiki is accessed via this special domain, it uses its normal configuration settings (with some minor differences which should not be security-relevant), so even if the other defenses fail, an unauthorized user would not be able to do anything they can't directly do on the private wiki's domain.
- There are several ways in which this approach preserves security weaknesses of the status quo (where the user could interact with the login page on any one wiki, and all wikis use the same session cookie value), which is a lost opportunity compared to the alternative implementation where we segregate all login processing to a single central wiki which is more locked down than normal wikis:
- The special login domain is shared by all wikis, so an exploit (such as an XSS) on any one wiki could be used to access the shared cookies, if it can be triggered through the special domain. Note that, since the special domain is limited to authentication-related special pages, these naturally already disable all gadgets and other personal user scriptgs or site-wide JS customizations.
- The set of extensions that are enabled and somehow reachable even on an authentication-related special page will differ from wiki to wiki and encompass all kinds of non-authentication-related things.
- i18n messages used on the login page will continue to be community-editable, same as they are today.
Code
The patches for the proof-of-concept implementation can be found in T365162: Set up sso.wikimedia.beta.wmflabs.org with config-layer routing to other wikis.
Working test environment
Beta cluster, soon (T365162). The change is mainly in operations/mediawiki-config so not really testable locally.