Project

General

Profile

Idea #15529

Updated by Tom Clegg over 4 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. 

Back