Linking TC to external authentication services

ideas.md

Anonymous

• create a well-known clientId anonymous with a well-known accessKey (in the sense that it's in cleartext on the client side of tools.taskcluster.net); when not using some other credential, that's the credential tools uses.

Client Creation

• Allow user-driven creation of new clients (limited to some suffix by a scope that's defined in assume:client-id:anonymous)
• Allow association and dissociation of credentials with individual external users (GitHub, Mozillians, LDAP, Persona)
  • Most users will only create one clientId, and just leave it in localStorage
  • Those who can edit roles can also create clientIds that are not associated with a user and thus not at risk of being disabled if that user leaves

Arbitrary Linking

Morgan has suggested the ability to link TC credentials to an arbitrary service. That is, it should be possible to use some other app than tools.taskcluster.net to associate some external userid with taskcluster credentials. If that app wants to also handle automatic revocation, then it will need to run some kind of service and revoke credentials that way.

Internally, that could be implemented with an extra layer of indirection: a Client has a set of links, each named with the link type ("github", "moz-ldap", etc.). Each Link has a set of roles (names). The Client's roles are, then, the set of all linked roles. Each link service would have scopes to view and update Links with its name.

We can incorporate a few of these link services into tools, but not preclude the others. So we can have a GitHub service that handles OAuth to create a new link, and periodically polls GitHub to determine a user's access, adjusting the linked roles apprporiately. And a "moz-ldap" service. And the Apache foundation can run an "apache-ldap" service similar to ours, having only requested from us a credential that can edit "apache-ldap" links and with the scopes we are comfortable with Apache issuing to its users.

Best of all, we can have links that never expire that we can use for infrastructure -- so infra clients don't expire if Jonas's LDAP account gets disabled.

user-stories.md

I want to use my browser to edit the secrets for my github repository, djmitche/uthreads

In tools.taskcluster.net, I select the "Log In" button in the upper right. The page says that I have no available credentials, and offers to create a new one for me.

I click to create a new credential, named "uthreads" and the page now says that I have one credential ("uthreads") and it is active, but clicking on it to view the scopes I see that it does not have much - in particular, no "secrets:set:github-repo/djmitche/uthreads", which is what I want.

I click the button to link this credential to GitHub, and complete the GitHub OAuth sequence. The scopes now show, among other things, the scope I want.

---

I want to set up a new, Mozilla-owned service that should outlast me, and needs to be issued a clientId

---

I want to create a set of credentials with very limited scopes that can create a certain kind of task, but does not have access to everything that my LDAP credentials grant

@djmitche, My initial approach is a bit more naive... I like not having state that we need to synchronize with external sources... Granted I fear we might need to support this... Well it depends...
There is a lot of power to only giving users temporary credentials... (not saying they can't be allowed to create permanent clients either). But for the default flow I like temporaries, because we can force expire them in say 3 days, and not have people putting permanent credentials in the browser.

I don't want to reinvent user management, then we have to add things like 2FA, synchronize with external databases... etc.. It's a lot of pain and work that's been done before. Goal is for TC credentials to put APIs before users with an identify. That said I see two short comings of the current approach:

1. The amount of scopes a single temporary credential can carry is limited, heroku can handle 8kb headers, and carrying around more is crazy anyways... I'm not sure just how big this problem is..
2. Auditable access logs, is hard as we don't really give any identity to temporary credentials... We could do this by some trick like saying clientId: <clientId>/<id>, so we append clientId with /<id> when creating temp credentials...
3. intermediate trust... When index is called by worker using task.scopes, the index has to trust that the queue checked the scopes of the caller that created the task.
4. We can't create temporary credentials with temporary credentials.... Granted it might not be feasible to drag around a long certificate chain :)

With respect to making fine-grains scopes, we would need the parameterized roles, I don't think we should want this, as it's better to make team based roles. I understand that a service may have a single owner, but the services should be coupled to a team that can take over when that guy moves on...

I think (1) and (2) needs to be solved at some point. (3) and (4) would be really nice to solve. Neither of them have to be solved now... Well, we can see... We'll certainly get much further with what I just filed a PR for... but yeah, it won't solve all problems.

Note: I would prefer it if TC creds were focused on protecting scoped resources, and not authenticating people. Hence, making it suitable for APIs as oppose to users... But IMO the goal is to optimize for automation :)