Idea #12995
Updated by Peter Amstutz about 6 years ago
Use case: A * As I understood, the basic idea is to make a self-served version of what’s described on: https://doc.arvados.org/admin/change-account-owner.html * The user has a new authentication (eg Google) account. User has previously being logged in using some other authentication account (eg LDAP) and already has an Aravdos account. User wants to link their existing Arvados account to the new authentication account so that when they log in with the new authentication account, they are logged into their existing Arvados account. h2. Entry points # User is logged in to Workbench using old authentication account, selects "link google account presses a new authentication method" button named something like “Link to a different login account”, maybe from menu the “Manage profile” section at workbench # User attempts to log in using new authentication account, gets an inactive account page # User attempts to log in using new authentication account, * The user is logged then sent into a new active empty account. h2. Flow for (1) # On workbench, click on "link new auth method" # Browser is sent login flow with a different @?return_to=@ url param, used to api_server/logout?return_to=http://workbench/link_accounts?link_to=api_token # Browser is logged out from API and SSO, and redirected indicate to workbench link_accounts page with "link_to" containing that the api token of the old Arvados account # Workbench redirects browser to api_server/login?return_to=http://workbench/link_accounts?link_to=api_token # User logs in and browser operation is sent back to workbench with &api_token=... of new Arvados account about changing login accounts. # Workbench now has both API token ** (Maybe instead of sending the account user to link to, and an api_token of the newly created account API’s @/login@ url, we would need a different endpoint? # Workbench sends request to API server to make * SSO related stuff should return the user that owns api_token an alias for the user in link_to @identity_url@ # Workbench sets the link_to API token * Somewhere in between there’s a user lookup or creation using the cookie, identity_url. This should be replaced and presents instead the user with a "success" page h2. Flow for (2) # User is at inactive user page. Text says "if you have logged in with a different account, click here @identity_url@ be passed to link your account" # Browser is sent to api_server/logout?return_to=http://workbench/link_accounts?link_from=api_token # Browser is logged out from API and SSO, and redirected to workbench link_accounts page with "link_from" containing the api token workbench, maybe as part of the new Arvados account @return_to@ url # * Workbench redirects browser to api_server/login?return_to=http://workbench/link_accounts?link_from=api_token # User logs in and browser is sent back to workbench checks there’s an existing account with &api_token=... of old Arvados account that @identity_url@ (is that an operation allowed by a normal user?) # Workbench now has both API token of ** If yes but inactive, hijack the account to link from, @identity_url@ and an api_token of the old account email address # Workbench sends request to API server to make ** If yes, but active: ask the user that owns link_from an alias for the user in api_token # Workbench sets ** If no: replace the api_token API token in the cookie, and presents the user current one with a "success" page h2. Flow for (3) # In the notifications area of workbench, if the user account seems to be "empty", provide message "if you have logged in with a different account, click here to link your account" new one. # Do flow for (2) * Affected modules: ** Workbench ** API ** (maybe?) SSO