Feature #15061

Updated by Peter Amstutz over 2 years ago

New design, based on discussion Apr 17

h3. Existing user:

# When a user logs into a home cluster, make ajax calls to known federated cluster login endpoints to say "this browser prefers cluster X as home" which returns a cookie.
# User arrives at a federated cluster. The login button takes user to login endpoint on API server. User can also choose a specific home cluster for log in.
# Request to login endpoint includes cookie saying user prefers cluster X, which can be overridden with an explicit query parameter that indicates a home cluster
# API server redirects login to proper home cluster

h3. Migrating to remote account (because you have an existing account or created one by accident)

# User logs in to local account
# User selects "migrate account" and selects home cluster X
# Current token is saved in local session storage and user is redirected to log into cluster X
# User is redirected back to cluster with salted token from cluster X
# Everything owned by local user is reassigned to remote user and local user is marked "redirect_to_user_uuid" to the remote
# User now uses token Complete logging in as remote user

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

# User logs in to local account
# After log in, we realize redirected user is not local
# Display a page that says "this has been migrated to a remote account, must log in at home cluster"
# Redirect to home cluster
# User logs in a second time (Existing user flow)

h3. Scripted user migration

# Admin generates list of email address and/or usernames assigned to each home cluster
# Get list of users on each cluster
# If there are user records with the email address or username that doesn't match the assigned home cluster, perform account merge
# Need to tweak "merge" endpoint for admin variant which accepts "old_user_uuid" and "new_user_uuid" instead of using current token / "new_user_token"

Back