Project

General

Profile

Actions

Feature #12958

closed

[Federation] Workbench login chooser

Added by Tom Clegg over 6 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assigned To:
-
Category:
Workbench
Target version:
Story points:
-
Release relationship:
Auto

Description

If cluster B is configured to permit it, federated login allows an account on cluster A to use Workbench at cluster B. In that case, Workbench B should give an unauthenticated visitor the option to log in via cluster A.

Current behavior

An unauthenticated visitor to Workbench B is offered a "log in" button that initiates the login procedure for cluster B. If a cluster A user clicks it, they end up creating a new cluster B account, instead of using their existing cluster A account. After #11454 they can work around this by visiting Workbench A first and following a link from the multisite search page to Workbench B, but this is not obvious or convenient.

Proposed change

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.

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.

If both configs are enabled, both widgets should be offered. If a user types an ID listed in remote_hosts, remote_hosts has precedence over remote_hosts_via_dns. Matching is case-insensitive.

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.

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.

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

TBD

Visual/interactivity specifics. Note there is a big dialog-like login box, plus a login button in the top nav.


Related issues

Related to Arvados - Idea #11454: Support federated search across a set of Arvados clustersResolvedLucas Di Pentima04/11/2017Actions
Related to Arvados - Idea #13255: Provide account activation configuration options for federated loginsResolvedPeter Amstutz06/21/2018Actions
Related to Arvados - Feature #14720: [Federation] Workbench2 login chooserResolvedPeter Amstutz02/13/2019Actions
Blocked by Arvados - Feature #14718: [API] Option to issue salted token in login procedureResolvedLucas Di Pentima01/26/2019Actions
Actions #1

Updated by Tom Morris about 6 years ago

  • Related to Idea #11454: Support federated search across a set of Arvados clusters added
Actions #2

Updated by Tom Clegg about 6 years ago

  • Related to Idea #13255: Provide account activation configuration options for federated logins added
Actions #3

Updated by Peter Amstutz about 6 years ago

  • Description updated (diff)
Actions #5

Updated by Peter Amstutz over 5 years ago

Another way to approach this would be for the user to start at their home cluster, and then be able to click on a button to navigate to one of the federated workbench instances by providing a salted token. In fact, the multi-site search already does this, but there isn't a simple obvious page to visit that takes you to the dashboard of each cluster.

Actions #6

Updated by Peter Amstutz over 5 years ago

  • Related to Feature #14718: [API] Option to issue salted token in login procedure added
Actions #7

Updated by Tom Clegg over 5 years ago

  • Related to deleted (Feature #14718: [API] Option to issue salted token in login procedure)
Actions #8

Updated by Tom Clegg over 5 years ago

  • Blocked by Feature #14718: [API] Option to issue salted token in login procedure added
Actions #9

Updated by Tom Clegg over 5 years ago

  • Description updated (diff)
Actions #10

Updated by Tom Clegg over 5 years ago

  • Story points set to 3.0
Actions #11

Updated by Eric Biagiotti over 5 years ago

  • Related to Feature #14720: [Federation] Workbench2 login chooser added
Actions #12

Updated by Peter Amstutz over 5 years ago

  • Target version changed from To Be Groomed to Arvados Future Sprints
Actions #13

Updated by Peter Amstutz over 5 years ago

  • Description updated (diff)
Actions #14

Updated by Tom Morris about 5 years ago

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

Updated by Peter Amstutz about 5 years ago

  • Target version changed from 2019-02-13 Sprint to 2019-02-27 Sprint
Actions #16

Updated by Tom Morris about 5 years ago

  • Story points deleted (3.0)
Actions #17

Updated by Tom Morris about 5 years ago

  • Status changed from New to Closed

We're going to skip doing this for Workbench 1. It's been implemented for Workbench 2.

Actions #18

Updated by Tom Morris about 5 years ago

  • Release set to 15
Actions

Also available in: Atom PDF