Project

General

Profile

Actions

Feature #4637

closed

[SSO] Use "authentications" table and support account linking

Added by Peter Amstutz about 10 years ago. Updated almost 7 years ago.

Status:
Rejected
Priority:
Normal
Assigned To:
Category:
SSO
Target version:
-
Start date:
11/06/2017
Due date:
% Done:

100%

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

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


Subtasks 1 (0 open1 closed)

Task #12489: Groom & implementation planClosedPeter Amstutz11/06/2017

Actions

Related issues 2 (0 open2 closed)

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

Actions
Related to Arvados - Feature #12626: [API] Merge user accounts (redirect=true case)ResolvedTom Clegg05/03/2018

Actions
Actions #1

Updated by Peter Amstutz about 10 years ago

  • Tracker changed from Bug to Feature
  • Description updated (diff)
Actions #2

Updated by Peter Amstutz about 10 years ago

  • Description updated (diff)
Actions #3

Updated by Brett Smith about 10 years ago

  • Category set to SSO
Actions #4

Updated by Tom Morris about 7 years ago

  • Target version set to To Be Groomed
Actions #5

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.

Actions #6

Updated by Peter Amstutz about 7 years ago

  • Target version changed from To Be Groomed to 2017-11-08 Sprint
Actions #7

Updated by Peter Amstutz about 7 years ago

  • Target version changed from 2017-11-08 Sprint to To Be Groomed
Actions #8

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

Actions #9

Updated by Tom Morris about 7 years ago

  • Related to Feature #12626: [API] Merge user accounts (redirect=true case) added
Actions #11

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.

Actions #12

Updated by Tom Morris almost 7 years ago

  • Target version deleted (To Be Groomed)
Actions

Also available in: Atom PDF