I'm skeptical about the cost/benefit ratio of making Wikitech a CentralAuth SUL wiki. It had multiple unfortunate naming policies over the years which resulted in a lot of people using a different username than their SUL account (or, in the case of WMF staff with a volunteer background, two SUL accounts and one Wikitech account); it would require either an extensive amount of renaming and content cleanup, or some kind of name mapping capability in CentralAuth that would violate a lot of assumptions in the code.

Making Wikitech outsource login to a CentralAuth SUL wiki using WSOAuth or something similar is easy. Extending the global blocking and permission system to Wikitech might not be worth the effort (or if it is, might be easier via custom hacks than by using CentralAuth).

In T161859#9233732, @Tgr wrote:

I'm skeptical about the cost/benefit ratio of making Wikitech a CentralAuth SUL wiki. It had multiple unfortunate naming policies over the years which resulted in a lot of people using a different username than their SUL account (or, in the case of WMF staff with a volunteer background, two SUL accounts and one Wikitech account); it would require either an extensive amount of renaming and content cleanup, or some kind of name mapping capability in CentralAuth that would violate a lot of assumptions in the code.

In my mind it just needs an account migration pretty much exactly like SUL unification did back in the day. The ~labswiki suffix for un-migrated local only accounts should go a long way towards keeping CentralAuth happy I think? Has the stack changed such that that solution is no longer possible?

I have always assumed that I would do that work once it was possible mostly because nobody else is likely to. "Cost/benefit ratio" sounds like an assumption that this would actually be resourced work and not anything like the active reality about everything wikitech--we do it because we need tools, not because management thinks tools are worth resourcing.

Making Wikitech outsource login to a CentralAuth SUL wiki using WSOAuth or something similar is easy.

How is that functionally different than making it a SUL wiki? Is is just the local legacy account cleanup that you would hope to avoid?

In T161859#9621255, @bd808 wrote:

In my mind it just needs an account migration pretty much exactly like SUL unification did back in the day. The ~labswiki suffix for un-migrated local only accounts should go a long way towards keeping CentralAuth happy I think? Has the stack changed such that that solution is no longer possible?

It hasn't been used or tested in a decade, I would be surprised if it wouldn't be at least somewhat broken.
But also, how would the migration work? You can't rename LDAP accounts, right? So you'd have to add some functionality to keep track of how Foo~labswiki needs to use cn=Foo for the LDAP password lookup. Or do you just rename everyone in one go, based on an authoritative and full SUL-LDAP username mapping that somehow exists, and generate random passwords for the unSULed (who hopefully have an email address)?

How is that functionally different than making it a SUL wiki? Is is just the local legacy account cleanup that you would hope to avoid?

Yes. You'd be able to log in with your Wikimedia account, we'd end up with an (incomplete) SUL-LDAP map based on those logins, you wouldn't get any of the CentralAuth functionality (although in the longer term we might be able to change that via T359116: Split up CentralAuth into smaller extensions) which might or might not be a problem wrt anti-abuse, not sure how that's imagined to work in the future.

In T161859#9621853, @Tgr wrote:

In T161859#9621255, @bd808 wrote:

In my mind it just needs an account migration pretty much exactly like SUL unification did back in the day. The ~labswiki suffix for un-migrated local only accounts should go a long way towards keeping CentralAuth happy I think? Has the stack changed such that that solution is no longer possible?

It hasn't been used or tested in a decade, I would be surprised if it wouldn't be at least somewhat broken.
But also, how would the migration work? You can't rename LDAP accounts, right? So you'd have to add some functionality to keep track of how Foo~labswiki needs to use cn=Foo for the LDAP password lookup. Or do you just rename everyone in one go, based on an authoritative and full SUL-LDAP username mapping that somehow exists, and generate random passwords for the unSULed (who hopefully have an email address)?

The MediaWiki accounts are MediaWiki accounts, not LDAP accounts. SUL migration here is very much about removing LDAP and Developer accounts from having anything at all to do with Wikitech as the canonical location for WMF operational documentation.

I honestly haven't gamed out the whole process in depth because there are still way too many blockers to make this an urgent need. At a high level the first thing needed would be converting to local authn within Wikitech. Because the passwords are currently external we probably have to get creative about how this is done. It may be possible to figure out how to harvest and reuse the password hashes from LDAP records, but it might just be easier to have everyone reclaim their account via password recovery. Once that's done Wikitech is just another fishbowl MediaWiki deployment. From there we can start integration with SUL which I think could look like everything did from the dawn of CentralAuth until the SUL finalization where there are a mix of local and global accounts in the local MediaWiki tables.

