Idea #15529
Updated by Tom Clegg over 5 years ago
[[Multi-cluster user database]] h2. Configuration Add Login.LoginCluster config configs mentioned on the [[Multi-cluster user database]] wiki (AssignUUIDPrefix, RemoteClusters.*.Authenticate) h2. Login # Instead of logging in to 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') # After logging in, user is sent to original cluster (cluster B) with a token issued by the home cluster (cluster A) # If cluster A's RemoteHosts for cluster B has a 'trusted' flag, send unsalted token (this is 'AuthenticateLocalUsers' but it should probably be called something else like 'TrustWithUnsaltedToken') # Users from master cluster A have extra trust on cluster B (respects admin flag) (based on AssignUUIDPrefix / whatever flag) h2. Token validation Tokens get a 'refresh_at' date in addition to existing expires_at. Attempt to contact master cluster after 'refresh_at', succeed or fail it sets a new 'refresh_at', does not prevent login until past 'expires_at' 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.