Feature #4637
closed[SSO] Use "authentications" table and support account linking
100%
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.)