Story #11453

Federated user identity which works across a network of Arvados clusters

Added by Tom Morris 7 months ago. Updated 11 days ago.

Status:In ProgressStart date:06/20/2017
Priority:NormalDue date:
Assignee:Tom Clegg% Done:

25%

Category:-
Target version:2017-11-22 Sprint
Story points2.0Remaining (hours)0.00 hour
Velocity based estimate0 days

Description

Basic elements:
- a single login server which provides authentication for all clusters in the network
- a single user UUID is used across all nodes in the cluster.

API server needs two additional features:
1. Validate salted token by contacting origin cluster
2. As an origin cluster, validate a received token from a remote cluster

Validation requests return the user record which is used to populate the local user table, along with an expiration time after which revalidation should occur.

Draft: Federated identity

Migration process from local identity to network identity is separate


Subtasks

Task #11874: [Spike] Prototype federated identityNew

Task #12424: Migration process to convert local user IDs to network cl...New

Task #12455: Validate v2-format salted tokensResolvedTom Clegg

Task #12440: Review 11453-federated-tokensIn ProgressTom Clegg


Related issues

Blocks Arvados - Story #11454: Support federated search across a set of Arvados clusters New 04/11/2017

History

#1 Updated by Tom Clegg 7 months ago

  • Description updated (diff)

#2 Updated by Tom Morris 3 months ago

  • Target version set to Arvados Future Sprints

#3 Updated by Tom Morris about 1 month ago

  • Description updated (diff)

#4 Updated by Tom Morris about 1 month ago

  • Description updated (diff)

#5 Updated by Tom Morris about 1 month ago

  • Description updated (diff)
  • Story points set to 2.0

#6 Updated by Tom Morris about 1 month ago

  • Assignee set to Tom Clegg
  • Target version changed from Arvados Future Sprints to 2017-10-25 Sprint

#7 Updated by Tom Clegg about 1 month ago

  • Status changed from New to In Progress

#8 Updated by Peter Amstutz 25 days ago

  • Target version changed from 2017-10-25 Sprint to 2017-11-08 Sprint

#9 Updated by Peter Amstutz 23 days ago

  • When validating a remote user, is_admin is forced to be false, but is_active is accepted from the remote site. I understand if the remote user is not active we shouldn't accept the token, however this also ignores the local configuration Rails.configuration.new_users_are_active when the user is initially created, which prevents the cluster admin from requiring manual activation of remote users.
  • It looks like once a user account is created, a user could create a new token one the remote cluster and start using that, bypassing validation with the home cluster. Is that desirable / intentional?
  • test "list readable groups with salted token" checks for the presence of "all users" and absence of "system group" but not any other group fixtures. Since these are special group ids they could conceivably have special behavior that subverts the test.
  • RemoteUserAccountTest would benefit from some comments. I think what it is doing is setting up a web server in a separate thread so that the "auth" method can call "ArvadosApiToken" which calls "ApiClientAuthorization.validate" which contacts the stub web server? And the behavior of the stub web server is predetermined, so we're only testing the client side?
  • In validate() you call uuid[0..4] in a couple of places, it might be easier to understand if it was assigned to a variable with a descriptive name like "token_uuid_prefix".

#10 Updated by Peter Amstutz 23 days ago

test 'remote api server is not an api server' should return status 200.

should bail out if 'uuid' or 'secret' is empty or nil (in case of maelformed v2/ tokens)

should test maelformed v2/ tokens.

is there a test that re-validates an expired token?

what happens if a remote user has an email address or username that conflicts with a local user?

what happens if the remote user's email address or username changes?

(currently, it looks like usernames are required to be unique, email is not).

it looks like the remote auth token caching doesn't set the "secret" field, so subsequent requests won't use it but (possibly) re-validate instead.

need a test for auth token caching.

what's the rationale for putting the "validate token from remote cluster" logic in load_read_auths of application_controller instead of in the arvados_api_token middleware?

The "validate token from remote cluster" logic should ensure that the HTTP method is GET.

#11 Updated by Peter Amstutz 20 days ago

All new tokens given to the client should be v2/ format tokens so the client can tell if it is talking to the home cluster or a remote cluster and determine if it needs to salt the token or not.

#12 Updated by Tom Clegg 20 days ago

Peter Amstutz wrote:

  • When validating a remote user, is_admin is forced to be false, but is_active is accepted from the remote site. I understand if the remote user is not active we shouldn't accept the token, however this also ignores the local configuration Rails.configuration.new_users_are_active when the user is initially created, which prevents the cluster admin from requiring manual activation of remote users.

Right. As it stands, if you accept users from remote site X, then you rely on site X's activation policy. Since the default config accepts users from *.arvadosapi.com, this seems rather permissive.

(todo?) set is_active=remote_is_active if (!remote_is_active or local_auto_activate); otherwise, leave it alone so local admin can activate

(todo) consider other activation stuff, like adding to "all users" group

  • It looks like once a user account is created, a user could create a new token one the remote cluster and start using that, bypassing validation with the home cluster. Is that desirable / intentional?

This does sound dubious in that it could effectively bypass the home cluster's token expiry time.

One such procedure (login with google at remote's SSO → create session at remote's API based on matching identity_url) can be fixed (in user_sessions_controller#create) by matching existing users on identity_url only if uuid[0..4] matches Rails.configuration.uuid_prefix.

For UX (avoiding accidentally creating a local account instead of using a remote account), for now we're assuming nobody will point their web browser at a "remote" api server.

Do you have other "create a new token" procedures in mind?

  • test "list readable groups with salted token" checks for the presence of "all users" and absence of "system group" but not any other group fixtures. Since these are special group ids they could conceivably have special behavior that subverts the test.

(todo) add checks for other fixtures

  • RemoteUserAccountTest would benefit from some comments. I think what it is doing is setting up a web server in a separate thread so that the "auth" method can call "ArvadosApiToken" which calls "ApiClientAuthorization.validate" which contacts the stub web server? And the behavior of the stub web server is predetermined, so we're only testing the client side?

(todo) add comments here

Yes. So far we just have separate tests for the server side and the client side. An integration test will require multiple uuid-prefixes = multiple apiserver instances = multiple databases = ... some more work.

  • In validate() you call uuid[0..4] in a couple of places, it might be easier to understand if it was assigned to a variable with a descriptive name like "token_uuid_prefix".

(todo)

#13 Updated by Tom Clegg 11 days ago

  • Target version changed from 2017-11-08 Sprint to 2017-11-22 Sprint

Also available in: Atom PDF