Feature #14720

[Federation] Workbench2 login chooser

Added by Eric Biagiotti about 1 month ago. Updated 1 day ago.

In Progress
Assigned To:
Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
Story points:


Task #14795: Review 14720-login-chooser in arvados-workbench2In ProgressPeter Amstutz

Related issues

Related to Arvados - Feature #12958: [Federation] Workbench login chooserNew


#1 Updated by Eric Biagiotti about 1 month ago

  • Tracker changed from Bug to Feature

#2 Updated by Eric Biagiotti about 1 month ago

  • Related to Feature #12958: [Federation] Workbench login chooser added

#3 Updated by Tom Morris 21 days ago

  • Target version set to Arvados Future Sprints

#4 Updated by Tom Morris 21 days ago

  • Target version changed from Arvados Future Sprints to 2019-02-13 Sprint

#5 Updated by Peter Amstutz 21 days ago

  • Assigned To set to Peter Amstutz

#6 Updated by Peter Amstutz 21 days ago

  • Story points set to 3.0

#7 Updated by Peter Amstutz 8 days ago

On a cluster with remote_hosts_via_dns enabled, the login button should come with a text box where the user can type a 5-letter cluster prefix.

Right now, other parts of the backend for federation (like controller!) don't support "remote_hosts_via_dns", so I didn't do it in this branch, because it would possibly result in a broken login.

On a cluster with specific remote_hosts defined, the login button should come with a selector widget so the user can choose one of the defined remotes.


When the user selects a remote cluster, the login URL should include the current cluster ID as the "remote" query parameter, which tells the login cluster to issue a salted token for the current cluster. See #14718.


If configured for a special "home" cluster, always redirect to the login endpoint of the "home" cluster, user will still be (eventually) returned to "remote" workbench. "Home" API server needs to know to send a salted token back to the remote workbench. This should also imply honoring the "is_active" flag.

Not done.

If a user logs in to an identity_url that corresponds to a remote user, or has a redirect_to_user_uuid to a remote user, results in a browser redirect to the user's home cluster for federated login.

Uhhhh... Need to investigate this further. May require additional cooperation from API server.

Optional: Use LocalStorage to remember which cluster was chosen, and make that the default next time.

Not done.

14720-login-chooser @ commit:4d515a3e8fe7578b75136ed8ad0c49692f1c3239

#8 Updated by Peter Amstutz 7 days ago

  • Status changed from New to In Progress
  • Target version changed from 2019-02-13 Sprint to 2019-02-27 Sprint
  • Story points changed from 3.0 to 1.0

#9 Updated by Peter Amstutz 7 days ago

#10 Updated by Eric Biagiotti 5 days ago

First notes from just using the UI:

  • From initial loading of the page 4xphq is selected in the drop down, but if you click login, the URL is undefined. The drop down should either have a blank entry (selected by default), which will grey out the login button, or the first item is actually selected and the login button says "Login into c97qk with user from 4xphq".
  • How important is it to have the cluster id which your user is from easily visible once logged in? ATM, you have to go into your account and parse the UUID. I think they best way to present it would be in the Account Management drop down as a part of your greyed out name at the top, but its debatable.

#11 Updated by Eric Biagiotti 1 day ago

  • In src/services/auth-service/auth-service.ts line 104: clean up commented out code
  • In src/store/auth/auth-reducer.ts
    return { ...state, user, apiToken: token, homeCluster: user.uuid.substr(0, 5) };

    I'm a little concerned about parsing the uuid to get the home cluster; though admittedly, I am not 100% sure how/where the uuid gets set. Is there any chance this could be more that 5 characters?

Also available in: Atom PDF