Closed Bug 1256736 Opened 8 years ago Closed 7 years ago

Support federated logins from the tools site

Categories

(Taskcluster :: UI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dustin, Unassigned, Mentored)

References

Details

If other sites (like treeherder) want to integrate with TaskCluster authentication, right now they need to redirect their users to https://login.taskcluster.net with a return URL.  The user then signs in with one of the available methods, and is presented with a "Grant" button that will return them to the original site.

In terms of user experience, this is confusing and backward.  By comparison, for a Github or Facebook login, the user sees a familiar page layout and URL asking "hey, this other site wants something from you - is that OK?".  In the TaskCluster case, a weird-looking page on a weird URL is saying the same thing, which is harder to trust.

A better solution would be to have the tools site itself do the granting.  So treeherder would send the user to https://tools.taskcluster.net/get-credentials?return=https://treeherder.mozilla.org which would present a page that looks like other tools pages, prompting the user to grant access.  If the user needs to sign in first, that's fine - they can click the "sign-in" button in the corner, do the normal process, then come back to the login page (without even having to click "Grant").

This is the last awkward wrinkle to iron out to make TC auth a truly useful tool for lots of developer-oriented mozilla services.
The last bit (removing the grant) already has a PR written:
  https://github.com/taskcluster/taskcluster-login/pull/9
although it needs to be rebased..
Assignee: nobody → dustin
Depends on: 1267249
I'm still keen to work on this, but for the record this is not a priority for me for 2016.  To my knowledge, that doesn't really bother anyone.  If it does, let me know!
https://github.com/mozilla/treeherder/pull/1922#pullrequestreview-6259059

We really suck at authentication.  Bug 1312915 may introduce a notion of "identity" (probably extending the existing `mozilla-user/<email>`, `mozillians-user/<username>` format.  Let's try to make that more concrete, so there's a way to determine the identity associated with a set of credentials.  Then authenticateHawk can return that value and if users want to authenticate they can just use that value and ignore the scopes.
I suspect we're not going to do this, actually.  I think we will standardize on auth0 and build a simple way to generate temporary TC credentials around that service.  Basically, other services should be talking to auth0 primarily, and us secondarily, since auth0 provides a much better authentication service (even if we are awesome at authorization).
Assignee: dustin → nobody
..and so it came to pass
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Component: Tools → UI and Tools
You need to log in before you can comment on or make changes to this bug.