As I said T367968#9908254, there may be accounts currently unattached to SUL. We need to handle them before switching to SUL3.

In T348388#9908262, @Bugreporter wrote:

As I said T367968#9908254, there may be accounts currently unattached to SUL. We need to handle them before switching to SUL3.

I don't see why. They will remain available via the action=login API which we probably won't remove anytime soon as it would probably cause a huge fallout for bots.

They will remain available via the action=login API

This will only applies to API login. But there are unattached accounts that is neither bot nor system user, and they will not be able to log in using normal way.

Even for bots, manual login is useful to modify password or 2FA settings (which will be moved to loginwiki, so will not work for unattached local accounts).

Actually, I don't think unattached accounts can log in at all. That was disabled way back in rOMWC165ecbfaba66: Set $wgCentralAuthStrict = true;.

In T348388#9916155, @Tgr wrote:

Actually, I don't think unattached accounts can log in at all. That was disabled way back in rOMWC165ecbfaba66: Set $wgCentralAuthStrict = true;.

So it would be the time to remove support for unattached accounts (i.e. assume all accounts are mergable) in CentralAuth.

In T348388#9916271, @Bugreporter wrote:

In T348388#9916155, @Tgr wrote:

Actually, I don't think unattached accounts can log in at all. That was disabled way back in rOMWC165ecbfaba66: Set $wgCentralAuthStrict = true;.

So it would be the time to remove support for unattached accounts (i.e. assume all accounts are mergable) in CentralAuth.

We are not the only user of CentralAuth. While this functionality may not be tailored to third party use, I think we should allow for some basic differences in configuration, setup, and migration/merges of existing accounts on other sites.

In T348388#9916455, @ArielGlenn wrote:

In T348388#9916271, @Bugreporter wrote:

In T348388#9916155, @Tgr wrote:

Actually, I don't think unattached accounts can log in at all. That was disabled way back in rOMWC165ecbfaba66: Set $wgCentralAuthStrict = true;.

So it would be the time to remove support for unattached accounts (i.e. assume all accounts are mergable) in CentralAuth.

We are not the only user of CentralAuth. While this functionality may not be tailored to third party use, I think we should allow for some basic differences in configuration, setup, and migration/merges of existing accounts on other sites.

First, currently CentralAuth migration code is buggy (T288906: Remove or rewrite CentralAuth SUL migration code); Second, unattached accounts not only do not work with SUL3 (and already not work well for other features requiring SUL finalization), it also results in issues like T275931. Third, the codes that deals with locally unattached users and SUL migration is complex and there are currently three database tables for it (localnames, globalnames, users_to_rename) and multiple configuration options and user rights. They are not well tested and maintained.

Currently we do not recommend third party users to use CentralAuth (partly) due to its complexity and difficulty to install, and such changes (plus T359116: Split up CentralAuth into smaller extensions) will make it easier for 3rd wikis to use and maintain (though existing wiki farms using CentralAuth must complete an SUL finalization process similar to Wikimedia). In my proposal, it is still able to install CentralAuth in an existing wiki farm; However, they will need to first manually rename each conflicting user names, since users with same name will always be merged to one single global account.

For what it's worth, Miraheze has had $wgCentralAuthStrict = true; for about 8 months now (and probably should have had it for much longer).

We're actually fairly excited about this project in general because it will mitigate some of our security risks, as well as presumably having less flaky login in general.

In T348388#9916271, @Bugreporter wrote:

So it would be the time to remove support for unattached accounts (i.e. assume all accounts are mergable) in CentralAuth.

Given that those accounts are already unusable (via web login, anyway; some of them are used by maintenance scripts, see T214722: Introduce global system users), I don't think the SUL3 project has any bearing on them.

In any case, I'm not sure what "remove support" means. We could remove support for $wgCentralAuthStrict = false; that might or might not be problematic for other CentralAuth users, and the only benefit to us would be getting rid of some code. (Which is definitely valuable, but I hope we can work on T359116: Split up CentralAuth into smaller extensions in the foreseeable future, which would be a better opportunity for B/C breaks.) Beyond that, I don't see what could be done here. CentralAuth should continue verify database consistency and disallow login if the local account is not attached; not doing that just seems unwise. So in that sense I don't think "assume all accounts are mergable" is reasonable.

disallow login if the local account is not attached

What I proposed is remove a large number of codes dealing with unattached users and SUL merging (see T368235); after then if user try to log in an unattached local account, it will (1) if a global account exists, automatically attach local account to SUL and try to login using global credential (local password is discarded); (2) if one does not exist, create a global account and migrate the credential to SUL, and use it to login.

