Idea #15529
Updated by Tom Clegg over 5 years ago
https://dev.arvados.org/projects/arvados/wiki/Multi-cluster_user_database
h2. Login
When logging in, instead of finding/creating a user record based on the SSO-provided identity_url:
* generate user UUID from configured user-UUID-prefix (Login.AssignUUIDPrefix) and hash of SSO-provided email address
* if a row with this UUID doesn't already exist, fetch/create one on the "master" cluster (if this fails, login fails)
* refresh the local record from the master cluster (non-master cluster only)
* if the user record has a "redirect" flag, follow it (fetch/update the local cache of the redirect target user, etc.)
If the upstream provides multiple email addresses, first check whether the master cluster has a (non-redirect) account matching one of them. If so, use that one. Otherwise, use the primary email address.
h2. Token validation
When validating a remote token, if the user UUID prefix in the remote cluster's response doesn't match the token UUID prefix:
* Retrieve the exported config document from the authoritative cluster (the one whose ID is indicated by the user UUID)
* If the authoritative cluster trusts the token issuer (RemoteClusters.$tokenprefix.Authenticate.$userprefix exists), accept the token
* Otherwise, reject the token
h2. UserGet / UserUpdate APIs
In controller, when requesting or updating a user uuid, proxy the request to the master cluster -- i.e., the cluster whose ID matches the user UUID prefix.
In controller, when making a request to a remote cluster as part of a federated query, check whether the remote cluster is trusted to issue tokens for the user UUID in play (according to the master cluster's config RemoteClusters.$remoteclusterid.Authenticate.$userprefix) -- if so, pass the token through unmodified instead of passing a salted token.