We could even decide that all of this is just too fancy and just do a ~labswiki rename for all old local accounts and start fresh with folks SUL accounts. If we did that, we could also think about possibilities to bring MediaWiki-extensions-UserMerge back temporarily (T216089: Undeploy UserMerge Extension from WMF production) just for Wikitech. I don't know if that would be a bigger lift than the alternate suggestion to bring WSOAuth into the Wikimedia prod cluster or not.

foundationwiki has been SUL-ified in T205347 and that was not such a long time ago. But Wikitech might be a bit more difficult.

Connect active LDAP accounts with SUL accounts -- this can use Bitu/Striker account linking?

Yes, the associations collected by Striker and Bitu would be part of this work. That data is at least partially in the LDAP directory itself now. What will certainly be needed is a campaign to make as many users who have not yet linked their Developer account identity with a SUL account identity to do so. I have not ran any reports to know the percentage or absolute numbers, but Developer accounts existed for many years before either Striker or Bitu allowed linking and to date there have not been major promotional campaigns outside of Striker's goal prompts that would have driven folks with older accounts to connect them together.

It seems like there is some progress on this task: https://wikitech.wikimedia.org/wiki/News/Migrating_Wikitech_Account_to_SUL

@komla: Could you provide some additional info (as you created that wiki page)? Who's the main assignee? TIA

In T161859#10002719, @Aklapper wrote:

@komla: Could you provide some additional info (as you created that wiki page)? Who's the main assignee? TIA

It's an epic. I'm not sure you can pick a single assignee. @komla is currently leading an outreach effort to get existing Developer accounts that are attached on Wikitech to provide their preferred SUL account via https://idm.wikimedia.org (Bitu) so that maximal account ownership is preserved when the backend for Wikitech accounts shifts from Developer accounts to SUL accounts.

is there a subtask about the emails being sent?, as I saw someone report this on IRC

<> I just got an email titled "[IMPORTANT] Action Required for Your Wikitech Account Migration" which says "Log in to idm.wikipedia.org [...]" but idm.wikipedia.org doesn't exist, I guess it's a typo with idm.wikimedia.org" ?

In T161859#10005035, @Peachey88 wrote:

is there a subtask about the emails being sent?, as I saw someone report this on IRC

<> I just got an email titled "[IMPORTANT] Action Required for Your Wikitech Account Migration" which says "Log in to idm.wikipedia.org [...]" but idm.wikipedia.org doesn't exist, I guess it's a typo with idm.wikimedia.org" ?

No phab task as far as I am aware, but the typo has been covered at https://lists.wikimedia.org/hyperkitty/list/cloud@lists.wikimedia.org/thread/QOPGTIOON5UYBS6BTYBXDDAUQBWSYN52/ and the general outreach has been publicly announced at https://lists.wikimedia.org/hyperkitty/list/cloud@lists.wikimedia.org/thread/W6NTBKRG6EXKMHGC23QYZMO532Q2NHF3/. In hindsight we should have made sure there was a public announcement before any of the direct action emails were sent. Time machines being in short supply we will move forward as best we can. ;)

Some thoughts:
(1) LDAP-SUL connection

1. Many people created LDAP accounts for Toolforge uses and has LDAP-SUL connection via Striker. They may not be aware that Bitu used a different connection (T371595). So we may import SUL user connections from Striker for users that does not yet have one in Bitu.
2. (a) Another potential import is matching SUL database. We can safely connect LDAP and SUL account with same username if they have same confirmed email address. (b) Also, SUL account A and LDAP account B can be connected if they have same confirmed email address which is not used in other SUL or LDAP account.
3. Also we can safely connect LDAP and SUL accounts if they linked to the same Phabricator account.

(2) SUL migration

1. After Wikitech is connected to SUL, local passwords (which are only created via password resets in transitional period) should be removed from local database, since they are PII (T104500). Probably, those (very few) of accounts not matched with SUL accounts should be migrated to CentralAuth database.
2. LDAP account emails are public but changable, so old emails may still be treated as PII. Thus emails should also be removed from local database. There are more different cases: (a) those with same email in SUL and LDAP; (b) those with different emails in SUL and LDAP - their Wikitech account email will be changed; (3) Those with no confirmed SUL email - we may or may not migrate Wikitech/LDAP emails to SUL; if we do not migrate LDAP email to SUL, there Wikitech account will no longer have an email; (d) Those without SUL accounts - same as previous one but if emails are not migrated the accounts can no longer be logged in.

