External Login Flow Improvements

[ahmedhamidawan]

There are several issues with logging in to Galaxy through external login providers such as AAF (Galaxy AU) and Custos.

Known Issues:

Here are some of the known issues:

• External linked account followed by local account creation will allow the local account to be created using the same email address as linked via 3rd party
• If an external identity is linked to an account already, it should not be possible to link it to another account
• Linking multiple identities to an account is broken (the initial linked identity is the only one that is used)
• If an account is linked in the current browser session, even if you log out and try other identities or accounts, OIDC will keep logging you into that same account that was first logged in externally. (only occurs for the current session)
• If an account was created by OIDC, the user still has the option to unlink it in User Preferences, meaning they will lose login credentials to that account.

Proposed Login Flow:

Here is a proposed login flow that might prevent the issues above from taking place:

Can be seen here: https://drive.google.com/file/d/10V5yqAb7Rf5snzrEchMj_-wv-xUmoUe0/view?usp=sharing

Usage Scenarios:

Here are all of the identified login usage scenarios (and their possible solutions*):

• A new user registers using the username & pwd
• A new user registers using Custos
• A user with an existing username & pwd links an external identify and, from then on, is able to log in using either the username & pwd or the external identity
• A user with an existing username & pwd attempts to log in using an external identity without having linked it
  • Fixed: Return to login saying this account does not exist and needs to be linked or created first
• A user with an existing username & pwd registers a new account using an external identity
  • Fixed: New accounts are created explicitly by registering and a splash screen warns of a new/duplicate acct
• An existing user links multiple external identities
  • broken/bug
• A user that created a new account via Custos unlinks all external identities
  • Solution: Require a password to be set before unlinking the last identity

• checked scenarios are fixed already

[dannon]

@ahmedhamidawan Thanks for setting up the planning issue! ping @neoformit

[neoformit]

I'll review with Maddie in our meeting next Tuesday and add a few suggestions. Thanks for setting up Ahmed!

[neoformit]

@madeline3000

[madeline3000]

Hello all,

Here is a user flow we mapped out earlier this year.

https://miro.com/app/board/uXjVPTAX1xM=/?share_link_id=212779270450

The main issue we encountered was how an existing Galaxy user with institutional credentials could "link" their account so their AAF (custos) could merge with their existing Galaxy email account. The current flow was very confusing for the user and involved many steps (see flow diagram). Our solution to this was to present the user with a linking screen as soon as they validated themselves through AAF, and then ask them to input their existing Galaxy password to verify they indeed were the owner of the existing account. This solution was validated thru consultation with technical devs, and through usability testing with Galaxy AU users.

Existing user - https://xd.adobe.com/view/12c1f83a-b7b1-4df2-be21-1e94361d77b6-4792/
New user - https://xd.adobe.com/view/5ac417ba-68e1-437b-8038-589a9166520c-0f97/

1. An existing user links multiple external identities
   broken/bug
2. A user that created a new account via Custos unlinks all external identities
   Solution: Require a password to be set before unlinking the last identity

I don't think we have considered these scenarios yet.

3. External linked account followed by local account creation will allow the local account to be created using the same email address as linked via 3rd party

@neoformit let's test this one on our end.

@ahmedhamidawan @neoformit what are next steps?

Madeline

[neoformit]

Should #3 return something like "sorry, an account already exists with that address"? Though I guess if they can do this and validate their email they should be allowed to take ownership of the account this way. This one is hard, maybe shelf for now?

I think we should start with the most tangible (preferably most common) use case and work on a fix for that first. Probably the OIDC login to existing account flow, with the "link accounts" dialog. The backend should already be available for that, but it might need a little jigging around.

Then we can focus on fixing the next user case.

What do you think @ahmedhamidawan?

@madeline3000 what do you want to test out on our end?