Bug #16726

other cluster's special users (root and anonymous) can appear in user list

Added by Peter Amstutz about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Target version:
Start date:
08/31/2020
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release relationship:
Auto

Description

When using a federation, it's possible to use the anonymous user of one cluster to access another cluster (for example, it does a lookup by PDH across the federation on behalf of the anonymous user). This works but is confusing because it results in two or more "anonymous" users appearing in the user list, belonging to different clusters.

Possible fixes:

  1. Hide the foreign anonymous user from the user list
  2. Notice when the user uuid ends in "-tpzed-anonymouspublic" and associate it with the local anonymous user instead of creating a new account
  3. When making a federated request as the anonymous user, substitute the other cluster's published anonymous user token.

There's a similar issue with the system user (root). System users should probably not federate at all.

There's also more general UX problem of user accounts from different clusters having the same name and appearing in the user list, which is confusing.


Subtasks

Task #16762: Review 16726-anon-fedResolvedPeter Amstutz


Related issues

Related to Arvados - Bug #16683: Trouble sharing with federated usersResolved08/13/2020

Related to Arvados - Bug #16789: missing can_read link from anonymous_user to anonymous_groupRejected

Related to Arvados - Feature #16794: API ensures configured Users.AnonymousUserToken is validClosed

Related to Arvados - Feature #17298: remove the need to run get_anonymous_user_token.rb during installationNew

Associated revisions

Revision a528347f
Added by Peter Amstutz about 1 year ago

Merge branch '16726-anon-user-token' refs #16726

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

Revision 7885ae2c (diff)
Added by Ward Vandewege 9 months ago

Documentation: reflect the current state of anonymous token generation.

refs #16726

Arvados-DCO-1.1-Signed-off-by: Ward Vandewege <>

Revision 5945736d (diff)
Added by Ward Vandewege 9 months ago

Documentation: reflect the current state of anonymous token generation.

refs #16726

Arvados-DCO-1.1-Signed-off-by: Ward Vandewege <>

History

#1 Updated by Peter Amstutz about 1 year ago

  • Category set to API
  • Description updated (diff)
  • Subject changed from hide other cluster's special users (root and anonymous) from user listings to other cluster's special users (root and anonymous) can appear in user list

#2 Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)

#3 Updated by Peter Amstutz about 1 year ago

  • Related to Bug #16683: Trouble sharing with federated users added

#4 Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Peter Amstutz

#5 Updated by Peter Amstutz about 1 year ago

16726-anon-fed @ 87977ae72b8cfded3263b109caa5245fa1abd74f

  • maps remote anonymous user to local anonymous user
  • remote system user is always named "root from #{cluster}"

I decided not to flat out reject remote system users. When LoginCluster is in use, we want the system user to work everywhere. In other cases, it seems good enough to make sure the remote system user won't be confused with the local one.

#6 Updated by Peter Amstutz about 1 year ago

  • Related to Bug #16789: missing can_read link from anonymous_user to anonymous_group added

#7 Updated by Lucas Di Pentima about 1 year ago

I think the code LGTM, but I just wanted to double-check by manually starting a federation and checking the UX aspect this branch fixes.
The result is that I couldn't even log into a federated cluster, because the token being returned wasn't v2. Not sure if I made a mistake in the process, I wanted to point it out just in case.

#8 Updated by Peter Amstutz about 1 year ago

Lucas Di Pentima wrote:

I think the code LGTM, but I just wanted to double-check by manually starting a federation and checking the UX aspect this branch fixes.
The result is that I couldn't even log into a federated cluster, because the token being returned wasn't v2. Not sure if I made a mistake in the process, I wanted to point it out just in case.

It is a little more subtle than that.

What happens is you use the anonymous token for cluster1 to fetch a collection from cluster2 via the cluster1 controller. The controller makes sure the token is a v2 token.

I will see about creating an integration test for this.

#9 Updated by Peter Amstutz about 1 year ago

16726-anon-user-token @ 09ff850dc6e3e8f10d7d96adfc02674222f7aa9a

  • Initialize anonymous user token in arvados-boot.
  • Integration test using anonymous token to fetch a collection

https://ci.arvados.org/view/Developer/job/developer-run-tests/2062/

#10 Updated by Peter Amstutz about 1 year ago

  • Status changed from New to In Progress

#11 Updated by Peter Amstutz about 1 year ago

  • Related to Feature #16794: API ensures configured Users.AnonymousUserToken is valid added

#12 Updated by Lucas Di Pentima about 1 year ago

Reviewing 16726-anon-user-token - 09ff850

Just one suggestion:

  • At file services/api/script/get_anonymous_user_token.rb Lines 59-62: I believe you could simplify a little by using find_or_create_by()

The rest LGTM, thanks.

#13 Updated by Peter Amstutz about 1 year ago

  • Status changed from In Progress to Resolved

#14 Updated by Peter Amstutz about 1 year ago

  • Release set to 25

#15 Updated by Ward Vandewege 9 months ago

  • Related to Feature #17298: remove the need to run get_anonymous_user_token.rb during installation added

Also available in: Atom PDF