Project

General

Profile

Federated identity » History » Version 2

Tom Clegg, 04/18/2017 06:00 PM

1 1 Tom Clegg
h1. Federated identity
2
3
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.
4
5
Motivating use cases:
6
* A user on cluster B shares a project with a user on cluster A.
7
* A container running on cluster A reads and writes data on cluster B.
8
* A user logged in to Workbench A can search/view/download/upload collections at cluster B.
9
10
Configuration examples:
11
* An organization has 5 clusters, but only one of them has user accounts and roles in its database.
12
* An on-premise cluster runs containers that use public data stored in the cloud (without mirroring the data locally).
13
14
h2. Design sketch
15
16
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.
17 2 Tom Clegg
18
h2. Protocol ideas
19
20
"SRP-6a":https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
21
22
"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.