Story #13255

Provide account activation configuration options for federated logins

Added by Tom Morris about 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Peter Amstutz
Category:
-
Target version:
2018-07-03 Sprint
Start date:
06/21/2018
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
2.0
Release:
Arvados 1.2
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

Task #13659: Review 13255-account-activationResolvedPeter Amstutz

Task #13672: document account activationResolvedPeter Amstutz

Related issues

Related to Arvados - Feature #12958: [Federation] Workbench login chooserClosed

Related to Arvados - Bug #13020: Login into workbench with a salted token activates a previously inactive federated accountDuplicate10/30/2019

Associated revisions

Revision 7f9465d3
Added by Peter Amstutz almost 4 years ago

Merge branch '13255-account-activation' closes #13255

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <>

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

#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:

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

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

#20 Updated by Tom Morris almost 4 years ago

  • Release set to 13

Also available in: Atom PDF