Failure when user can authenticate the same account name via multiple IDPs

[theferrit32]

Example:

IntegrityError at /authcallback

duplicate key value violates unique constraint "token_service_user_user_name_key"
DETAIL:  Key (user_name)=([email protected]) already exists.

This is due to get_user trying to match an accepted auth callback to a user using sub and provider, not finding one, and then trying to create a new user object for it. However if a user has authenticated the same account name with a different provider, this second attempt will fail.

Need time to explore whether there is any security vulnerability in expanding the User uniqueness tuple from (sub, provider) to (sub, provider, user_name) and removing the individual column uniqueness constraint on user_name.

The Auth0 broker passes through the same sub for a given user_name as is used in the IDP backend itself. Example scenario after expanding the uniqueness tuple to incorporate user_name, which is currently disallowed:

id	sub	provider	user_name	name	email
1	a1b2c3	auth0|globus	[email protected]	User One	[email protected]
2	a1b2c3	globus	[email protected]	User One	[email protected]

The other concern is how this would impact services relying on tokens, as the two users would technically have a different set of tokens attached to them. In addition, queries for token based on sub+provider need to be careful to disambiguate, and possibly require that the whole provider information (auth0|globus) is sent in the request, rather than just auth0. Or possibly facilitate this startswith matching behavior by allowing a "compound": true value set in config.json on that provider. If the provider is not compound, then the entire provider string must match on token requests.