IDM

Wikimedia IDM (codename Bitu) is an identity management service that (will) centralize and streamline account creation, account settings, access groups, and account disabling for Wikimedia Developer accounts (sometimes known as "Wikitech", "LDAP", or "Gerrit" accounts). IDM stands for identity management.

Preliminary design decisions

In line with other in-house build web-application Django has been picked as the framework for the IDM solution.

Core LDAP functionality will be implemented in a separate library, which can be reused for other LDAP tools. The goal of the LDAP wrapper library is to abstract the LDAP searches and command away, and instead present user and group objects for the developers to interact with. See Gerrit for code: https://gerrit.wikimedia.org/g/operations/software/bitu-ldap

Safety is a major concern and the IDM must not become an entry point for an attack to escalate privileges. In the initial implementation certain operations will require manual interaction from a member of the SRE team. E.g. access to servers will require a manual review and merge of a Gerrit change.

Initial use cases for IDM

This document describes the initial use cases for the IDM implementation. The goal is to identify three, or more, frequently occurring tasks regarding access rights and management. These are to serve as the guidelines for the initial implementation of the IDM solution.

Major use cases for the Wikimedia IDM page

The use cases below will serve as starting points of design and implementation of the IDM solution. Each use case is split in a "as is" and "to be", representing the current state or workflow, and the desired outcome.

Account creation

Status quo

Account creation currently happens via the LDAP_Authentication extension, built on top of the standard MediaWiki account creation with an additional field to ask for a shell username added by the OpenStackManager extension which is installed on the web servers running https://wikitech.wikimedia.org.

The Wikitech wiki is currently hosted differently and separately from the main MediaWiki platform that hosts Wikipedia and all other public and private WMF wikis. There’s the intent to eventually make Wikitech a standard wiki like the others (tracked at T161553 and T161859). The original purpose of the OpenStackManager extension has mostly been obsoleted by the adoption of Horizon for the management of the OpenStack infrastructure of Wikimedia Cloud Services.

The Wikimedia Developer account creation mechanism is used by other community members and staff members of the Wikimedia Foundation who are working in a technical capacity. The extension currently creates a user directly in the Wikimedia LDAP directory, allocates a UID, and allows the adding of SSH public keys for use by Toolforge and Wikimedia Cloud VPS. It also records the person’s email address.

The LDAP user ID (UID) is also the same UID that is we use for logging into restricted web applications in Wikimedia production via such as Grafana, Orchestrator, Logstash, and Horizon (mostly via idp.wikimedia.org, running CAS-SSO). However configuring SSH public keys for production servers (as opposed to Toolforge/WMCS) is managed in Git and typically managed via a Phabricator task.

Future

On the Wikimedia IDM landing page, the user gets offered the choice to create an account or login. When creating a new account, the following values can be set:

Wikimedia Developer account name
Given name or pseudonym
Email address
Password (needs to be given twice) (enforced with a password policy)
MediaWiki SUL (shared unified login) account name (The user must verify ownership of the SUL account)

After submitting an account request, the account would be put on hold until a confirmation email is received by the user and a confirmation link is clicked. This makes an email address mandatory, but it seems like an acceptable tradeoff given that it’s important to have a reliable communication channel to the user (e.g. in case of an account compromise, to announce invasive maintenance etc.). Anyone who for some reason does not wish to reveal their primary mail address, can still create a secondary one.

With account creation a numeric user id (UID) will be allocated for the user as well.

Modifying account settings

Status quo

Currently some basic attributes (e.g. email address, SSH keys used for Cloud VPS) can be modified using the Preferences dialogue in Wikitech.

Future

Once the user has logged in the first time with the confirmed account name, additional attributes can be configured to the ones required for account creation, some examples:

