Idea #15529
Updated by Peter Amstutz over 4 years ago
[[Multi-cluster user database]] h2. Configuration Add configs mentioned on the [[Multi-cluster user database]] wiki (AssignUUIDPrefix, RemoteClusters.*.Authenticate) h2. SSO When providing callback response to API, include all upstream-provided email addresses (not just the primary one as we do now). h2. Login # Instead When logging in, instead of logging in to finding/creating a local SSO provider, can 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') user record based on the SSO-provided identity_url: # After logging in, * generate user is sent to original cluster (cluster B) UUID from configured user-UUID-prefix (Login.AssignUUIDPrefix) and hash of SSO-provided email address * if a row with a token issued by this UUID doesn't already exist, fetch/create one on the home "master" cluster (cluster A) (if this fails, login fails) # If * refresh the local record from the master cluster A's RemoteHosts for (non-master cluster B only) * if the user record has a 'trusted' "redirect" flag, send unsalted token (this is 'AuthenticateLocalUsers' but follow it should probably be called something else like 'TrustWithUnsaltedToken') # Users from (fetch/update the local cache of the redirect target user, etc.) If the upstream provides multiple email addresses, first check whether the master cluster A have extra trust on cluster B (respects admin flag) (based on AssignUUIDPrefix / whatever flag) has a (non-redirect) account matching one of them. If so, use that one. Otherwise, use the primary email address. Add any missing redirects for the alternate email addresses. h2. Token validation Tokens get When validating a 'refresh_at' date remote token, if the user UUID prefix in addition to existing expires_at. Attempt to contact master the remote cluster's response doesn't match the token UUID prefix: * Retrieve the exported config document from the authoritative cluster after 'refresh_at', succeed or fail it sets a new 'refresh_at', does not prevent login until past 'expires_at' (the one whose ID is indicated by the user UUID) * If the authoritative cluster trusts the token issuer (RemoteClusters.$tokenprefix.AuthenticateLocalUsers 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.AuthenticateLocalUsers) -- if so, pass the token through unmodified instead of passing a salted token.