Is there also a "make everything SUL" plan? More specifically, a plan to replace passwords with some kind of SUL-based remote login on gerrit, horizon, logstash etc?

What will happen to accounts already created and SUL accounts? Would we be able to get them merged/migrated/etc?

@Tgr, I don't think we would want to do this. The threat model for horizon/gerrit/etc is quite different from on-wiki account access so I'd prefer that we keep the two separate account types.

That said, a simpler/unified login service for all developer account types might be nice.

In T161859#3997722, @MarcoAurelio wrote:

What will happen to accounts already created and SUL accounts? Would we be able to get them merged/migrated/etc?

My intent is for all existing LDAP accounts (that are still in use) to be associated with a SUL account. This is the "Connect active LDAP accounts with SUL accounts" step in the very high level plan. It is possible today to make this association using https://toolsadmin.wikimedia.org/. The "Replace wikitech as source of LDAP account creation" step would be a good time to introduce this idea more broadly and to start a campaign to get active users to make the association.

In T161859#3997670, @Tgr wrote:

Is there also a "make everything SUL" plan? More specifically, a plan to replace passwords with some kind of SUL-based remote login on gerrit, horizon, logstash etc?

That decision is largely beyond the scope of the Cloud Services team. The projects we own that could do this are Horizon and Striker (toolsadmin). There is a plan for Striker to use SUL via OAuth as the authentication mechanism. I think it would be possible for Horizon as well, but one thing we would probably want to be able to do for Horizon is to require that the SUL account be using 2FA protection.

In T161859#3997670, @Tgr wrote:

Is there also a "make everything SUL" plan?

Filed that as T189531: All Wikimedia developer services should use single sign-on.

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.