Story #13255
Provide account activation configuration options for federated logins
100%
Description
- Their account is active at their "home" cluster, and
- "Auto-activate new users" is enabled on the local cluster.
Otherwise, the user lands in an inactive account.
Options:- auto activate federated remote accounts
- allow specific approval and activation of remote accounts (??? does this mean current behavior?)
Proposed behaviors¶
- Auto activate: list of cluster ids for which it honors the "is_active" flag (current behavior is to ignore the is_active flag and use the local cluster's autoactivate policy)
Subtasks
Related issues
Associated revisions
History
#1
Updated by Tom Morris about 4 years ago
- Status changed from New to In Progress
#2
Updated by Tom Morris about 4 years ago
- Description updated (diff)
- Status changed from In Progress to New
#3
Updated by Tom Clegg about 4 years ago
- Related to Feature #12958: [Federation] Workbench login chooser added
#4
Updated by Tom Clegg about 4 years ago
- Description updated (diff)
#5
Updated by Peter Amstutz about 4 years ago
- Description updated (diff)
#6
Updated by Peter Amstutz about 4 years ago
- Description updated (diff)
#7
Updated by Peter Amstutz about 4 years ago
- Description updated (diff)
#8
Updated by Tom Morris about 4 years ago
- Story points set to 2.0
#9
Updated by Tom Morris about 4 years ago
- Target version changed from To Be Groomed to Arvados Future Sprints
#10
Updated by Tom Morris almost 4 years ago
- Target version changed from Arvados Future Sprints to 2018-07-03 Sprint
#11
Updated by Lucas Di Pentima almost 4 years ago
- Assigned To set to Lucas Di Pentima
#12
Updated by Peter Amstutz almost 4 years ago
- Assigned To changed from Lucas Di Pentima to Peter Amstutz
#14
Updated by Peter Amstutz almost 4 years ago
- Related to Bug #13020: Login into workbench with a salted token activates a previously inactive federated account added
#15
Updated by Peter Amstutz almost 4 years ago
13255-account-activation @ 0bcbbb13f9e278347e500fa344ee600891a9bcb8
#16
Updated by Peter Amstutz almost 4 years ago
Updated
13255-account-activation @ ebb7681e5cf4bc2825e8786ecda895e219158703
#17
Updated by Lucas Di Pentima almost 4 years ago
Very clear documentation! I would add a test to check for the negative case (users from non trusted clusters aren't auto-activated), is that implicitly proved on preexisting tests?
Apart from that, LGTM.
#18
Updated by Peter Amstutz almost 4 years ago
Lucas Di Pentima wrote:
Very clear documentation! I would add a test to check for the negative case (users from non trusted clusters aren't auto-activated), is that implicitly proved on preexisting tests?
Yes that's covered already, I added a check to an existing test that is_active is false:
Apart from that, LGTM.
Thanks!
#19
Updated by Peter Amstutz almost 4 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|7f9465d37fcc3277128d3f4a611b778e24e530a5.
#20
Updated by Tom Morris almost 4 years ago
- Release set to 13
Merge branch '13255-account-activation' closes #13255
Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <pamstutz@veritasgenetics.com>