Project

General

Profile

Actions

Idea #15529

closed

[API] [Controller] Share user account database with a group of trusted clusters

Added by Peter Amstutz over 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Story points:
5.0
Release relationship:
Auto

Description

Multi-cluster user database

Configuration

Add Login.LoginCluster config mentioned on the Multi-cluster user database wiki

Login

  1. Instead of logging in to a local SSO provider, can designate a home cluster (cluster A) where login is always sent
  2. After logging in, user is sent to original cluster (cluster B) with a token issued by the home cluster (cluster A)
  3. Users from LoginCluster (cluster A) have extra trust on cluster B (respects admin flag)

Subtasks 1 (0 open1 closed)

Task #15552: Review 15529-federated-user-accountsResolvedPeter Amstutz08/22/2019Actions

Related issues

Related to Arvados - Idea #15477: Use email address for Arvados account linkingDuplicateActions
Related to Arvados - Feature #15531: [SDK] Migrate federation to central LoginClusterResolvedPeter Amstutz09/23/2019Actions
Related to Arvados - Feature #15530: Workbench2 trusts federation usersResolvedPeter Amstutz10/07/2019Actions
Related to Arvados - Idea #15558: [SSO] [API] Identify users by (alternate) email addressesResolvedPeter Amstutz08/22/2019Actions
Actions #1

Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)
Actions #2

Updated by Tom Clegg over 4 years ago

  • Related to Idea #15477: Use email address for Arvados account linking added
Actions #3

Updated by Peter Amstutz over 4 years ago

  • Related to Feature #15531: [SDK] Migrate federation to central LoginCluster added
Actions #4

Updated by Peter Amstutz over 4 years ago

Actions #5

Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)
Actions #6

Updated by Peter Amstutz over 4 years ago

  • Subject changed from Federated users to Trust federated users from other clusters
Actions #7

Updated by Tom Clegg over 4 years ago

  • Subject changed from Trust federated users from other clusters to [API] [Controller] Share user account database with a group of trusted clusters
  • Description updated (diff)
Actions #8

Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
Actions #9

Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
Actions #10

Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
Actions #11

Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
Actions #12

Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
Actions #13

Updated by Tom Morris over 4 years ago

  • Story points set to 5.0
Actions #14

Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
Actions #15

Updated by Tom Morris over 4 years ago

  • Target version changed from To Be Groomed to 2019-08-28 Sprint
Actions #16

Updated by Tom Morris over 4 years ago

  • Assigned To set to Peter Amstutz
Actions #17

Updated by Peter Amstutz over 4 years ago

There is a feature to "pre-register" a user by creating a permission link from the user email to the user uuid.

It seems that with deterministic user uuids this feature could be superceded by giving the admin a way to create an account with the uuid that would be generated for a given email address?

Actions #18

Updated by Peter Amstutz over 4 years ago

After spending a while mulling over implementation strategy, I think we want to create a new API endpoint called "fedlogin" (only enabled on the master cluster). This new endpoint will allow the subordinate clusters to forward along the 'info' hash we get from SSO (contains user name, email) and return the user record to use.

The rationale is that if a user with multiple email aliases logs in for the first time on a subordinate cluster, the action of probing for potential user record, creating records on the master cluster, and setting up redirects is complicated, risky, and slow if spread across multiple API calls, any of which could fail and result in inconsistent state or behavior. A single call is transactional and ensures consistent behavior.

Actions #19

Updated by Peter Amstutz over 4 years ago

Revised design for delegating user accounts to master cluster.

  1. Instead of logging in to a local SSO provider, designate a home cluster (cluster A) where login is always sent (this is 'AssignUUIDPrefix' but it should probably be called something else like 'LoginCluster' or 'MasterCluster')
  2. After logging in, user is sent to original cluster (cluster B) with a token issued by the home cluster (cluster A)
  3. If cluster A's RemoteHosts for cluster B has a 'trusted' flag, send unsalted token (this is 'AuthenticateLocalUsers' but it should probably be called something else like 'TrustWithUnsaltedToken')
  4. Users from master cluster A have extra trust on cluster B (respects admin flag)
  5. Tokens get a 'refresh_at' date in addition to existing expires_at. Attempt to contact master cluster after 'refresh_at', succeed or fail it sets a new 'refresh_at', does not prevent login until past 'expires_at'

Multi-email login should be done in a separate branch.

  1. Start by looking up identity_url
  2. If identity_url is not found, look up records for each email address in the 'info' field
  3. If there's more than one user with the same email address and it is ambiguous which record to use, login fails.
  4. If no user record is found, create user records for each email address and link the alternate ones to the primary one
  5. Sync identity_url, email address, name on the user record that was selected.
  6. Make sure 'email' field is not user editable (when we actually need to send mail, check user preferences?)

Migration.

  1. Need to be able to create user accounts through the API with just an email address
  2. Merge account feature must be able to have local user account take over a remote account
Actions #20

Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)
Actions #21

Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
Actions #22

Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)
Actions #23

Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)
Actions #24

Updated by Peter Amstutz over 4 years ago

  • Description updated (diff)
Actions #26

Updated by Peter Amstutz over 4 years ago

  • Related to Idea #15558: [SSO] [API] Identify users by (alternate) email addresses added
Actions #27

Updated by Tom Morris over 4 years ago

  • Target version changed from 2019-08-28 Sprint to 2019-09-11 Sprint
Actions #28

Updated by Tom Clegg over 4 years ago

The existing token validation code uses ApiClientAuthorization.remote_host(id) to get the configured Host, fall back to {id}.arvadosapi.com. Seems like we should use the same strategy/function when finding a remote cluster's endpoint for LoginCluster purposes. (That remote_host() function also requires Proxy: true, which seems like a sensible requirement for using a remote as a LoginCluster -- e.g., "get current user record after logging in" won't work without it.)

I probably shouldn't care so much about comments, but Invarient → Invariant

Rest LGTM, thanks!

Actions #29

Updated by Peter Amstutz over 4 years ago

Tom Clegg wrote:

The existing token validation code uses ApiClientAuthorization.remote_host(id) to get the configured Host, fall back to {id}.arvadosapi.com. Seems like we should use the same strategy/function when finding a remote cluster's endpoint for LoginCluster purposes. (That remote_host() function also requires Proxy: true, which seems like a sensible requirement for using a remote as a LoginCluster -- e.g., "get current user record after logging in" won't work without it.)

Fixed.

I probably shouldn't care so much about comments, but Invarient → Invariant

Fixed.

Rest LGTM, thanks!

15529-federated-user-accounts @ 068e72307f9ce91538e45cb461b99cf92d2f5666

https://ci.curoverse.com/view/Developer/job/developer-run-tests/1502/

Actions #30

Updated by Tom Clegg over 4 years ago

LGTM, thanks

Actions #31

Updated by Peter Amstutz over 4 years ago

  • Status changed from New to Resolved
Actions #32

Updated by Peter Amstutz about 4 years ago

  • Release set to 22
Actions

Also available in: Atom PDF