Story #4927

[SSO] Decide overall single sign-on strategy

Added by Tom Clegg over 5 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
SSO
Target version:
Start date:
01/12/2015
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)
Story points:
1.0

Description


Subtasks

Task #4959: Write up [[Authentication]] pageResolvedTom Clegg


Related issues

Related to Arvados - Feature #4601: [SSO] Migrate OpenId users to OAuth/Google+Resolved11/05/2014

History

#1 Updated by Tim Pierce over 5 years ago

  • Assigned To set to Tim Pierce

#2 Updated by Tom Clegg over 5 years ago

  • Subject changed from [SSO] Design overall single sign-on strategy to [SSO] Decide overall single sign-on strategy

#3 Updated by Tom Clegg over 5 years ago

  • Assigned To changed from Tim Pierce to Tom Clegg
  • Story points changed from 2.0 to 1.0

#4 Updated by Peter Amstutz over 5 years ago

Some notes:

We need a unified notion of identity across multiple Arvados instances. Federated instances should be able to access each other's data without requiring the user to log in twice.

Identity management can be centralized or decentralized:

Centralized: Have a single identity provider (SSO server instance) for Arvados federation. This is roughly what we have now, except that we are using Google OpenId 2.0 identity URLs to identify users (which ties us to Google, and who is shutting down OpenId 2.0) instead of generating our own identifiers. Provides a single place to add 3rd party identity providers (map 3rd party identity -> Arvados federated id). Enables any user to log in to any instance in the federation. Can tie multiple 3rd party accounts to the same identity to facilitate migration (for example, a researcher who's login is associated with her institution gets a job at a different institution, she can maintain the same Arvados identity and access but login with credentials from the new institution).

Decentralized: Support many identity providers. Use tuple of (identity provider, identifier) to identify users. Every Arvados instance needs to have a list of the identity providers that it recognizes. Users can only log into instances that recognize their identity provider. Current SSO server becomes redundant in this scenario, its capabilities could be merged into API server. Since accounts are tied to specific to the 3rd party providers, they can't easily migrate their Arvados account from one institution from another.

#5 Updated by Tom Clegg over 5 years ago

  • Description updated (diff)
  • Category set to SSO

#6 Updated by Tom Clegg over 5 years ago

  • Status changed from New to In Progress

#7 Updated by Tom Clegg over 5 years ago

Note decentralized/centralized is orthogonal to sso-provider/apiserver (N-1 apiserver instances could use one "central" apiserver as an OAuth2 provider. Or each apiserver instance could have its own sso-provider.)

The approach described on the Authentication page should support both independent and federated sites. Each site can decide whether it trusts an upstream sso-provider and whether it needs to support any additional authentication providers that aren't supported upstream.

Trust upstream? Need additional? What to do
Yes - Configure apiserver to use upstream sso-provider directly.
Yes Yes Configure apiserver to use local sso-provider. Configure local sso-provider to use upstream sso-provider and others. Optionally, pass through upstream sso-provider's UUIDs instead of mapping them onto the local namespace.
- Yes Configure apiserver to use local sso-provider. Configure local sso-provider to use desired providers.
- - Nobody can log in ever! Too secure.

#8 Updated by Tom Clegg over 5 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF