Page MenuHomePhabricator

Create a single application to provision and manage developer (LDAP) accounts
Open, Needs TriagePublic


@faidon, @Volans, @Aklapper, and I (and probably others I am forgetting) have talked about the need for a web application that provides a better user experience for creating and managing LDAP accounts for Wikimedia's same sign-on services which are detached from Wikimedia wiki (SUL) accounts.

As outlined in T179461: Use the term "developer account" for Wikimedia LDAP accounts, LDAP is currently used to provide authentication and in some cases authorization for a number of Wikimedia services:

Additionally, LDAP derived data is used in the Wikimedia Puppet configuration to allocate user ids for shell account users. LDAP group membership is used for authorization in several places including Gerrit and LDAP protected services.

The workflow for creating a new LDAP account is poor. The user interface is a single page collecting multiple pieces of information. Instructions are not clear. Error messages are poor or in the worst cases misleading. Client side validation is not offered for all fields.

Work was done in Striker to improve the workflow, but those efforts were targeted at Toolforge contributors and are not broadly advertised to all users needing a new account. The Toolforge specific branding in Striker is also confusing if the account is desired merely for Gerrit access or other non-Toolforge reasons.

Beyond account creation, management of a LDAP account by users and other administrators is cumbersome:

  • Password changes can be done via Wikitech or Striker.
  • Password "recovery" can only be done via Wikitech (T174469).
  • Two-factor auth can be used on Wikitech, Horizon, and Striker, but can only be managed via Wikitech. Currently no other services can enforce two-factor protection for LDAP accounts.
  • Group membership is managed using command line tools with cumbersome interfaces.
  • Some forms of directory browsing can be done with Toolforge tools, but there is no web interface that offers deeper querying or inspection to authenticated users.

T161859 postulates a world where Wikitech is a normal SUL wiki sharing accounts with enwiki and the rest of the sister projects. To realize this dream, we at least need to create a replacement for the end-user workflows of creating and managing an LDAP account. This can be accomplished with Striker, but it would be nice to also address some of the other issues without conflating them with the Toolforge use cases that Striker is intended to handle.

A more ideal solution would provide:

  • LDAP account creation
  • LDAP account management for account owners
    • password change
    • password recovery
    • public key storage (for VM access)
    • ?other data editing?
  • Single source of truth correlation of SUL and LDAP accounts
  • LDAP account management for administrators
    • enable/disable accounts
    • view, edit group membership
    • view, edit accounts
  • 2fa account protection
  • True single sign-on rather than same sign-on for external services

There is also an opportunity to use this same application as a hub for pointing to information for technical contributors. Wizard based workflows and goal prompts for various new contributor workflows could be integrated with the core LDAP authn/authz management purpose.

Implementing all of this at once would be a non-trivial amount of work. It should be instead be done in stages that build on top of each other. Getting the core end-user facing parts done may be relatively easy. Striker already has code for most of the necessary functions. The biggest challenge is probably the creation of a true single sign-on service that can be integrated with Gerrit, Apache, Nginx, and other services that are currently using LDAP for authn/z. This and the 2fa service are things where a build vs buy comparison should be made with available FLOSS solutions which are compatible with using an LDAP directory as the primary source of truth.

This is all a bit scattered at the moment and the ideas could use refinement by others. Should the main description be moved from this task to a wiki page somewhere that is easier to collaborate on editing? Maybe the RFC section on

Related Objects

Event Timeline