Given name or pseudonym
An optional user affiliation (could be “Wikimedia staff member”, “Community member with NDA”, ”Researcher working with Wikimedia under MOU (Memorandum of Understanding)” and others. Depending on the affiliation some attributes are mandatory or not
Email address (mandatory, changing it re-triggers the confirmation mail)
Password change (needs to be given twice) (enforced with a password policy)
MediaWiki SUL account name
IRC username
Cloud VPS SSH key

For all changes a history be logged (within reasonable limits, e.g. with setting were changed at what time)

Gaining additional access needed for a role

Requesting and granting access to additional LDAP roles and/or shell group access.

Status quo

Let’s consider the new Wikimedia staff member who starts in a Wikimedia department which needs to access the Hadoop cluster and various PII-sensitive web services, such as Turnilo.

After enabling the account the staff member reads lengthy instructions and opens a Phabricator task tagged User-Access-Requests. This ends up on the radar of someone within Site Reliability Engineering which operates a weekly rotation called Wikimedia Clinic Duty. The ticket is processed and the following steps are taken:

Validate that the user is a WMF staff member
The user needs to approve the “Acknowledgement of Wikimedia Server Access Responsibilities” by accessing https://phabricator.wikimedia.org/L3 and confirming it (and the SRE handling the access request needs to confirm it)
Get confirmation from the person’s manager (after figuring who the person’s manager is)
Get confirmation from the service owner of the service to request access for (here the Data Engineering team which operates Hadoop)
The user needs to provide separate SSH public keys for the SSH access to the Wikimedia production cluster
Since the LDAP does not contain a full name, the full name needs be provided (or alternatively a pseudonym in select cases)
If the person is a contractor or a researcher with a time-limited contract/MOU the designated end date needs to be noted (along with a point of contact who to ping when the end date is nearing to check for extension or account revocation)

Once all the data is in place, access to the cn=wmf LDAP group is granted by the SRE (by running a CLI tool or using the OpenLDAP tools). This enables access to Turnilo and other services guarded by that group.

The SRE handling the access request pushes a git change against a YAML data structure maintained in the Puppet git repository, which adds the new SSH key for the user (along with the rest of the data provided on task) and adds the user to the access group which enables Hadoop (here “analytics-privatedata-user”).

Future setup

After logging into Wikimedia IDM: In addition to the base attributes, the user can request access to “account profiles” (this is an interim name, “role” seems like a more fitting name, please leave further feedback in the talk page) which enable additional attributes which can be configured. Adding/removing an account profile can also add/remove a user from an LDAP group.

Every profile can declare a validation module which checks internal state (e.g. for the SSH keys it’s checked that certain key type requirements are upheld and that the Cloud VPS keys are distinct from the production keys). Every profile has a group of owners/administrators. If someone asks for a specific profile it can either be granted automatically (e.g. in the case of SSH access to Cloud VPS) or the request is added to a queue where it needs to be approved or rejected by the team or person managing a profile. The profile owner can also leave comments, e.g. to communicate that additional steps are necessary.

For the specific example of Hadoop access, the user would log into the Wikimedia IDM and request the “Hadoop” role. This would cause the following internal steps:

If the user affiliation is “WMF staff” or if there’s a pre-existing NDA (e.g. for a researcher or has a community NDA), all is fine and we proceed. Otherwise, they are asked to initiate the NDA process (description is out of scope for this section)
It gets validated whether the “Acknowledgement of Wikimedia Server Access Responsibilities” are approved by the user and otherwise is asked to “sign” them.
The person’s manager gets a notification via email and is asked to confirm that the user should have access to Hadoop (happens by logging into the IDM and confirming)
The service owner for Hadoop manager gets a notification via email and is asked to confirm that the user should have access to Hadoop (happens by logging into the IDM and confirming)
It’s checked whether the user provided SSH public keys for the SSH access to the Wikimedia production cluster and otherwise is prompted to provide them
The IDM generates a Puppet patch against the YAML structure in Wikimedia Puppet and the resulting patch is reviewed and merged by an SRE member.
If LDAP access is also requested (which would be the case for Hadoop), the user gets added to the respective LDAP group.

Disabling an account

Status quo

Access is revoked under the following circumstances:

A WMF staff member departs to a new position
A time-limited access expired because the project is completed (e.g. a MOU for researchers or an internship or a short term contract for some work)
A community member is no longer interested in contributing
As an emergency measure for security reasons (e.g. a stolen laptop or indications of account compromise)

The current removal policy is that the account itself it kept (since anyone leaving access may still use the account for volunteer work. As such, the current removal process only strips the parts of access which:

Grant access to the Wikimedia production systems
Grant access to PII-sensitive groups in Phabricator (e.g. tasks which may contain user data)
Grant access to PII-sensitive groups in LDAP (such as the group enabling Turnilo)

The removal of access credentials happens via a CLI tool run by SRE (offboard-user) and - (if SSH access needs to be revoked) via an additional Puppet patch against the YAML structure mentioned above.

Intended new workflow when all workflow steps of the IDM have been implemented. Not all the features will be implemented at once/immediately, so there will be a mix until all the bits are in place.

Future setup

If access is to be removed this can be triggered by multiple events (e.g. By the Talent & Culture department of the Wikimedia Foundation notifying about someone departing their job) and the removal happens by an administrative account in the IDM.

By default only sensitive access is stripped (as listed above), but there is also an option to disable an account (by stripping all attributes and marking it as disabled, but ensuring that the UID is never reused).

This can be used e.g. if someone indicates that they’ll never use it again or if an account was created maliciously.

Removing an account makes the necessary changes in LDAP and if SSH shell access is involved, generates a patch against the LDAP structure which gets reviewed and merged by an SRE.

Bug reports and feature requests

See phab:tag/bitu in Phabricator.

Runbooks

See: IDM/Runbook

External links