You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org
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 wikitech 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.
|As Is||To Be|
|Account creation||Account creation currently happens via a MediaWiki extension (TODO: Figure out the exact name and a link to the MW extension) which is installed on the servers running https://wikitech.wikimedia.org. This MediaWiki installation is different from the main MediaWiki installation powering the wikis, but there’s the intent to eventually make wikitech a standard wiki like the rest
TODO: find the Phab task to merge wikitech to SUL and main wikis.
This account creation mechanism applies both to community members, but also to staff members of the Wikimedia Foundation who are working in a technical capacity.
The user ID used is also the same user ID that is going to be used when logging into the Wikimedia production clusters (which is done by WMF technical staff and community members), but the configuration of SSH access isn’t configured within the extension and needs a separate Phabricator task (see next section).
|On the login to the Wikimedia IDM page, the user gets offered the choice to create an account or login (see next section).
When creating a new account, the following values can be set:
After submitting an account request, the account would be put on hold until a confirmation email is received by the user and some 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 mail address to us, can still create a secondary one. With account creation a UID is allocated for the user.
For all changes a history should be logged (within reasonable limits, e.g. with setting were changed at what time)
|Gaining additional access needed for a role (LDAP and shell group access)||Let’s consider the new user is working 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 opens a task within Phabricator 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:
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”).
|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 comments) 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:
|Disabling an account||Access is revoked under the following circumstances:
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:
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.
|If access is to be removed this can be triggered by multiple events (e.b. 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.
When linking SUL (Single Unified Logins) with IDM accounts, validation is required. This is to be done, to avoid having unclaimed SUL accounts linked to fraudulently IDM accounts.