Project

General

Profile

Federated identity » History » Version 19

Peter Amstutz, 06/21/2017 02:08 PM

1 1 Tom Clegg
h1. Federated identity
2
3 9 Tom Clegg
See
4
* #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.
8
9
Motivating use cases:
10
* A user on cluster B shares a project with a user on cluster A.
11
* A container running on cluster A reads and writes data on cluster B.
12
* A user logged in to Workbench A can search/view/download/upload collections at cluster B.
13
14
Configuration examples:
15
* An organization has 5 clusters, but only one of them has user accounts and roles in its database.
16
* An on-premise cluster runs containers that use public data stored in the cloud (without mirroring the data locally).
17
18 18 Tom Clegg
h2. Relevant principles
19
20
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
* This implies that permission links whose head_uuid starts with "bbbbb-" exist only on cluster bbbbb. (If they exist elsewhere, they should be ignored.)
22
23 1 Tom Clegg
h2. Design sketch
24 8 Tom Clegg
25
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
29
"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 7 Tom Clegg
* API server hands out tokens in the form "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.
32
* Cluster B can be configured with a lookup table (clusterID&rarr;apiHost) to override the implicit {id}.arvadosapi.com
33
* Cluster B can be configured to _only_ use the lookup table, i.e., to never use implicit {id}.arvadosapi.com 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.
40
41
|grantor|grantee|object|notes|
42
|user on site A|user on site A|object on site A|(existing permission system)|
43
|user on site A|group on site A|object on site A|(existing permission system)|
44
|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.|
45
|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.|
47
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
53
54 1 Tom Clegg
Things to address
55 11 Peter Amstutz
56 4 Tom Clegg
* how to sync groups
57
* diagrams
58
* 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 19 Peter Amstutz
* [[Multi-cluster client access]]