Federated identity » History » Revision 4
Revision 3 (Tom Clegg, 04/18/2017 06:05 PM) → Revision 4/22 (Tom Clegg, 04/18/2017 06:34 PM)
h1. Federated identity
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).
h2. Design sketch
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.
h2. Protocol ideas
"SRP-6a":https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
"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.
h2. TODO
Things to address
* how to sync groups
* diagrams
* mnemonic cluster names / more concrete examples (including who is reachable on the internet)
* [how] do you get a list of users you can share stuff with?
* clarify what UUIDs look like (some people have A uuids, some have B uuids)