Story #15529

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

Added by Peter Amstutz 17 days ago. Updated 1 day ago.

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

0%

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

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-accounts In Progress


Related issues

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

Related to Arvados - Feature #15531: [SDK] Migrate federation to central LoginClusterNew

Related to Arvados - Feature #15530: Workbench2 trusts federation usersNew

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

History

#1 Updated by Peter Amstutz 17 days ago

  • Description updated (diff)

#2 Updated by Tom Clegg 17 days ago

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

#3 Updated by Peter Amstutz 16 days ago

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

#4 Updated by Peter Amstutz 16 days ago

#5 Updated by Peter Amstutz 16 days ago

  • Description updated (diff)

#6 Updated by Peter Amstutz 16 days ago

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

#7 Updated by Tom Clegg 16 days ago

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

#8 Updated by Tom Clegg 16 days ago

  • Description updated (diff)

#9 Updated by Tom Clegg 16 days ago

  • Description updated (diff)

#10 Updated by Tom Clegg 16 days ago

  • Description updated (diff)

#11 Updated by Tom Clegg 16 days ago

  • Description updated (diff)

#12 Updated by Tom Clegg 16 days ago

  • Description updated (diff)

#13 Updated by Tom Morris 16 days ago

  • Story points set to 5.0

#14 Updated by Tom Clegg 16 days ago

  • Description updated (diff)

#15 Updated by Tom Morris 9 days ago

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

#16 Updated by Tom Morris 9 days ago

  • Assigned To set to Peter Amstutz

#17 Updated by Peter Amstutz 8 days 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 8 days 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 4 days 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 3 days ago

  • Description updated (diff)

#21 Updated by Tom Clegg 3 days ago

  • Description updated (diff)

#22 Updated by Peter Amstutz 3 days ago

  • Description updated (diff)

#23 Updated by Peter Amstutz 3 days ago

  • Description updated (diff)

#24 Updated by Peter Amstutz 2 days ago

  • Description updated (diff)

#26 Updated by Peter Amstutz 1 day ago

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

Also available in: Atom PDF