Bug #13020
closed
Login into workbench with a salted token activates a previously inactive federated account
Added by Lucas Di Pentima about 6 years ago.
Updated over 4 years ago.
Description
Scenario:
- clusterH: Home cluster with local active account
- clusterR: Remote cluster with clusterH alredy existing federated (and inactive) account (Also
new_users_are_active=false setting on clusterR)
When having an inactive federated account on clusterR from clusterH, if the user logs into clusterR's workbench using the salted token:
https://workbench.clusterR.arvadosapi.com/?api_token=v2/clusterHsaltedtoken
..the result is that the user is redirected to her/his federated account on clusterR's workbench, as the federated account's is_active attribute changed to true.
- Related to Idea #11454: Support federated search across a set of Arvados clusters added
- Target version set to 2018-02-14 Sprint
- Assigned To set to Lucas Di Pentima
- Status changed from New to In Progress
Some notes on the investigation:
- Apparently the issue is with any kind of login: When logging in with an inactive local account on qr1hi, the account gets auto-activated.
- Wrote test that exposes the bug, still looking for the cause.
- Testing live clusters I found that:
- Arvbox: BUG - f7d7147 (8 February)
- Arvbox: BUG - ee8558ddd (5 December - previous to federated tokens)
- qr1hi: BUG - 9b7a5de (12 December)
- c97qk: GOOD - b3e8a48 (1 February)
- 9tee4: GOOD
- su92l: BUG
- 4xphq: BUG
An account can be "inactive" and "setup" (aka "invited"). In that state, a user can self-activate if the "user agreement" requirement is met. Workbench calls "activate" automatically in this situation.
This makes the following sequence possible:
- New user logs in using Google account → inactive account
- Admin hits "setup" button (this adds the user to the "all users" group)
- User is still inactive because user agreements are not signed
- User signs user agreements (via Workbench)
- Workbench detects that all user agreements are signed, and calls "activate" API
- User is active
Otherwise, the admin would need to wait for the user to sign all user agreements before hitting the "setup" button, which would be annoying (even if the admin had an easy way to see whether they are signed, which they currently don't).
So perhaps we can rephrase this: "turning off the "is_active" flag is a tempting but ineffective way to disable an account." The admin "unsetup" button in Workbench is the right way.
- Target version changed from 2018-02-14 Sprint to 2018-02-28 Sprint
As suggested by Tom Clegg on the chat, this issue is related to #10557 (021d36f17fe0329e869324d3764eaaf15c3a0771), we have two options:
- Show a notice to the user that making
is_active=false is not the correct way of deactivating an account.
- Modify the API server so that it deactivates the user properly when this flag is set to
false.
Personally I would prefer the second option for consistency purposes, but Tom suggested that proper user deactivation is hard to reverse, so I suppose that some kind of confirmation from the user would be needed.
- Target version changed from 2018-02-28 Sprint to 2018-03-14 Sprint
- Target version changed from 2018-03-14 Sprint to 2018-03-28 Sprint
- Target version deleted (
2018-03-28 Sprint)
- Related to Idea #13255: Provide account activation configuration options for federated logins added
- Status changed from In Progress to New
- Status changed from New to Duplicate
Also available in: Atom
PDF
Updated by 
Updated by Tom Morris 
Updated by 
Updated by