Hey, I don't know how the process is ongoing but @fnegri found a few centralauth tables on labswiki while sanitizing wikireplicas. Just putting a reminder here that as part of the checklist, probably those should be deleted after SUL integration finalization, to avoid leaving leftovers of private data.

I only found the table globalblocks so far in the labswiki db, and it's empty, but there may be others.

Change #1076992 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[operations/mediawiki-config@master] wikitech: Soft connect wikitech to SUL

https://gerrit.wikimedia.org/r/1076992

Change #1076992 merged by jenkins-bot:

[operations/mediawiki-config@master] wikitech: Soft connect wikitech to SUL

https://gerrit.wikimedia.org/r/1076992

Mentioned in SAL (#wikimedia-operations) [2024-10-01T11:52:05Z] <ladsgroup@deploy2002> Started scap sync-world: Backport for [[gerrit:1076992|wikitech: Soft connect wikitech to SUL (T161859)]]

Mentioned in SAL (#wikimedia-operations) [2024-10-01T11:54:21Z] <ladsgroup@deploy2002> ladsgroup: Backport for [[gerrit:1076992|wikitech: Soft connect wikitech to SUL (T161859)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-10-01T12:01:59Z] <ladsgroup@deploy2002> Finished scap sync-world: Backport for [[gerrit:1076992|wikitech: Soft connect wikitech to SUL (T161859)]] (duration: 09m 53s)

Change #1077006 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[operations/mediawiki-config@master] wikitech: Allow 'crats to rename local users

https://gerrit.wikimedia.org/r/1077006

Change #1077006 merged by jenkins-bot:

[operations/mediawiki-config@master] wikitech: Allow 'crats to rename local users

https://gerrit.wikimedia.org/r/1077006

Mentioned in SAL (#wikimedia-operations) [2024-10-01T12:20:30Z] <ladsgroup@deploy2002> Started scap sync-world: Backport for [[gerrit:1077006|wikitech: Allow 'crats to rename local users (T161859)]]

Mentioned in SAL (#wikimedia-operations) [2024-10-01T12:22:46Z] <ladsgroup@deploy2002> ladsgroup: Backport for [[gerrit:1077006|wikitech: Allow 'crats to rename local users (T161859)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-10-01T12:28:22Z] <ladsgroup@deploy2002> Finished scap sync-world: Backport for [[gerrit:1077006|wikitech: Allow 'crats to rename local users (T161859)]] (duration: 07m 51s)

Change #1077399 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] labswiki: Disallow account autocreation

https://gerrit.wikimedia.org/r/1077399

Change #1077399 merged by jenkins-bot:

[operations/mediawiki-config@master] labswiki: Disallow account autocreation

https://gerrit.wikimedia.org/r/1077399

Mentioned in SAL (#wikimedia-operations) [2024-10-02T14:14:02Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1077399|labswiki: Disallow account autocreation (T161859)]]

Mentioned in SAL (#wikimedia-operations) [2024-10-02T14:16:20Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:1077399|labswiki: Disallow account autocreation (T161859)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-10-02T14:21:40Z] <urbanecm@deploy2002> Finished scap sync-world: Backport for [[gerrit:1077399|labswiki: Disallow account autocreation (T161859)]] (duration: 07m 38s)

Will the Two-factor Authentication previously set up in Wikitech still be effective for LDAP, or will it become invalid along with the migration to SUL?

In T161859#10209425, @SunAfterRain wrote:

Will the Two-factor Authentication previously set up in Wikitech still be effective for LDAP, or will it become invalid along with the migration to SUL?

This is a good question for T359552: Enable self-service IDP two-factor authentication management where the new system for Developer account 2FA is being planned/worked on.

Should we re-enable account creation on Wikitech or not? Account creation was disabled in https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/952209 following T345226.

Note that Wikitech accounts were previously "married" to LDAP accounts, but with this task, they are becoming "divorced". So, creating a Wikitech account will no longer automatically create an LDAP account, and vice versa, creating an LDAP account will no longer automatically create a Wikitech account. Also, the Wikitech password will no longer match the LDAP password, but rather the SUL password.

Instead, your Wikitech account will become "married" to your SUL account (along with other wiki accounts, so this is actually "polygamy"). Then, your SUL account would become a "stepparent" to any "children" of your Wikitech and LDAP accounts (i.e., Gerrit changes and Wikitech edits).