When logging into tools.tc.net it's very confusing to be thrown back to the screen that tells me to choose a method of logging in, *after* logging in with Okta. AFAICT, the reason for this is that I have to hit "grant access", but there's no indication of that. It seems like it would be much better to go back to the tools.tc.net homepage after a user completes sign in, and not require "grant access" to be clicked. If there's a reason users need to explicitly do that step, a dedicated screen for that would make it more clear what needs to happen.

Agree... The reason for this is that login.taskcluster.net can redirect to any site given by query string. However, we can probably make tools.taskcluster. net a special case where we redirect without asking for confirmation.

I think the better solution is to move the delegation to the tools site. Having two different sites is confusing!

I'm warming up with https://github.com/taskcluster/taskcluster-login/pull/25

Commit pushed to master at https://github.com/taskcluster/taskcluster-login https://github.com/taskcluster/taskcluster-login/commit/9fc337dbf236fe23e22aded2ae36759d91d1cde1 Merge djmitche/taskcluster-login:bug1267249-persona (PR #26)

To remind myself: the next step here is to generate credentials given an Okta SAML assertion, too, which is going to require a fair bit more research.

Is this fixed now? I just signed in and it redirected back to tools.tc.net without me needing to click anything after the Okta page.

It's a special case for tools right now. I want to do a bit better.

It looks like processing SAML assertions like that isn't practical. The current flow is this: user clicks "sign in" on the tools site, is taken to the login site user clicks "sign in with Okta" on tools site redirect to some Okta URL okta POSTs back to the login site with an assertion in the body login processes the assertion, generates credentials login sees that the original request was from https://tools.taskcluster.net and automatically redirects there My desired flow was this: user clicks "sign in with Okta" on tools site redirect to some okta URL okta redirects back to tools with saml assertion in URL tools extracts that from the URL (editing location in the process) and passes it to login for conversion to credentials but that won't work because the redirect to tools can't use POST (Cloudflare doesn't allow it) and while there is a GET binding, the response body is about 10k which definitely won't fit in a URL. Anyway, this would still involve special-casing tools since login would need to process promises with an audience of "tools". The next best thing is a flow very much like what we have: redirect to login, it redirects to Okta, Okta POSTs back to login, login redirects back to tools. So not API driven as I'd like, but I really had no basis for that desire other than cleanliness. What I will do is remove the UI from login so that it *only* supports this redirect flow and unconditionally redirects back to tools (after updating tools to support this functionality, and so on).

(In reply to Dustin J. Mitchell [:dustin] from comment #10) > What I will do is remove the UI from login so that it *only* supports this > redirect flow and unconditionally redirects back to tools (after updating > tools to support this functionality, and so on). How would the redirect flow work for the Treeherder case? (If tools is hardcoded)

So right now you hit https://login.taskcluster.net/?target=<target>&description=<description> to get those credentials. I'll keep that working, but by having it redirect to somewhere on tools with the same parameters. We can modify treeherder to skip that redirect (just point it to 'somewhere on tools'), but the redirect will maintain compatibility with any other uses. Once it's on tools, the idea is for tools to do a github-style verification splash page: "Treeherder would like your TC credentials, is that OK?" (after requiring an okta/mozillians signin, if necessary). The origin of this bug was confusion over why one thing that appears to the user to be "TaskCluster" is asking you to grant access to sometihng else that is also "TaskCluster". That's undesirable, but I think users understand the difference between TH and TC. We can maintain the "remember this choice" checkbox, too :) Overall, I think this change should be invisible to TH.

Ah that sounds fine, I'd misunderstood the changes.

Commit pushed to master at https://github.com/taskcluster/taskcluster-login https://github.com/taskcluster/taskcluster-login/commit/516874993d64408c635e005c36a69cd7cffaa411 Merge pull request #28 from djmitche/bug1267249-update Update dependencies

Not done yet, some open questions for those more experienced than me: https://github.com/taskcluster/taskcluster-tools/pull/153

I still need a bit of assistance with pull 153..

And, done! The existing login landing page needs to stay until we implement federated logins in the tools site, sadly, but at least those using the tools site directly will no longer see it.