Arvados

h1. Authentication

Permissions are granted to users ("resource owners") who can be authenticated via OAuth2.

From the perspective of Arvados, a user is always authenticated using an "sso-provider":https://arvados.org/projects/arvados/repository/sso-provider regardless of the user's choice of identity provider. This provides the following benefits.

* Every user referenced by Arvados has an Arvados UUID, @aaaaa-bbbbb-ccccccccccccccc@

* Permissions are granted to users, rather than {user,site} tuples.

* sso-provider can act as a proxy to various identity providers, even ones that don't support OAuth2.

* Users can switch identity providers without affecting their existing permissions.

* Users can use multiple identity providers to access a single account. For example, a user might want to use an alternate authentication mechanism when connecting from a mobile device. (In principle, this could be deferred to the third-party provider -- "you should use a provider that supports all the authentication mechanisms you need" -- but it would be convenient to have multiple mechanisms right here as well.)

* Even identity providers (like Google OpenID) that supply anonymized identity strings can be used to log in to multiple Arvados sites with the same ID.

In the current implementation (January 2015) permission records refer to the identity indirectly: they give the UUID of a user record which was assigned by the API server; the user record mentions the ID supplied by sso-provider, which is the ID originally supplied by the user's authentication provider. This can be fixed in two stages: (1) sso-provider should supply an Arvados UUID rather than the upstream provider's resource owner ID (each sso-provider instance will have a site prefix); (2) API server should use the supplied UUID as the UUID of the user record, tail_uuid of permission links, etc., instead of keeping a level of indirection in the user record. (If an installer really wants an extra level of redirection to map local IDs to federated IDs, that should be achieved by installing a local sso-provider rather than building an extra level of indirection into API server.)

Links

* https://tools.ietf.org/html/rfc6749

* https://developers.google.com/accounts/docs/OAuth2