Story #4927
closed[SSO] Decide overall single sign-on strategy
Added by Tom Clegg almost 10 years ago. Updated about 7 years ago.
0%
Updated by Tom Clegg almost 10 years ago
- Subject changed from [SSO] Design overall single sign-on strategy to [SSO] Decide overall single sign-on strategy
Updated by Tom Clegg almost 10 years ago
- Assigned To changed from Tim Pierce to Tom Clegg
- Story points changed from 2.0 to 1.0
Updated by Peter Amstutz almost 10 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.
Updated by Tom Clegg almost 10 years ago
- Description updated (diff)
- Category set to SSO
Updated by Tom Clegg almost 10 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. |
Updated by Tom Clegg almost 10 years ago
- Status changed from In Progress to Resolved