Feature #4637
closed[SSO] Use "authentications" table and support account linking
Description
The SSO server has a (at least partial) capability to link multiple external provider accounts to the same user account. However, we currently bypass this capability and store the user id directly on the user record in "identity_url". We should:
- Remove the "identity_url" column and migrate it's contents to the 'authentications' table
- Enable users who are already logged in with one account to link additional accounts by logging in to other providers.
We're currently bypassing an existing abstraction in the SSO server that separates the concept of a user from the concept of a particular authentication provider. That's a problem because if we want to support multiple account providers (independently of account linking) we can't because we're bypassing the "authentications" table that is intended for that purpose. The way the SSO server was intended to be used, you identify users based on a user id allocated by the SSO server. Right now, we're passing through the OpenId "identity_url". But now we need to migrate to OAuth2. This is a blocker for supporting multiple authentication providers (at a single sso install).
The intended design of the SSO server (from the upstream developers) was you have a "users" table and each "user" has one or more "authentications". The "authentications" has the (provider, uid) tuple. But currently it ignores the "authentications" table and uses a hacked on "identity_url" on the "users" table, which ties it to OpenId 2.0, since the "users" table doesn't specify which provider is being used (but the "authentications" table does.)
Updated by Peter Amstutz about 10 years ago
- Tracker changed from Bug to Feature
- Description updated (diff)
Updated by Tom Morris about 7 years ago
- Assigned To set to Peter Amstutz
The SSO server is based on Devise and Omniauth. Let's investigate the current state of play and update the story to reflect what needs to be done.
Updated by Peter Amstutz about 7 years ago
- Target version changed from To Be Groomed to 2017-11-08 Sprint
Updated by Peter Amstutz about 7 years ago
- Target version changed from 2017-11-08 Sprint to To Be Groomed
Updated by Tom Clegg about 7 years ago
This seems to be mostly about catering to the sso-provider design. IMO our use of sso-provider is an awful hack that will die when we implement a sane authentication process, so I'm finding it hard to get excited about using its features.
I recommend we back off a bit from the implementation details and describe (from the user's perspective) with greater precision what "account linking" is expected to accomplish in various scenarios.
(My hope is that we can achieve that without making sso-provider any more entrenched.)
Updated by Tom Morris about 7 years ago
- Related to Feature #12626: [API] Merge user accounts (redirect=true case) added
Updated by Tom Morris almost 7 years ago
- Status changed from New to Rejected
We're going to support multiple accounts via the API server instead.
Updated by Tom Morris almost 7 years ago
- Target version deleted (
To Be Groomed)