Once a user has been created (or when editing users) we want to offer to link it to an existing wiki account (this could be either a wikitech account or a wiki-wide SUL account). To validate that they are in control of the wiki account, we use the OAuth federation to authenticate against the OAuth provider deployed to the wikis (either the main wikis for SUL or wikitech).
|Open||None||T189531 All Wikimedia developer services should use single sign-on|
|Open||None||T161859 Make Wikitech an SUL wiki|
|Resolved||PRODUCTION ERROR||Tgr||T195253 Special:Notifications gives a consistent PHP exception on load ("The trash icon is not registered") for users with OpenStackManager notifications|
|Open||None||T106123 Extensions needing to be removed from Wikimedia wikis|
|Open||None||T161553 Remove OpenStackManager from Wikitech|
|In Progress||None||T196171 Developer account creation without OpenStackManager|
|Open||None||T179463 Create a single application to provision and manage developer (LDAP) accounts|
|Open||None||T319405 Create an IDM for Wikimedia developer accounts|
|Open||None||T320603 IDM milestone 2 "Initial limited deployment"|
|Resolved||SLyngshede-WMF||T320807 Implement OAuth account validation for linking an account to a wiki account|
an existing wiki account (this could be either a wikitech account or a wiki-wide SUL account).
A Wikitech account is itself a realization of an LDAP Developer account record. There would be no benefit in using OAuth to prove that the Wikitech account and the LDAP account are correlated.
I would actually recommend that you strongly consider using OAuth with metawiki as the primary authn for the IDM.
One thing to keep in mind is that SUL has a rather large attack surface. In a glorious future where we would use a narrowly scoped standalone application for SUL authentication and OAuth, this wouldn't be a concern; today, though, authentication happens in every Wikimedia wiki with no process or DB or web origin separation, so any SQL or XSS injection vulnerability in any extension deployed on any Wikimedia SUL wiki, or any XSS vulnerability in any community-maintained on-wiki script, or any takeover of a sufficiently privileged volunteer account (or a number of more obscure but similarly wide-ranging avenues of attack) could be escalated into takeover of any specific SUL account with relative ease.
The presence of a non-trivial risk of SUL account takeover is not great, but ultimately there is a pretty low limit on how much value an attacker can get out of a SUL account, and pretty much anything they can use it for leaves a public trace and will soon be noticed and reverted. How comfortable are you saying the same about developer accounts? They don't get you any production access, so maybe it is a similar situation, but I wouldn't be entirely sure about that.