Project

General

Profile

Feature #15061

Updated by Peter Amstutz almost 5 years ago

New design, based on discussion Apr 17 [To be revised - this is only the API piece of the implementation now, with the wb2 piece in #15088] 

 h3. Existing user: Situation: 

 # When a user logs into a User has an account on home cluster, make ajax calls cluster A. 
 # User goes to known cluster B.    Instead of logging in with federated identity from cluster login endpoints to say "this browser prefers cluster X as home" which returns A, user logs into a cookie. preexisting account and/or accidentally creates a new account. 
 # User arrives at a federated cluster.    The login button takes now has multiple accounts, but wanted only one account. 
 # UI should guide user to login endpoint on API server.    User can also choose a specific home redirect/merge accounts to use the cluster for log in. 
 A account consistently. 

 Proposed solution: 

 # Request to login endpoint includes cookie saying When a user prefers logs in / creates an account on cluster X, which can be overridden with an explicit query parameter that indicates A, send a home cluster 
 # API server redirects login simple request to proper home cluster 

 h3. Migrating all clusters in the federation on behalf of the user.    This will cause the remote clusters to cache a record of the remote account (because you have an existing account or created one by accident) 

 user. 
 # User When a user logs in to local / creates an account 
 # User selects "migrate account" on cluster B and selects home the account is inactive, check if there are any cluster X A user records with the same email address. 
 # Current token is saved in local session storage and If so, prompt the user is redirected to log into migrate the cluster X B user to the cluster A user instead. 
 # User logs in (again) at cluster A and is redirected back to cluster with salted token from cluster X 
 # Everything owned by B.    The local user account is reassigned migrated (setting redirect_to_user_uuid to remote the cluster A user) the user and local user is marked "redirect_to_user_uuid" to the remote 
 # Complete finishes logging in as remote user in. 

 h3. Logging into a redirected account, no cookies or other hints telling us which cluster to use: Notes: 

 # User * If the user logs in to local cluster B again, the account 
 # After should be automatically redirected to log in, we realize redirected in at cluster A.    Unfortunately, the user is not local 
 # Display a page that says "this has been migrated will probably still have to a remote account, must log in at home cluster" twice. 
 # Redirect * For the case where the user wants cluster B to be the home cluster 
 # User logs in but there is a second time (Existing remote user flow) 

 h3. Scripted from cluster A in the database, provide an alternate flow that sends the user migration 

 # Admin generates list of email address and/or usernames assigned to each home cluster 
 # Get list of users on each A to migrate the cluster A account to redirect to the cluster B account. 
 # If there * These are user records all cases of #13651 with the addition of user accounts identified based on matching email address or username that doesn't match addresses instead of the assigned home cluster, perform account merge being initiated by the user. 
 # Need * User interaction will be added to tweak "merge" endpoint for admin variant which accepts "old_user_uuid" and "new_user_uuid" instead of using current token / "new_user_token" 
 workbench2, includes adding "merge user" flow that exists in wb1 (see #15088)

Back