Feature #14720
closed[Federation] Workbench2 login chooser
Updated by Eric Biagiotti almost 6 years ago
- Tracker changed from Bug to Feature
Updated by Eric Biagiotti almost 6 years ago
- Related to Feature #12958: [Federation] Workbench login chooser added
Updated by Tom Morris almost 6 years ago
- Target version set to Arvados Future Sprints
Updated by Tom Morris almost 6 years ago
- Target version changed from Arvados Future Sprints to 2019-02-13 Sprint
Updated by Peter Amstutz almost 6 years 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.
Done.
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.
Done.
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
Updated by Peter Amstutz almost 6 years 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
Updated by Peter Amstutz almost 6 years ago
I've started a Hacking Workbench2 page: https://dev.arvados.org/projects/arvados/wiki/Hacking_Workbench2
Updated by Eric Biagiotti almost 6 years 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.
Updated by Eric Biagiotti almost 6 years 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?
Updated by Peter Amstutz almost 6 years ago
Eric Biagiotti wrote:
- In src/services/auth-service/auth-service.ts line 104: clean up commented out code
Fixed.
- In src/store/auth/auth-reducer.ts
[...]
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?
Arvados uuids always start with the five character cluster identifier.
This branch has gotten a little tangled up with #14841, so the changes are here:
14841-link-workbench1 @ c74d94dabd5f66bc948f9a9ed6283cdb59fb392b
Updated by Peter Amstutz almost 6 years ago
- Status changed from In Progress to Resolved