Project

General

Profile

Actions

Idea #13255

closed

Provide account activation configuration options for federated logins

Added by Tom Morris over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
06/21/2018
Due date:
Story points:
2.0
Release:
Release relationship:
Auto

Description

Currently, a user who authenticates for the first time to a "local" cluster using their existing account at a "remote" cluster (their "home" cluster) is automatically activated if
  • 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 2 (0 open2 closed)

Task #13659: Review 13255-account-activationResolvedPeter Amstutz06/22/2018Actions
Task #13672: document account activationResolvedPeter Amstutz06/21/2018Actions

Related issues

Related to Arvados - Feature #12958: [Federation] Workbench login chooserClosedActions
Related to Arvados - Bug #13020: Login into workbench with a salted token activates a previously inactive federated accountDuplicateLucas Di Pentima10/30/2019Actions
Actions #1

Updated by Tom Morris over 6 years ago

  • Status changed from New to In Progress
Actions #2

Updated by Tom Morris over 6 years ago

  • Description updated (diff)
  • Status changed from In Progress to New
Actions #3

Updated by Tom Clegg over 6 years ago

  • Related to Feature #12958: [Federation] Workbench login chooser added
Actions #4

Updated by Tom Clegg over 6 years ago

  • Description updated (diff)
Actions #5

Updated by Peter Amstutz over 6 years ago

  • Description updated (diff)
Actions #6

Updated by Peter Amstutz over 6 years ago

  • Description updated (diff)
Actions #7

Updated by Peter Amstutz over 6 years ago

  • Description updated (diff)
Actions #8

Updated by Tom Morris over 6 years ago

  • Story points set to 2.0
Actions #9

Updated by Tom Morris over 6 years ago

  • Target version changed from To Be Groomed to Arvados Future Sprints
Actions #10

Updated by Tom Morris over 6 years ago

  • Target version changed from Arvados Future Sprints to 2018-07-03 Sprint
Actions #11

Updated by Lucas Di Pentima over 6 years ago

  • Assigned To set to Lucas Di Pentima
Actions #12

Updated by Peter Amstutz over 6 years ago

  • Assigned To changed from Lucas Di Pentima to Peter Amstutz
Actions #14

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
Actions #17

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.

Actions #18

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:

https://dev.arvados.org/projects/arvados/repository/revisions/645e9829bec9147f52141b17b439f9b561ed3445/diff/services/api/test/integration/remote_user_test.rb

Apart from that, LGTM.

Thanks!

Actions #19

Updated by Peter Amstutz over 6 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
Actions #20

Updated by Tom Morris over 6 years ago

  • Release set to 13
Actions

Also available in: Atom PDF