Skip to content

Instantly share code, notes, and snippets.

@djmitche

djmitche/@@Federated Logins.md

Last active October 5, 2016 21:43
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save djmitche/0c5186facc9c3db595d356f799b8124d to your computer and use it in GitHub Desktop.
Save djmitche/0c5186facc9c3db595d356f799b8124d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
@@Federated Logins.md

Goals

  • Users see a single, consistent "app" representing TaskCluster
  • Users can control access granted to other applications
  • Other applications interact only with the tools site
  • Non-employee authentication remains possible after Persona sunsets
Raw
bug1267249.md

Goals

  • All user-visible UI should be within the tools site.
  • Single-click sign-in for users already authenticated to Okta
  • Ready to support:
    • Replacement for Persona
    • Federated login requests going to tools.taskcluster.net rather than login.taskcluster.net
    • Federated login "landing page" with tools UI, allowing sign-in if necessary, remembering whitelisted services
    • Federated logins requesting a subset of scopes, generating new temp creds for that request

Design Notes

I am dropping the attempt to use login as an API. Only Persona is currently implemented, and that will go away soon. SAML cannot be implemented that way (because tools is static and Cloudflare does not allow POSTs, POSTing the SAML assertion back doesn't work, but the assertion is far too large to be in a GET; so we need a service that can accept a POST). Likely OIDC is best implemented like SAML.

So, the flow for any of these should be as follows:

  • tools consults a login API to see what auth methods are available
  • user clicks a button on tools
  • user authenticates, using the mechanism appropriate to the auth method (never sees tools content)
  • auth process POSTs a result back to a login.taskcluster.net URL with a return URL
  • login generates temporary credentials, redirects to tools with those credentials
  • tools puts the credentials in localStorage
  • in case of an error, login assembles an appropriate tools URL to display the error and redirects to it

Key here is that while tools is handling requests from a browser, it has no UI. Note that, in a positive change from current behaivor, signing in reloads the tools page.

Because different auth options have different in-browser behavior (full page - Okta, JS modal - Auth0, new window - Persona), the tools site needs to be given some "type" information about each login option and must contain purpose-specific code for those types.

TODO

  • Add a Persona login button to tools, using PersonaVerifier
  • Add an Okta login button to tools, redirecting to a new window that correctly updates tools' LocalStorage
  • Add a "manual login" button to tools
  • Update docstrings for the Login API to match new plan
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment