Bug #13020: Login into workbench with a salted token activates a previously inactive federated account - Arvados

Actions

Copy link

Bug #13020

closed

Login into workbench with a salted token activates a previously inactive federated account

Added by Lucas Di Pentima almost 7 years ago. Updated about 5 years ago.

Status:

Duplicate

Priority:

Normal

Assigned To:

Lucas Di Pentima

Category:

API

Target version:

Start date:

10/30/2019

Due date:

% Done:

100%

Estimated time:

(Total: 0.00 h)

Story points:

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.

Subtasks 1 (0 open — 1 closed)

Related issues 2 (0 open — 2 closed)

Actions

Copy link

Updated by Lucas Di Pentima almost 7 years ago

Related to Story #11454: Support federated search across a set of Arvados clusters added

Actions

Copy link

Updated by Tom Morris almost 7 years ago

Target version set to 2018-02-14 Sprint

Actions

Copy link

Updated by Lucas Di Pentima almost 7 years ago

Assigned To set to Lucas Di Pentima

Actions

Copy link

Updated by Lucas Di Pentima almost 7 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by Lucas Di Pentima almost 7 years ago

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

Actions

Copy link

Updated by Tom Clegg almost 7 years ago

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.

Actions

Copy link

Updated by Lucas Di Pentima almost 7 years ago

Target version changed from 2018-02-14 Sprint to 2018-02-28 Sprint

Actions

Copy link

Updated by Lucas Di Pentima almost 7 years ago

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.

Actions

Copy link