Idea #13255
closedProvide account activation configuration options for federated logins
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)
Related issues
Updated by Tom Morris over 6 years ago
- Description updated (diff)
- Status changed from In Progress to New
Updated by Tom Clegg over 6 years ago
- Related to Feature #12958: [Federation] Workbench login chooser added
Updated by Tom Morris over 6 years ago
- Target version changed from To Be Groomed to Arvados Future Sprints
Updated by Tom Morris over 6 years ago
- Target version changed from Arvados Future Sprints to 2018-07-03 Sprint
Updated by Lucas Di Pentima over 6 years ago
- Assigned To set to Lucas Di Pentima
Updated by Peter Amstutz over 6 years ago
- Assigned To changed from Lucas Di Pentima to Peter Amstutz
Updated by Peter Amstutz over 6 years ago
- Related to Bug #13020: Login into workbench with a salted token activates a previously inactive federated account added
Updated by Peter Amstutz over 6 years ago
13255-account-activation @ 0bcbbb13f9e278347e500fa344ee600891a9bcb8
Updated by Peter Amstutz over 6 years ago
Updated
13255-account-activation @ ebb7681e5cf4bc2825e8786ecda895e219158703
Updated by Lucas Di Pentima over 6 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.
Updated by Peter Amstutz over 6 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!
Updated by Peter Amstutz over 6 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|7f9465d37fcc3277128d3f4a611b778e24e530a5.