those accounts are already unusable

But having an unattached local account for User:Example in enwiki will make Example unable to edit enwiki, so it is still problematic. We may want to prevent it completely.

In T348388#9917274, @Bugreporter wrote:

But having an unattached local account for User:Example in enwiki will make Example unable to edit enwiki, so it is still problematic. We may want to prevent it completely.

Yes but that's the status quo, it doesn't have anything to do with this task. No one reported such problems in a long time, and there weren't many unattached accounts when I last checked (that was several weeks ago, but hopefully they only decrease over timew) so this is a marginal issue.

In T348388#9917250, @Bugreporter wrote:

What I proposed is remove a large number of codes dealing with unattached users and SUL merging (see T368235); after then if user try to log in an unattached local account, it will (1) if a global account exists, automatically attach local account to SUL and try to login using global credential (local password is discarded); (2) if one does not exist, create a global account and migrate the credential to SUL, and use it to login.

If we don't care about other users of CentralAuth, we should probably just get rid of all the auto-merge logic, and just fail for unattached accounts and tell the user to ask for help. That would get rid of a fair amount of code in CentralAuthPrimaryAuthenticationProvider.

I have mixed feelings about potentially breaking other wikis just to get rid of code that's not problematic to maintain, although use of CentralAuth by third parties isn't officially supported. (But some major wiki farms like Miraheze do use it.) T359116 will probably involve breaking changes anyway, so that's why I would want to roll this into that project.

potentially breaking other wikis just to get rid of code that's not problematic to maintain

Note: In my proposal the only drawback is (after running migration script) all unattached accounts will become attached regardless of password and email, so local accounts that should not be merged must be renamed to other unique name first.

I know username policies etc have been discussed in the past wrt this project, but I can't find back where...

Has thought been put into how the centralised system can help with that ? Maybe it is an idea to have some sort of customisable local steps (local pre and post onboarding screens/interstitials or something ?)

Original task description, for history and search:

CentralAuth relies on the concept of a central login wiki (e.g. login.wikimedia.org for Wikimedia wikis), but (despite what the terminology might suggest) it's not where login actually happens. Users enter their credentials in their home wiki and get logged in there, and the the central login wiki is used, through an elaborate series of redirects, to create a central session (essentially, a cookie stored on the central login wiki) and look up it to authenticate the user on other wikis.

This has the benefit that the user never leaves the wiki they are familiar with and the wiki community can customize the login and signup page (e.g. indicate username requirements specific to that wiki), and and administrative tools such as blocks and AbuseFilter filters also behave more naturally. But it causes a lot of problems:

