Project

General

Profile

Actions

Federated identity » History » Revision 1

Revision 1/22 | Next »
Tom Clegg, 04/11/2017 07:54 PM


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).

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.

Updated by Tom Clegg over 7 years ago · 1 revisions