Bug #16726
closed
other cluster's special users (root and anonymous) can appear in user list
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:
- Hide the foreign anonymous user from the user list
- Notice when the user uuid ends in "-tpzed-anonymouspublic" and associate it with the local anonymous user instead of creating a new account
- 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.
Updated by Peter Amstutz over 4 years 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
Updated by Peter Amstutz over 4 years ago
- Related to Bug #16683: Trouble sharing with federated users added
Updated by Peter Amstutz over 4 years 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.
Updated by Peter Amstutz over 4 years ago
- Related to Bug #16789: missing can_read link from anonymous_user to anonymous_group added
Updated by Lucas Di Pentima over 4 years 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.
Updated by Peter Amstutz over 4 years 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.
Updated by Peter Amstutz over 4 years ago
16726-anon-user-token @ 09ff850dc6e3e8f10d7d96adfc02674222f7aa9a
- Initialize anonymous user token in arvados-boot.
- Integration test using anonymous token to fetch a collection
Updated by Peter Amstutz over 4 years ago
- Status changed from New to In Progress
Updated by Peter Amstutz over 4 years ago
- Related to Feature #16794: API ensures configured Users.AnonymousUserToken is valid added
Updated by Lucas Di Pentima over 4 years ago
Reviewing 16726-anon-user-token - 09ff850
Just one suggestion:
- At file
services/api/script/get_anonymous_user_token.rbLines 59-62: I believe you could simplify a little by usingfind_or_create_by()
The rest LGTM, thanks.
Updated by Peter Amstutz over 4 years ago
- Status changed from In Progress to Resolved
Updated by Ward Vandewege almost 4 years ago
- Related to Feature #17298: remove the need to run get_anonymous_user_token.rb during installation added