Talk:IDM

Naming

Could we name this project as something else than 'Wikitech IDM', in line with the other work in the recent years to avoid using Wikitech naming for anything Developer account related? This is mostly to avoid confusion if/when Wikitech finally becomes a SUL wiki? Majavah (talk!) 11:42, 28 September 2022 (UTC)

The accounts that it would be managing are canonically called developer accounts. I agree that having "wikitech" anywhere in the name of this non-wiki account management system will be confusing for everyone. -- BryanDavis (talk) 21:58, 28 September 2022 (UTC)

We're not 100% set on a name for the new tool (tentatively Charon, but we'll source further community feedback), so for now wikimedia IDM should be a good enough placeholder. Muehlenhoff (talk) 10:50, 29 September 2022 (UTC)

Absolutely, it has now been moved. You're right that Wikitech didn't make sense. Slyngshede (talk) 10:45, 29 September 2022 (UTC)

Cloud VPS ssh key management use case missing from future plan

The Modifying account settings / Status quo section correctly identifies Cloud VPS SSH key management as a current use case. I do not see this listed as an editable attribute in the Modifying account settings / Future list. Is this an oversight or has this use case been deliberately excluded from the planned application? BryanDavis (talk) 22:03, 28 September 2022 (UTC)

Management of SSH keys is absolutely in scope, but we didn't want to overload the list of attributes, after all these are liste as examples only. But to avoid any confusion they are now explicitly listed Muehlenhoff (talk) 10:53, 29 September 2022 (UTC)

Replacement for Wikitech as a source of 2FA protection for developer accounts

One use case that I see missing from set of major use cases is TOTP-based 2FA for developer accounts. This is currently provided by the combination of MediaWiki and the action=oathvalidate API endpoint. Both Striker and Horizon use this API to enforce 2FA protection for developer account authentication today. -- BryanDavis (talk) 22:13, 28 September 2022 (UTC)

This is an excellent point, I've added it to the roadmap document. Muehlenhoff (talk) 08:12, 30 September 2022 (UTC)

Anti-spoofing, naming deny list, IP range blocking all provided "for free" by MediaWiki today

Something that is likely non-obvious when thinking about a system to replace MediaWiki for developer account creation is the number of "free" account related features that exist today on wikitech thanks to MediaWiki and integration with meta.wikimedia.org. When I implemented developer account creation in Striker, there were a few things that I discovered I needed to make API calls to wikitech for to keep feature parity:

IP range block checking via action=query&list=blocks is used to provide a small degree of protection against known abusers. This check also includes global blocks which have been created by Stewards.

User name allowed checking via action=query&list=users&usprop=cancreate. This checks against the local MediaWiki:Titleblacklist which we mostly use reserve the names of various system level accounts. Additionally the cross-wiki meta:Title blacklist is checked. The API call also invokes the protections of mw:Extension:AntiSpoof which are largely unnecessary for shell account names due to their ascii charset restrictions, but which may be useful for cn or sn attributes depending on how they are expected to be used in the resulting dataset. For currently existing developer accounts both cn and sn (should) contain the same value which is also known as the developer account's "username". This attribute is commonly used by wikitech as the wiki account username as well as being used in Gerrit, Phabricator, Horizon, Striker, and some other LDAP backed authn as the account name for authentication.

It would be worth considering the continued use of these MediaWiki API checks rather than attempting to re-implement similar functionality in a stand alone system. The synergy effects with Steward actions on the content wikis are especially difficult to replicate independently. -- BryanDavis (talk) 23:00, 28 September 2022 (UTC)

Thanks! That is excellent input and I've created a roadmap item "Consider reusing some wiki data sources for signup/restrictions" based on it. (We'll publish the roadmap on Phabricator soon) Muehlenhoff (talk) 12:24, 5 October 2022 (UTC)

Remote API for account creation?

A use case I would like to propose is a proper API that would allow account creation from external apps. My specific use case is retaining account creation functionality in Striker so that we do not have a feature regression there which would complicate the new Toolforge user workflow. -- BryanDavis (talk) 23:11, 28 September 2022 (UTC)

That is an excellent suggestion that was/is in fact missing in our current roadmap document (which needs more work before we can publish it on Phabricator). I'm adding a new item to include it. Muehlenhoff (talk) 10:55, 29 September 2022 (UTC)

Reviewing Striker for things that may be worth stealing or extracting

Way back in the olden days of 2017 I had conversations with Faidon, Riccardo, Andre, and a few other folks about the need for this type of system. Some very rough and high level information from those discussions is captured in T179463. Over the years we have touched base from time to time (usually during annual planning) to see if we had capacity to work on it yet. Seeing the announcement that this is finally happening on wikitech-l was a very nice thing. :)

One of the things mentioned in that phab task is that Striker already handles the account creation workflow and some bits of the account editing workflows. This code was not strictly written with reuse in mind, but I do think that there are things there which are at least worth being used as a reference when building this bigger and better identity management service. I would like to publicly offer to walk through the code of Striker and try to explain anything that seems weird to anyone who is interested. -- BryanDavis (talk) 23:30, 28 September 2022 (UTC)

This is literally an existing roadmap item (we called it "Evaluate Striker codebase") :-)

We have a WIP roadmap we're currently bringing in order which has more fine-grained action items. This will end up in Phabricator, so you and everyone else can comment on specific items. This wikitech page servers a more high-level entry point to the whole project to allow people to understand the general direction we're taking. Also, there's quite a few dependencies between action items/tasks, which are also better expressed in Phabricator. Muehlenhoff (talk) 08:02, 30 September 2022 (UTC)

Affiliation

The plan lists "An optional user affiliation" as one of the stored attributes. May I ask what's this used for? This seems like something that will have lots of weird edge cases considering the nature of this community. Majavah (talk!) 11:00, 29 September 2022 (UTC)

The use cases we had in mind are e.g. "Wikimedia Foundation staff member" or "Wikimedia Deutschland staff member" (since those e.g. designate possible membership in cn=wmf or cn=wmde LDAP groups). Let me know what edge cases you had in mind and we can figure how to formulate this is a less ambigious manner :-) Muehlenhoff (talk) 12:57, 29 September 2022 (UTC)