Feature #4637

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

Added by Peter Amstutz about 6 years ago. Updated almost 3 years ago.

Assigned To:
Target version:
Start date:
Due date:
% Done:


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


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


Task #12489: Groom & implementation planClosedPeter Amstutz

Related issues

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

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


#1 Updated by Peter Amstutz about 6 years ago

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

#2 Updated by Peter Amstutz almost 6 years ago

  • Description updated (diff)

#3 Updated by Brett Smith almost 6 years ago

  • Category set to SSO

#4 Updated by Tom Morris about 3 years ago

  • Target version set to To Be Groomed

#5 Updated by Tom Morris about 3 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.

#6 Updated by Peter Amstutz about 3 years ago

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

#7 Updated by Peter Amstutz about 3 years ago

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

#8 Updated by Tom Clegg about 3 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.)

#9 Updated by Tom Morris about 3 years ago

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

#11 Updated by Tom Morris almost 3 years ago

  • Status changed from New to Rejected

We're going to support multiple accounts via the API server instead.

#12 Updated by Tom Morris almost 3 years ago

  • Target version deleted (To Be Groomed)

Also available in: Atom PDF