Federated identity » History » Version 22

Tom Clegg, 10/16/2017 07:14 PM

1 1 Tom Clegg
h1. Federated identity
3 9 Tom Clegg
* #11453
5 10 Tom Clegg
* #11874
6 9 Tom Clegg
7 1 Tom Clegg
A person should be able to create an account and get a token from a single identity provider, and use that token to access private/protected resources on multiple Arvados clusters.
Motivating use cases:
* A user on cluster B shares a project with a user on cluster A.
* A container running on cluster A reads and writes data on cluster B.
* A user logged in to Workbench A can search/view/download/upload collections at cluster B.
Configuration examples:
* An organization has 5 clusters, but only one of them has user accounts and roles in its database.
* An on-premise cluster runs containers that use public data stored in the cloud (without mirroring the data locally).
18 18 Tom Clegg
h2. Relevant principles
20 22 Tom Clegg
Cluster "bbbbb" is authoritative for objects whose UUIDs start with "bbbbb-". This applies to both the object's state and the set of user/group UUIDs that are allowed to read/write the object.
21 18 Tom Clegg
* This implies that permission links whose head_uuid starts with "bbbbb-" exist only on cluster bbbbb. (If they exist elsewhere, they should be ignored.)
23 1 Tom Clegg
h2. Design sketch
24 8 Tom Clegg
Each Arvados client must be able to prove to cluster B that it is authorized by cluster A to act on behalf of a user account which is controlled by cluster A. This must not involve giving enough information to cluster B to act on behalf of the user account: for example, the client cannot simply give cluster B its cluster A token for the purpose of doing a canary query: doing so would allow cluster B to exercise the client's authority on cluster C, D, and E as well.
26 1 Tom Clegg
27 18 Tom Clegg
h2. Protocol ideas
28 1 Tom Clegg
"Salted tokens": instead of passing its literal token, the client passes the token UUID and @HMAC(token, "bbbbb")@ when sending a request to cluster B (where "bbbbb" is cluster B's cluster ID / UUID prefix). Cluster B validates the request by passing those two parameters untouched to a "verify request" ("no-op") endpoint at cluster A.
30 22 Tom Clegg
* API server hands out tokens in the form "v2 <delimiter> tokenUUID <delimiter> secret" instead of just the secret part.
31 6 Tom Clegg
* Cluster B figures out cluster A's API endpoint by looking at the "site ID prefix" of the token UUID.
* Cluster B can be configured with a lookup table (clusterID&rarr;apiHost) to override the implicit {id}
* Cluster B can be configured to _only_ use the lookup table, i.e., to never use implicit {id} endpoints
34 1 Tom Clegg
35 18 Tom Clegg
"Cluster-scoped tokens": the client contacts cluster A to get a scoped token which only allows "GET /users/current" on cluster A but is accepted by cluster B as an [all] token for that user.
36 1 Tom Clegg
37 6 Tom Clegg
h2. Adding permissions
38 1 Tom Clegg
39 6 Tom Clegg
There are a few permission-granting cases to consider.
|user on site A|user on site A|object on site A|(existing permission system)|
|user on site A|group on site A|object on site A|(existing permission system)|
|user on site A|user or group on site A|object on site B|Client creates a link at site B. Site B asks site A whether the grantee user/group is visible to user A.|
|user on site A|user or group on site B|object on site B|Client creates a link at site B. Site B asks site A for a list of groups user A can see, then checks whether (possibly via one of those groups) user A can read the grantee user/group according to site B's local database.|
46 1 Tom Clegg
|user on site A|user or group on site B|object on site A|Client creates a link at site A. Site A generates a salted token and uses it to ask site B whether user A can read the grantee user/group.|
48 18 Tom Clegg
In all of these cases, "user on site A" has a UUID starting with "aaaaa-" and therefore uses a token issued by cluster A (see "protocol ideas" above).
49 12 Peter Amstutz
50 18 Tom Clegg
When site B connects to site A in the course of processing request R, it uses the token provided by the client in request R.
51 14 Peter Amstutz
52 4 Tom Clegg
h2. TODO
54 1 Tom Clegg
Things to address
55 11 Peter Amstutz
56 4 Tom Clegg
* how to sync groups
* diagrams
* mnemonic cluster names / more concrete examples (including who is reachable on the internet)
59 6 Tom Clegg
* [how] do you get a list of users/groups you can share stuff with?
60 4 Tom Clegg
* clarify what UUIDs look like (some people have A uuids, some have B uuids)
61 11 Peter Amstutz
* [[Cross-cluster delegation]]
62 20 Peter Amstutz
* [[Routing multi cluster requests]]