Github-related roles on login

[djmitche]

When users login with a github(-associated) account, they should get scopes accorded to the repos to which they have access.

[petemoore]

This is a great idea. Just to be explicit (as it kind of goes without saying) this should include repo-specific cancellation scopes. See e.g. bug 1354067 where this came up recently.

[djmitche]

This will be more practical after #9, but will need some further development and discussion on exactly how we do it.

We have discussed creating short-term clients, rather than temporary credentials, since those clients can contain more scopes than can be fitted into an HTTP header. Even so, enumerating all of the repos to which a user has access may be a herculean task, and we need to think about security too.

[djmitche]

#9 turned out to not really help this along at all. We can support logins with github, but not linked logins so you can have one session with both LDAP-related and github-related scopes.

[djmitche]

Brian, should we leave this open for @owlishDeveloper to make a proposal from?

[imbstack]

Yep, but of course we will help through the whole process!

[owlishDeveloper]

imma read through this tonight or tomorrow morning!

[petemoore]

The docs for schedulerId from queue.createTask state:

All tasks in a task group must have the same schedulerId. This is used for several purposes:

• it can represent the entity that created the task;
• it can limit addition of new tasks to a task group: the caller of
  createTask must have a scope related to the schedulerId of the task
  group;
• it controls who can manipulate tasks, again by requiring
  schedulerId-related scopes; and
• it appears in the routing key for Pulse messages about the task.

I think this is rather overloaded, but the third bullet point seems to me to be the most valuable use of schedulerId. If we consider the schedulerId to be a top-level global identifier for a project, we quickly see that it can be used to neatly partition tasks into projects enabling per-project scopes.

The range of values allowed for schedulerId is currently rather limited (^([a-zA-Z0-9-_]*)$, 22 chars long - soon to be extended to 40), but even with this, consider the case of using it to identify a github project.

Tasks created by taskcluster-github currently all have "schedulerId": "taskcluster-github", regardless of the repo that the task is created for.

If tasks created for repo github.com/foo/bar were to have (e.g.) "schedulerId": "github-foo-bar", then to cancel a task, a client would need to have queue:cancel-task:github-foo-bar/<taskGroupId>/<taskId> rather than queue:cancel-task:taskcluster-github/<taskGroupId>/<taskId> so it would be relatively straightforward to grant queue:cancel-task:github-foo-bar/* to roles/clients that should be able to cancel any task for only this repo. They would then not be able to cancel tasks for other github repos, as they currently can now.

Similarly, we could apply a similar principle to other task generation services, such as mozilla-taskcluster, or whatever we use these days for generating tasks for hg pushes. I believe at the moment we already do this with gecko repositories (gecko-level-{level}) but e.g. nss push tasks have a more general "schedulerId": "task-graph-scheduler" rather than e.g. nss or nss-try.

---

Edit: this comment has been moved to issue #143

[djmitche]

Good thinking! BTW, extension to 40 chars is #139.

You (@petemoore) mentioned "authority vs. identity" in irc, too -- and I think that's a good thing to think of here. A schedulerId should identify a class of tasks that some clients have authority to create or manipulate, rather than the "identity" of the thing that "scheduled" the task.

It'd be nice to have a way to issue "arbitrary" schedulerIds, too. For example, maybe the NSS team want to be able to schedule and cancel NSS-related jobs, not all of which come from the same github repo. So we should have some role-based way of creating and granting to them scopes for schedulerId project:nss/* or something like that. Doing so would avoid the need to create "personal" schedulerIds for individuals -- which is good, since the login identities we issue to people are often over 40 characters alone.

I think we'll need to find some options for handling github repo names that are too long. It might be something ugly -- perhaps if gh:<org>/<repo> is too long, then we take a 31-character prefix of that and append an 8-character hash of the remaining characters? Then https://github.com/djmitche/some-really-super-long-repository-name-with-extra-notes would become gh:djmitche/some-really-super-l|abcdef12. We'd need to make sure that the hash is secure so that people can't invent repo names that will generate hash collisions.

[djmitche]

We (@owlishDeveloper, @imbstack, and me) had a lot of discussions about this in the process of building a GSoC project which did not end up happening. Notes are in this googly doc but to summarize:

Logins

GitHub hosts both "OAuth Apps" and "Github Apps", and either can support user login. We already have a GitHub app. However, that app has lots of permissions and is too powerful when used for logins -- for example, a user logging in via that GitHub App allows the app to make comments on issues as that user. So, we should use a distinct OAuth App to support logins. That has a better UI for allowing access to different orgs, too.

The login process is a normal OAuth2 process, and ends with an access token which can be used to make some API calls on behalf of the user. In particular, it allows "get all my teams" and "get all my org memberships". From those, we can make a Taskcluster client with roles for each team and for each org of which the user is an admin.

Cancellation

We didn't reach any conclusions on this

Third-Party Logins

We have a few options

• implement a process of our own similar to OAuth2, but ending with the third party getting Taskcluster credentials instead of an access token:
  • third parties would register and get a client_id and client_secret
  • redirect to a Taskcluster URL with ?state=..&redirect_uri=..&client_id=..
  • Taskcluster gets the user's consent, checks scopes, etc.
  • Taskcluster redirects back to the redirect_uri with ?state=..&access_code=..
  • third party makes a POST request to Taskcluster with client_id, client_secret, and access_code, and gets back a set of Taskcluster credentials
• use the existing client-creator process that we use with taskcluster signin