- Users should be able to login easily to the tools site to carry out day-to-day tasks.
- Users should be able to create and manage limited-access permanent credentials for use in their own automation
- Permanent credentials tied to users should be disabled when those users lose the relevant permissions
- All services have a consistent, reliable way to log who or what is making a particular request.
Identity providers manage subsets of clients:
- github (managed by tc-github)
- moz-ldap (managed by tc-login)
- mozillians (managed by tc-login)
- permanent (not synchronized against anything)
Each identity provider has a name (identityProviderId) and defines a namespace of identities (identityId).
Each identity provider is responsible for all clientIds beginning with <identityProviderId>/*, and each user identified by a provider controls <identityProviderId>/<identityId>/*.
The API itself does not recognize this pattern, and just considers as clientIds opaque identifiers.
The structure is a matter of convention, described in the namespaces document and enforced with scopes.
Identity providers can involve external services to manage clients they are responsible for.
Services which interact with an external authorization service such as Okta will have a minimal UI to handle this.
Although hosted separately, the UI only interacts with the tools site.
Upon successful authentication, this UI redirects the user back to the tools site, providing temporary credentials with clientId of the form <identityProviderId>/<identityId>.
The temporary credentials contain the scopes accorded to the identified user, as well as permission to manage clients with the prefix <identityProviderId>/<identityId/.
For example, the temporary credentials supplied by the moz-ldap identity provider can have client-id moz-ldap/sue@mozilla.com.
Aside from authenticating users, each identity service can also periodically scan the clients associated with its identityProviderId and verify that they are still satisfied.
If not, the service can disable the client (and later re-enable it if its scopes are satisfied).
The "permanent" provider does not do any authentication or expiration -- it exists merely as an identity group to prevent either of these from occurring.
Users of the tools site have a consistent view of the sets of credentials available to them.
Each set has a name -- its clientId, and a set of scopes, and some other metadata.
The tools provide convenient means for manipulating these identities: creating them, using them for other operations, even sharing with other sites.
To allow users to edit client scopes, we move the scopes into the clients table. This avoids the need to manage permission to edit roles attached to clients associated with a particular identity, which is complex and subject to race conditions.
- clientId: no change
- scopes: [..] -- moved from role
- disabled -- new
- description, details, etc.
Client scopes will be calculated as the union of client.scopes and assume:client-id:<clientId>, allowing delegation of scopes to other users via role editing.
client- no changelistClient- grows the ability to filter by prefix (clients are kept in memory so table scans are not an issue)createClient- takes a list of scopes; caller's scopes must satisfy those scopesresetAccessToken, etc. no changeupdateClient- modifying scopes requires posessing all of the newly-added scopes, as wellauth:update-client:<clientId>.
New, useful API methods
auth.enableClient(clientId)auth.disableClient(clientId)auth.expandScopes(scopes)-- expands any role assumptions in a scopesetauth.currentScopes()-- returns the scopes from the caller
Temporary credentials can include an issuer in the certificate which identifies the client that created the credential, defaulting to the credential's clientId if not supplied.
When the issuer is supplied, the credential's clientId need not correspond to an actual client.
However, the issuer must have auth:create-client:<clientId>.
From a user's perspective, the browser interface to TaskCluster is the tools site and nothing more. Users do not need to know that TaskCluster is composed of multiple distinct services. In particular, there is no need to grant access from the "login" service to the "tools" service.
The tools site knows about the available login mechanisms, and displays them in the "login" screen.
Tools will have a more substantial means of displaying the current credentials, including describing whether they are temporary or not, expiration time, and what scopes they grant. This will include links to documentation (which will need to be written) about credentials, credential types, scopes, roles, expandedScopes, and so on. This is not the default view, though: most users need not be concerned with what their scopes are, as long as those scopes permit them to do what they want to do. The page banner will, however, display the current identity as well as its expiration time.
The UI will be able to store multiple credentials and switch between them (so e.g,. you can login with your SSO and Mozillians identities and swap between them easily). It will also purge credentials immediately when they expire, and inform the user of this change.
Tools will continue to support installing a regular old clientId and accessToken as stored credentials,
This will be useful for people whose group membership gives them lots of scopes, so that they can perform day-to-day tasks with a more restricted set of scopes.
The tools site will provide a shortcut to create a new client and "login" as that user, serving the purpose of a "remember me" checkbox. This will be available and explained clearly in the login landing page, when the current credentials are temporary.
Manual logouts will be complete, destroying all stored TaskCluster credentials as well as all information about third-party logins (e.g., SAML assertions).
The site will not have an option to automatically logout when the session closes -- this adds another layer of complexity for users.
In the tools UI, the Client Manager will, by default, only show clients associated with the current user's identity (by prefix matching based on the credentials' clientId).
Viewing all clients is an option for anyone; the default view merely helps users focus on what they can control.
Roles for users who have permission to manage permanent clients for a project will have scopes like:
auth:create-client:permanent/<project>-*auth:update-client:permanent/<project>-*auth:delete-client:permanent/<project>-*auth:reset-access-token:permanent/<project>-*
Roles for users who have permission to manage other roles will have scopes like:
auth:create-role:<role>auth:update-role:<role>auth:delete-role:<role>
For example, members of the releng project might have
auth:<verb>-role:hook-id:project-releng/*
An identity-provider service will have a permanent client with the following scopes:
auth:create-client:<identityProviderId>/*auth:update-client:<identityProviderId>/*auth:enable-client:<identityProviderId>/*auth:delete-client:<identityProviderId>/*auth:reset-access-token:<identityProviderId>/*assume:<role>for all roles associated with the identity group (e.g.,assume:mozillians-group:*for the mozillians identity provider)
auth:create-client:<identityProviderId>/<identityId>/*auth:update-client:<identityProviderId>/<identityId>/*auth:delete-client:<identityProviderId>/<identityId>/*auth:reset-access-token:<identityProviderId>/<identityId>/*assume:<role1>, etc. as appropriate to the user's access
The TaskCluster team will have
auth:create-client:*auth:update-client:*auth:delete-client:*auth:reset-access-token:*auth:create-client:permanent/*auth:update-client:permanent/*auth:delete-client:permanent/*auth:reset-access-token:permanent/*auth:create-role:*auth:update-role:*auth:delete-role:*
Alice loads the tools service, and the brower-side code finds no credentials, or expired temporary credentials, in localStorage. Alice clicks "login" and selects "Mozilla SSO" (or similarly "Mozillians" or "Github"). She is taken through the typical SSO login process and returns to the tools page where she began, with a banner overlay indicating that she is now logged in using temporary credentials.
To double-check her permissions, Alice clicks the user icon in the navbar.
The resulting page shows that she is using temporary credentials, her "identity" (moz-ldap/alice@mozilla.com), and the set of scopes she is granted.
Outcome: tools has temporary credentials based on Alice's groups.
After logging in above, Alice wants to establish a set of credentials that will last longer than a few days.
User-information page, she clicks "Create My Client".
The resulting page provides a suggested clientId (moz-ldap/alice@mozilla.com/tools-login) and a set of scopes pre-filled with her current scopes.
She clicks "Create And Login", and is brought back to the user-information page with a banner overlay indicating that she is now logged in with permanent credentials and displaying an accessKey she can record for later use.
After dismissing this page, the user-information page displays two sets of credentials, with the new permanent credentials selected.
Outcome: Alice is logged into tools with credentials that will not expire.
Barbara loads the tools service, and the brower-side code finds no credentials, or expired temporary credentials, in localStorage. Barbara clicks "login" and selects "ClientId/AccessToken". She is prompted for a clientId and an accessToken. There are options for a certificate and to limit the available scopes. She enters these, clicks "login", and returns to the tools site.
Outcome: tools has credentials, optionally including a certificate with authorizedScopes or temp creds
Helen is using a shared computer to access TaskCluster to take care of something for a co-worker. She has already logged in using the SSO method, above, and completed the task. She clicks the "logout" button on the menu bar. She is taken to a landing page indicating that she is completely logged out and connected to tools anonymously. Just to check, she clicks "login" and selects "Mozilla SSO" and is prompted for a username and password just as before -- her information does not appear.
Outcome: none of Helen's identifying information remains on the shared computer.
Maya has been working with TC for a few days now, submitting ad-hoc tasks as she works to develop a new in-tree task definition. This morning, exactly 72 hours after she last logged in, she sees a popup message that she is now logged out and must login again, with a link to do so. The user display in the corner changes to indicate that she is logged out. The popup mentions that she can use a permanent credential to avoid these frequent logouts, with a link.
Outcome: Maya is actively informed when her login expires.
Pete is building a service to integrate with TaskCluster, and needs credentials for testing the service locally and in Travis.
She loads the tools service, which is already logged in (above).
Using the ""Client Manager" tool, Pete selects "Create Client" and enters a clientId, description, expiration, and a set of scopes (a subset of the scopes she is logged in with).
When she clicks "Create", a popup provides her with the selected clientId and an accessToken, with a warning that the accessToken will not be shown again.
She records this information in the necessary configuration files.
Outcome: tests run with minimum-privilege credentials which are good until they expire or Pete's group membership no longer satisfies them
Fatima is supervising a QA analyst, Eileen, who needs to download private task artifacts to carry out tests on them.
This analyst is on a short-term contract and does not have an LDAP account or Mozillians account.
Fatima uses the Client Manager to create a new client, named moz-ldap/fatima@mozilla.com/qa-analyst-eileen, with expiration date set to the contract expiration, and with the get-artifact:private/build/firefox.exe scope.
She provides the resulting accessToken to Eileen through a secure channel (OK, she uses email..).
Eileen follows the "Tools Login (clientId and accessToken)" process, above.
Outcome: Eileen can access task artifacts and no more, and only for the duration of her contract with Mozilla.
Pete is ready to deploy her service, and needs credentials that will outlive her time on the team (not that she's thinking of quitting..). She files a bug requesting permanent credentials, giving the required list of scopes. Dorothy, a member of the TaskCluster team, evaluates the bug, requesting a vouch if necessary and verifying that the scopes are appropriate, Dorothy uses the tools site to create a new client similarly to the approach Pete used, but selecting "permanent:dorothy@mozilla.com" for the client's identity. She provides the resulting clientId and accessToken to Pete through a secure channel.
Outcome: Pete has credentials for her service that are not tied to her identity.
Ellen works on Webmaker, and the CI tasks for Webmaker require a new scope.
Ellen's membership in the Webmaker LDAP team already grants her this scope as well as permission to update the role for the Webmaker repository (auth:update-role:repo:github.com/mozilla/webmaker-core/*).
Ellen loads the tools service, which is already logged in (above).
Using the "Role Manager" tool, she selects the repo:github.com/mozilla/webmaker-core/* role, edits it, adds the new scope, and clicks "Save Changes".
Outcome: tasks based on the webmaker-core repository now have the desired scope.
Janice is a member of the Rust team, and is working with Kat, a trusted contributor, on creating some new task definitions for fuzzing which run on a particular worker type.
Kat, who is logged in via her mozillians profile, needs the scope queue:create-task:aws-provisioner-v1/rust-fuzzer in order to run test jobs from the task inspector.
Janice creates a new curated mozillians group including Kat, "rust-fuzzing", and requests that this group be linked to TaskCluster and that the team_rust LDAP group be given scopes to manage it.
A TC Administrator does this, granting auth:update-role:mozillians-group:rust-fuzzing to mozilla-group:team_rust.
Janice then grants queue:create-task:aws-provisioner-v1/rust-fuzzer (and a few more scopes she finds necessary soon afterward) to this mozillians group.
Outcome: Kat has the access she needs, by virtue of her Mozillians membership, and the process will be even easier for the next contributor.
NOTE: this process requires some administrator intervention, but nicely avoids
- Allowing Janice to grant scopes directly to Kat (which could result in a mess of per-person scopes)
- Allowing Janice to grant the
queue:create-task:aws-provisioner-v1/rust-fuzzerto all roles (which could result in pollution of unrelated roles and much confusion)
Guadalupe is using a command-line tool she found on the 'net to update some secrets in the secrets service. She wants to grant the tool permission to write those specific secrets, but not to read all of the secrets she has access to.
When she runs the tool, it automatically opens a page in her browser on the tools site, which displays the set of required scopes and asks for approval. Guadalupe checks the scopes and the expiration time (3 days from now), then clicks "Approve". The browser displays a "success" page and the tool proceeds to upload the secrets.
Alternative: if Guadalupe is running this tool on a system without a web browser, then the tool displays a link to click on and prompts Guadalupe to paste in the credentials object. When the request is approved, the success page includes a block of characters (similar to a GPG message) and instructions to copy/paste them into the tool.
Noreen is watching her try job on treeherder, and has discovered a bug that renders some of the other tasks unnecessary, so like a good Mozillian she would like to cancel them. She selects the jobs in treeherder and clicks the cancel-task button. Since this is the first time she has done this recently, treeherder opens a new window with a taskcluster page asking Noreen to select credentials to share with Treeherder. Noreen was not already logged in on the tools site, so the page suggests that she login first, then approve the request from Treeherder. When she is done logging in to TaskCluster, she sees the same page, but now including her credentials. She clicks "Grant" and the window closes returning her to the treeherder page where the cancel operation proceeds as before.
Outcome: Noreen can use her TaskCluster credentials from the Treeherder application.