Federated identity » History » Version 1
Tom Clegg, 04/11/2017 07:54 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. |