Project

General

Profile

Authentication for a multi-cluster workflow » History » Revision 3

Revision 2 (Tom Clegg, 06/25/2018 03:19 PM) → Revision 3/4 (Tom Clegg, 06/25/2018 07:25 PM)

h1. Authentication for a multi-cluster workflow 

 (work in progress) 

 Scenarios: 

 | user uuid        | workflow uuid         | cluster running parent workflow    | cluster running child container    || 
 | uuuuu            | uuuuu                 | uuuuu                              | uuuuu                              |degenerate case (no federation)| 
 | uuuuu            | wwwww                 | uuuuu                              | uuuuu                              |A| 
 | uuuuu            | uuuuu                 | rrrrr                              | rrrrr                              |B| 
 | uuuuu            | wwwww                 | rrrrr                              | rrrrr                              |C| 
 | uuuuu            | wwwww                 | rrrrr                              | ccccc                              |D| 

 h2. A: Proxy "GET workflow" request on behalf of local user 

 Cluster uuuuu makes a salted token for wwwww when proxying the client's "GET workflow wwwww-*" request. 

 Cluster wwwww calls back to uuuuu to verify the salted token. 

 

 h2. B: Proxy "GET workflow" request on behalf of remote user (authenticated by same remote cluster that hosts workflow) 

 * token issued by uuuuu 
 * workflow hosted by uuuuu 
 * a-c-r connects to rrrrr 

 Client (arvados-cwl-runner) uses original token (issued by uuuuu) instead of an rrrrr-salted token. 
 * Todo: during login, uuuuu asks TBD: how does the user get to choose between single-cluster and all-clusters token. this point? 

 Cluster rrrrr calls back to cluster uuuuu to verify the token for rrrrr-local transactions. 
 * Todo: uuuuu issues v2 tokens, so rrrrr knows where to perform the verify callback. 
 * Todo: v2 tokens indicate whether or not they are salted (e.g., len(secret)==40 iff salted). 
 * Todo: rrrrr salts the supplied token when doing the verify callback, if it's not already salted. 

 Cluster rrrrr makes a salted token for uuuuu when proxying the client's "GET workflow uuuuu-*" request. 
 * Todo: uuuuu accepts self-issued tokens that have been uuuuu-salted (for regular requests, not verify callbacks). 

 (Alternatively, cluster rrrrr, when proxying a "GET workflow uuuuu-*" request with a token issued by uuuuu, passes through the supplied token without salting it -- but this needlessly sends a more powerful token over the network.) 

 

 h2. C: Proxy "GET workflow" request on behalf of user authenticated by different remote cluster 

 * token issued by uuuuu 
 * workflow hosted by wwwww 
 * a-c-r connects to rrrrr 

 Client (arvados-cwl-runner) uses original token (issued by uuuuu) instead of an rrrrr-salted token. 
 * (as in scenario B) 

 Cluster rrrrr makes a salted token for wwwww when proxying the "GET workflow wwwww-*" request. 

 Cluster wwwww calls back to uuuuu to verify the token. 

 h2. D: Parent (workflow) container submits child container to a fourth cluster 

 (tbd)