Idea #15529
Updated by Tom Clegg over 4 years ago
https://dev.arvados.org/projects/arvados/wiki/Multi-cluster_user_database h2. Login Differences from previous "home cluster" design When logging in, instead of finding/creating a * deterministic user record uuid based on the SSO-provided identity_url: upstream identifier * generate log in anywhere * use token anywhere h2. API When logging in, assign deterministic user UUID from uuid with a configured user-UUID-prefix prefix and id based on hash of SSO-provided email address * if a row upstream identifier (email address). Prefix is associated with this UUID doesn't already exist, fetch/create one on of the clusters in the federation. This is the "master" cluster (if this fails, login fails) * refresh cluster. Login contacts the local record from the master cluster (non-master cluster only) * to get authoritative copy of user record (such as to know if the user record has is active). If there is a "redirect" flag, follow redirect, it (fetch/update will return a different user uuid. It should use the local cache of user uuid that was returned. Login cluster issues its own token for the redirect target user, etc.) user. If To authenticate the upstream provides multiple email addresses, first check whether token, contact the master cluster has a (non-redirect) account matching one of them. If so, use that one. Otherwise, use issued the primary email address. h2. Token validation When validating a remote token, if token. It returns the uuid of the user UUID prefix in associated with the remote cluster's response doesn't match token. The user uuid may have the token UUID prefix: * Retrieve federation prefix. Configuration (see below) specifies that API server will trust other servers in the exported config document federation for user uuid responses of federation users (which will have a different prefix 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 being contacted.) h2. 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. cluster. When making sending a request to a remote cluster as part of a federated query, check whether cluster, if the remote cluster is trusted trusted, don't salt the token. h2. Configuration * Specify how to issue tokens for construct the deterministic user UUID in play -- if so, pass uuid (email address or other field from upstream auth) * master cluster * for each other cluster, configure it to accept tokens issued with the token through unmodified instead of passing a salted token. master prefix