1427866 - Make github, google logins work

Status: RESOLVED FIXED

(Taskcluster :: Services, enhancement)

Description

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

Just before the all-hands, Auth0 stopped allowing users who have linked accounts (in Mozillians) to login with any method other than the "primary".  That primary method is usually github.  But we didn't allow usrs to login with Github.  So they were locked out.  Boo.

I asked the IAM team to allow Github and Google logins for tools, and they have.  But if you login with one of these methods, you don't get much in the way of access.

Our hand is sort of forced here: we need to allow people to login with github and google, and at least give them mozillians-related scopes.

Comment 1

[Hassan Ali (:hassan)]

Dustin, I'm thinking of tackling this. 2 questions come to mind:

1. For the mozillians-related scopes is there an existing role that covers basic mozillians scopes?
2. Which taskcluster repository takes care of adding roles/scopes to users? Simply trying to see which repositories I should be messing with.

Thanks!

Comment 2

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

1. Yes, the `mozillians-group:..' roles correspond to mozillians groups.  Similarly `mozillians-user:<username>' corresponds to a specific Mozillians user, and `mozillians-unvouched` has scopes for un-vouched users.  I don't think the last one is much used and isn't very important.

2. This would happen in taskcluster-login.

I don't really have a solution in mind here, so the sky's the limit!  There are a few concerns:

We currently issue clientIds of the form `email/<some-address>`.  The client editor uses that as a prefix under which users are allowed to create their own clients.  Login then checks that those clients do not have scopes they shouldn't in a periodic check.  So if we change those clientIds, we will invalidate those existing clients.  Luckily, there are only a handful, and the most recent was used 2 months ago, so this is probably OK.

So maybe it makes sense for someone logging in with github to get clientId `github/<username>` instead?  For google and passwordless logins, I think we should stick with `email/<address>` as that's all we really know.  Users with @mozilla.com addresses won't be allowed to login with Google -- they'll be forced to use LDAP.

So, for someone logging in with github, I'm not sure how best to check with Mozillians.  Right now we take an email address and look up its groups.  But I don't think we get a reliable email for github accounts.

More importantly, I think the Auth0 profile now contains enough information to add those groups *without* consulting the Mozillians API at all.  In fact, I think it contains enough information to not contact LDAP, either.  Fixing that would help the service's speed and reliability quite a bit.

There are three components in the login service right now:
 - handlers -- take an OIDC access_token and generate a User object
 - authz -- take a User and attach roles to it (so there's a Mozillians authz and an LDAP authz)
 - authn -- authenticate users (this is the interface Treeherder uses right now)

Right now I have things set up so that the mozilla-auth0 handler just sets the User's identity property; the authz then use that identity to look up the user in LDAP and in Mozillians.  I did this because the data in the profile from Auth0 wasn't stable at the time, and because I had to keep supporting the authz stuff for Treeherder.  Soon neither of those will be the case anymore.  At that point, I think we can delete both authz and authn, and add support in the mozilla-auth0 handler for figuring out the TC roles to assign for a user based solely on the contents of the profile from Auth0.

OK, that sounds like a lot, but the thing I've left out is setting up roles for users based on their github permissions -- either what teams they are on, or what repos they have access to.  I only bring that up to say, let's *not* think about that right now.  This bug is just to allow people to *authenticate* with Github, but still get roles based only on LDAP and Mozillians groups.

Comment 3

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

To be clear, I think the right way forward here is to convert login to generate all roles based on the content of the profile it fetches from the management API, and not use the authz stuff at all.

This will get us away from depending on LDAP and Mozillians queries, and make credential renewals a lot faster to boot.

It might be necessary to call the "Person API" to fetch the profile instead, but hopefully we can stick with the existing code to fetch from the Auth0 Management API.

Comment 4

[Hassan Ali (:hassan)]

https://github.com/taskcluster/taskcluster-login/pull/71

Comment 5

[Hassan Ali (:hassan)]

Dustin, any thoughts on when we should proceed with the merge?

Comment 6

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

I don't think there's anything holding us back.  I wonder if this is a good time to set up a staging instance of the login server?

Comment 7

[Hassan Ali (:hassan)]

We have a staging instance now.

Comment 8

[Hassan Ali (:hassan)]

Live on staging.

Comment 9

[Hassan Ali (:hassan)]

Promoted to production.