Story #15529

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

Added by Peter Amstutz 10 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
08/22/2019
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
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

Task #15552: Review 15529-federated-user-accountsResolvedPeter Amstutz


Related issues

Related to Arvados - Story #15477: Use email address for Arvados account linkingDuplicate

Related to Arvados - Feature #15531: [SDK] Migrate federation to central LoginClusterResolved09/23/2019

Related to Arvados - Feature #15530: Workbench2 trusts federation usersResolved10/07/2019

Related to Arvados - Story #15558: [SSO] [API] Identify users by (alternate) email addressesResolved08/22/2019

Associated revisions

Revision 7c3e13d4
Added by Peter Amstutz 9 months ago

Merge branch '15529-federated-user-accounts' refs #15529

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <>

History

#1 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#2 Updated by Tom Clegg 10 months ago

  • Related to Story #15477: Use email address for Arvados account linking added

#3 Updated by Peter Amstutz 10 months ago

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

#4 Updated by Peter Amstutz 10 months ago

#5 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#6 Updated by Peter Amstutz 10 months ago

  • Subject changed from Federated users to Trust federated users from other clusters

#7 Updated by Tom Clegg 10 months 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)

#8 Updated by Tom Clegg 10 months ago

  • Description updated (diff)

#9 Updated by Tom Clegg 10 months ago

  • Description updated (diff)

#10 Updated by Tom Clegg 10 months ago

  • Description updated (diff)

#11 Updated by Tom Clegg 10 months ago

  • Description updated (diff)

#12 Updated by Tom Clegg 10 months ago

  • Description updated (diff)

#13 Updated by Tom Morris 10 months ago

  • Story points set to 5.0

#14 Updated by Tom Clegg 10 months ago

  • Description updated (diff)

#15 Updated by Tom Morris 10 months ago

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

#16 Updated by Tom Morris 10 months ago

  • Assigned To set to Peter Amstutz

#17 Updated by Peter Amstutz 10 months 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?

#18 Updated by Peter Amstutz 10 months 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.

#19 Updated by Peter Amstutz 9 months 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

#20 Updated by Peter Amstutz 9 months ago

  • Description updated (diff)

#21 Updated by Tom Clegg 9 months ago

  • Description updated (diff)

#22 Updated by Peter Amstutz 9 months ago

  • Description updated (diff)

#23 Updated by Peter Amstutz 9 months ago

  • Description updated (diff)

#24 Updated by Peter Amstutz 9 months ago

  • Description updated (diff)

#26 Updated by Peter Amstutz 9 months ago

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

#27 Updated by Tom Morris 9 months ago

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

#28 Updated by Tom Clegg 9 months 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!

#29 Updated by Peter Amstutz 9 months 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/

#30 Updated by Tom Clegg 9 months ago

LGTM, thanks

#31 Updated by Peter Amstutz 9 months ago

  • Status changed from New to Resolved

#32 Updated by Peter Amstutz 4 months ago

  • Release set to 22

Also available in: Atom PDF