• Since the user expects they might need to enter their password on any wiki (even more so with central login not working reliably), an XSS vulnerability on any wiki can easily be escalated into password theft. It's hard to meaningfully monitor hundreds of wikis, and these wikis are often by design less secure than the central login wiki (more people can deploy sitewide JS, there are more gadgets and so potentially more vulnerabilities etc). A separate wiki that's only used for entering login credentials could easily be locked down to the extent where XSS on another wiki in the same farm cannot be used to interfere with login. ({T190019})
• The redirects used for central login are indistinguishable from user tracking, from a browser's perspective; and browsers increasingly break it to prevent tracking. (T345249: Mitigate phase-out of third-party cookies in CentralAuth)
• Related to the previous point, the authentication flows that browser vendors expect all involve a single SSO domain (without the historical baggage of CentralAuth, it's just a much more natural way of doing things) so that's what they build their heuristics on (e.g. they consider it suspicious if a domain wants to set cookies but the user has never interacted with it) and that assumption is built into web APIs (e.g. the concept of a service domain in T345589: Investigate the First-Party Sets / Related Website Sets browser API or the login flow in T335851: Investigate the Federated Credential Management browser API).
• Various authentication-related data is stored per domain by the browser (e.g. cookies, passwords, WebAuthn T248339: Decide how to deal with WebAuthn login/registration flow on Wikimedia wikis in future) so having many wikis severely degrades the user experience of authentication, and degrades privacy (e.g. there is no practical way to delete your authn cookies on all Wikimedia projects) and security (it's easier to notice you are being phished if you always log in on the same domain, e.g. because you can expect the password to be prefilled).

We need to disable local login and use a central, single location where the user interacts with credentials. This includes at least login, signup, password change, password reset; arguably also bot passwords and OAuth.

---

There are a couple ways to do this:

• Minimal-effort version: Have Special:UserLogin etc. redirect to loginwiki, do the user interaction there (if the user is already logged in, probably just show a button to confirm identity, to fulfill interaction requirements for bounce tracking prevention heuristics), redirect back on success or failure and prove to the other wiki what happened. Everything else is kept as-is. (Note: the MediaWiki / CentralAuth code change needed for this is pretty small, but many bots and apps would have to be updated, so on the whole not a small project nevertheless.) Or maybe instead of redirection, embed the relevant loginwiki form as an iframe.
• Use FedCM (T335851: Investigate the Federated Credential Management browser API) if it becomes available, which is vaguely similar (and requires a non-FedCM fallback in any case, for older browsers and non-browsers) but requires a couple extra APIs and a "popup" layout for the login form.
• As above, but also rethink session handling (as the half dozen auth cookies used by MediaWiki don't make that much sense when login is happening elsewhere) and use something like JWT cookies (e.g. OAuth 2 access tokens) instead.
• The same but (taking advantage of using an industry-standard format for sessions) replace loginwiki entirely with a small dedicated app to reduce attack surface (cf T120484: Store CentralAuth password hashes outside the main database cluster). Note that this would affect a number of important steward workflows so it needs careful investigation.

These options could also be done as successive stages (at the cost of some overhead).

In T348388#10543403, @TheDJ wrote:

I know username policies etc have been discussed in the past wrt this project, but I can't find back where...

Has thought been put into how the centralised system can help with that ? Maybe it is an idea to have some sort of customisable local steps (local pre and post onboarding screens/interstitials or something ?)

After T363695: Create a Wikimedia login domain that can be served by any wiki the system ended up less centralized than we originally thought; the interaction with username blacklists, abuse filters etc. should be identical to before.

In T348388#10555816, @Tgr wrote:

In T348388#10543403, @TheDJ wrote:

I know username policies etc have been discussed in the past wrt this project, but I can't find back where...

Has thought been put into how the centralised system can help with that ? Maybe it is an idea to have some sort of customisable local steps (local pre and post onboarding screens/interstitials or something ?)

After T363695: Create a Wikimedia login domain that can be served by any wiki the system ended up less centralized than we originally thought; the interaction with username blacklists, abuse filters etc. should be identical to before.

Thank you for confirming @Tgr !

In scope:

• Moving login, account creation, password change and reset to a dedicated domain
• Ensuring that autologin still functions as today, requiring users to sign in only once
• Full compatibility with existing CheckUser workflows, including cross-wiki on loginwiki
• Full compatibility with temporary accounts and supporting their rollout

I think this is now done except for two things that are borderline in scope:

• client hint support on accounts autocreated via jobs (T381128: backfillLocalAccounts.php should fill Client Hints)
• moving credentials change to the central domain for WebAuthn (T362715: Move credentials change to central domain - for B/C we want to keep it working on the old domains for a while since otherwise users can't disable old keys)

I think we can close this and track those two edge cases in their own tasks.

login.wikimedia.org is currently only used for cross-wiki CheckUser checks, which can also be performed on meta.wikimedia.org. Therefore, can login.wikimedia.org be deprecated? Should an issue be created for this?

In T348388#10719519, @Arendpieter wrote:

login.wikimedia.org is currently only used for cross-wiki CheckUser checks, which can also be performed on meta.wikimedia.org. Therefore, can login.wikimedia.org be deprecated?

Deprecated meaning, deleted? Or not used for CheckUser anymore? I think using meta instead would be nice as it seems like it might fit better into stewards' workflows. But I don't understand those workflows very well so I'd defer to the stewards on this.

Other than CheckUser, it won't be used for anything else. (Right now it's still checked for autologin, since we are migrating existing login sessions from login.wikimedia.org to auth.wikimedia.org. See T391284: Swap order of central autologin lookup for loginwiki and shared domain.

In T348388#10719519, @Arendpieter wrote:

login.wikimedia.org is currently only used for cross-wiki CheckUser checks, which can also be performed on meta.wikimedia.org.

While true from a technical perspective, it is not true from a policy/social perspective. Without a change in policy, stewards cannot CU on metawiki without also being elected as CUs there since metawiki has local CUs.

In T348388#10723564, @Tgr wrote:

I think using meta instead would be nice as it seems like it might fit better into stewards' workflows. But I don't understand those workflows very well so I'd defer to the stewards on this.

While metawiki would be a better workflow fit, getting policy changed would be the hurtle.

(FYI, the CU data available on metawiki and loginwiki are not the same. The latter only ever has a single entry.)