1319152 - Add a scope that always has just the user's email address

Status: RESOLVED WONTFIX

(Taskcluster :: Services, defect)

Description

[Cameron Dawson [:camd]]

I know there are some cases where the user won't have an email address, and that can be blank.  But at least for most cases, the user will have an email.  It would be great to have it in one uniform scope, rather than mozilla-user or elsewhere, depending on who they are.

Comment 1

[Ed Morley [:emorley]]

Just to call this out explicitly: this scope must only include email addresses whose ownership has been verified, and not whatever the user might have provided via some unverified Mozillians field etc.

It would be great if this field were set for Auth0 too - since at the moment as I understand it we don't get their email? (Perhaps we should file this as another bug?)

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

I don't think this is the right way to go.  Fundamentally, we're in the business of *authorization*, not identifying people.  TC credentials are not necessarily tied to a person.  The intent of bringing treeherder together with taskcluster was that eventually all authorization in treeherder would be based on the TC credentials' scopes, and the clientId would just be a pretty string in the corner of the page -- this is how tools.taskcluster.net works.

I suspect this request is coming from a divergence from that intent -- perhaps driven in part by the Django admin console, which probably can't be modified to use TC credentials.  I think this is also based on the reversal of plans to use TC for authorization in favor of an MVP using some hacks to achieve only authorization.  So what you have now is minimally viable :)

We've toyed with the idea of attaching an optional "identity" field to temporary credentials, probably authorized by a scope, that could be interpreted by the login service to generate an identity.  But that gets mixed up in all kinds of issues of aliases, linked identities, differential trust of authentication mechanisms (e.g., if I use passwordless login for `[e-mail]` that's not the same as LDAP + Duo), etc.  We are not the team to deal with those complexities.

I think that if you are really looking for authentication, you should be working with the IAM team.  If you then *also* need TC credentials associated with the user you have authenticated, we can provide an API that can exchange an OIDC id_token or access_token for temporary TC credentials.

On the other hand, if you the goal is a situation where the credentials are used directly for authorization (rather than authorizing based on stored permissions keyed by an authenticated identity), then this is but a temporary setback along the way and the fix is to continue to work toward that goal.

As a short-term fix, you can use the clientId.  I've indicated that's not suitable for authentication, and it's not, but maybe the risk is low enough?

Comment 3

[Ed Morley [:emorley]]

We absolutely do want to switch to using TC scopes for determining authorisation.

However we still need to retain user identities on Treeherder's side, since they are used for:
1) user profile type things (eg long lived preferences, notification settings for future "notify me when my tier 3 job starts failing on inbound" features, ...)
2) mapping user actions to Treeherder data (eg someone marking an automatic classification as triaged)
3) Users requesting Hawk credentials for automation submitting to Treeherder's API (though I guess some of this could be ported over)

This still requires that we have a way to maintain a relationship between a user and whatever assertion login.taskcluster.net generates.

Comment 4

[Ed Morley [:emorley]]

I guess I'm just a bit confused here. Our intent hasn't changed at all - we have always intended to use solely TC for authorisation (and will shortly), however that doesn't mean we were ever wanting to loose visbility as to the authentication part in the process.

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

We've had a few discussions which, I think, have settled this matter and indicated a good path forward for treeherder.

Comment 6

[Ed Morley [:emorley]]

For those wanting to follow along, the work for that will be happening in bug 1319246 :-)