[ARVADOS] updated: 1.1.4-499-g645e9829b
Git user
git at public.curoverse.com
Thu Jun 21 22:41:47 EDT 2018
Summary of changes:
doc/admin/activation.html.textile.liquid | 135 ++++++++++++++-------
doc/api/tokens.html.textile.liquid | 4 +
.../api/app/models/api_client_authorization.rb | 3 +-
services/api/app/models/user.rb | 1 +
services/api/config/application.default.yml | 16 ++-
services/api/test/integration/remote_user_test.rb | 13 ++
6 files changed, 127 insertions(+), 45 deletions(-)
via 645e9829bec9147f52141b17b439f9b561ed3445 (commit)
via 5d3a682b0fc41f4152051b43b8e5311b9a130f13 (commit)
via ec88f99b1eeb811159b3aea9a6f810dc06e9417b (commit)
via bd14cd71274109789ea076b1b4219bdf3beef657 (commit)
from 75f835af6ac337c490a76ac60453242719f6ceca (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
commit 645e9829bec9147f52141b17b439f9b561ed3445
Author: Peter Amstutz <pamstutz at veritasgenetics.com>
Date: Thu Jun 21 22:41:31 2018 -0400
13255: Add test for auto_activate_users_from
Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <pamstutz at veritasgenetics.com>
diff --git a/services/api/test/integration/remote_user_test.rb b/services/api/test/integration/remote_user_test.rb
index 6d7f4a061..7749951a8 100644
--- a/services/api/test/integration/remote_user_test.rb
+++ b/services/api/test/integration/remote_user_test.rb
@@ -85,6 +85,7 @@ class RemoteUsersTest < ActionDispatch::IntegrationTest
assert_response :success
assert_equal 'zbbbb-tpzed-000000000000000', json_response['uuid']
assert_equal false, json_response['is_admin']
+ assert_equal false, json_response['is_active']
assert_equal 'foo at example.com', json_response['email']
assert_equal 'barney', json_response['username']
@@ -218,4 +219,16 @@ class RemoteUsersTest < ActionDispatch::IntegrationTest
refute_includes(group_uuids, groups(:trashed_project).uuid)
refute_includes(group_uuids, groups(:testusergroup_admins).uuid)
end
+
+ test 'auto-activate with remote token' do
+ Rails.configuration.auto_activate_users_from = ['zbbbb']
+ get '/arvados/v1/users/current', {format: 'json'}, auth(remote: 'zbbbb')
+ assert_response :success
+ assert_equal 'zbbbb-tpzed-000000000000000', json_response['uuid']
+ assert_equal false, json_response['is_admin']
+ assert_equal true, json_response['is_active']
+ assert_equal 'foo at example.com', json_response['email']
+ assert_equal 'barney', json_response['username']
+ end
+
end
commit 5d3a682b0fc41f4152051b43b8e5311b9a130f13
Author: Peter Amstutz <pamstutz at veritasgenetics.com>
Date: Thu Jun 21 16:21:10 2018 -0400
13255: Implement auto_activate_users_from
Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <pamstutz at veritasgenetics.com>
diff --git a/services/api/app/models/api_client_authorization.rb b/services/api/app/models/api_client_authorization.rb
index b267a6388..8ea9f7bd8 100644
--- a/services/api/app/models/api_client_authorization.rb
+++ b/services/api/app/models/api_client_authorization.rb
@@ -161,7 +161,8 @@ class ApiClientAuthorization < ArvadosModel
end
end
- if Rails.configuration.new_users_are_active
+ if Rails.configuration.new_users_are_active ||
+ Rails.configuration.auto_activate_users_from.include?(remote_user['uuid'][0..4])
# Update is_active to whatever it is at the remote end
user.is_active = remote_user['is_active']
elsif !remote_user['is_active']
diff --git a/services/api/app/models/user.rb b/services/api/app/models/user.rb
index 9d4c20af9..a69dc7e92 100644
--- a/services/api/app/models/user.rb
+++ b/services/api/app/models/user.rb
@@ -26,6 +26,7 @@ class User < ArvadosModel
user.username.nil? and user.username_changed?
}
before_update :setup_on_activate
+ before_create :setup_on_activate
before_create :check_auto_admin
before_create :set_initial_username, :if => Proc.new { |user|
user.username.nil? and user.email
diff --git a/services/api/config/application.default.yml b/services/api/config/application.default.yml
index f51679135..5406e8d95 100644
--- a/services/api/config/application.default.yml
+++ b/services/api/config/application.default.yml
@@ -117,7 +117,11 @@ common:
### New user and & email settings
###
- # Config parameters to automatically setup new users.
+ # Config parameters to automatically setup new users. If enabled,
+ # this users will be able to self-activate. Enable this if you want
+ # to run an open instance where anyone can create an account and use
+ # the system without requiring manual approval.
+ #
# The params auto_setup_new_users_with_* are meaningful only when auto_setup_new_users is turned on.
# auto_setup_name_blacklist is a list of usernames to be blacklisted for auto setup.
auto_setup_new_users: false
@@ -125,7 +129,9 @@ common:
auto_setup_new_users_with_repository: false
auto_setup_name_blacklist: [arvados, git, gitolite, gitolite-admin, root, syslog]
- # When new_users_are_active is set to true, the user agreement check is skipped.
+ # When new_users_are_active is set to true, new users will be active
+ # immediately. This skips the "self-activate" step which enforces
+ # user agreements. Should only be enabled for development.
new_users_are_active: false
# The e-mail address of the user you would like to become marked as an admin
@@ -409,6 +415,12 @@ common:
# remote_hosts above.
remote_hosts_via_dns: false
+ # List of cluster prefixes. These are "trusted" clusters, users
+ # from the clusters listed here will be automatically setup and
+ # activated. This is separate from the settings
+ # auto_setup_new_users and new_users_are_active.
+ auto_activate_users_from: []
+
###
### Remaining assorted configuration options.
###
commit ec88f99b1eeb811159b3aea9a6f810dc06e9417b
Author: Peter Amstutz <pamstutz at veritasgenetics.com>
Date: Thu Jun 21 15:48:28 2018 -0400
13255: More discussion of federated users in account activation
Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <pamstutz at veritasgenetics.com>
diff --git a/doc/admin/activation.html.textile.liquid b/doc/admin/activation.html.textile.liquid
index 2d2d35151..a38b87796 100644
--- a/doc/admin/activation.html.textile.liquid
+++ b/doc/admin/activation.html.textile.liquid
@@ -10,46 +10,62 @@ Copyright (C) The Arvados Authors. All rights reserved.
SPDX-License-Identifier: CC-BY-SA-3.0
{% endcomment %}
-After completing the authentication process with the SSO server and receiving a new @identity_url@, a new user object is always created.
+This page describes how new users are created and activated.
-h3. Setup
+"Browser login and management of API tokens is described here.":{{site.baseurl}}/api/tokens.html
-If @auto_setup_new_users@ is true, as part of creating the new user object, the user is immediately setup with:
+h3. Authentication
-* @can_login@ @permission@ link going (email address → user uuid) which records @identity_url_prefix@ (??? wtf does this mean)
+After completing the authentication process, a callback is made from the SSO server to the API server, providing a user record and @identity_url@ (despite the name, this is actually an Arvados user uuid).
+
+The API server searches for a user record with the @identity_url@ supplied by the SSO. If found, that user account will be used, unless the account has @redirect_to_user_uuid@ set, in which case it will use the user in @redirect_to_user_uuid@ instead (this is used for the "link account":{{site.baseurl}}/user/topics/link-accounts.html feature).
+
+Next, it searches by email address for a "pre-activated account.":#pre-activated
+
+If no existing user record is found, a new user object will be created.
+
+A federated user follows a slightly different flow, whereby a special token is presented and the API server verifies user's identity with the home cluster, however it also results in a user object (representing the remote user) being created.
+
+h3. User setup
+
+If @auto_setup_new_users@ is true, as part of creating the new user object, the user is immediately set up with:
+
+* @can_login@ @permission@ link going (email address → user uuid) which records @identity_url_prefix@
* Membership in the "All users" group (can read all users, all users can see new user)
* A new git repo and @can_manage@ permission if @auto_setup_new_users_with_repository@ is true
* @can_login@ permission to a shell node if @auto_setup_new_users_with_vm_uuid@ is set to the uuid of a vm
-Otherwise, an admin must explicitly call "setup" on the user.
+Otherwise, an admin must explicitly invoke "setup" on the user via workbench or the API.
-h3. Activation
+h3. User activation
A newly created user is inactive (@is_active@ is false) by default unless @new_users_are_active at .
-An inactive user cannot create or update any object, but can read Arvados objects that the user account has permission to read. This implies that if @auto_setup_new_users@ is true, an "inactive" user who has been set up may still be able to do things, such as read things shared with "All users", clone and push to the git repository, or login to a vm. (unless these services check is_active)
+An inactive user cannot create or update any object, but can read Arvados objects that the user account has permission to read. This implies that if @auto_setup_new_users@ is true, an "inactive" user who has been set up may still be able to do things, such as read things shared with "All users", clone and push to the git repository, or login to a VM.
{% comment %}
-(I believe that when this was originally designed, being able to access git and VM required an ssh key, and an inactive user could not register an ssh key because that required creating a record. However, it is now possible to authenticate to shell VMs and http+git with just an API token).
+Maybe these services should check is_active.
+
+I believe that when this was originally designed, being able to access git and VM required an ssh key, and an inactive user could not register an ssh key because that required creating a record. However, it is now possible to authenticate to shell VMs and http+git with just an API token.
{% endcomment %}
-At this point, there are two ways a user can become active:
+At this point, there are two ways a user can be activated.
# An admin can set the @is_active@ field directly. This runs @setup_on_activate@ which sets up oid_login_perm and group membership, but does not set repo or vm (even if if @auto_setup_new_users_with_repository@ and/or @auto_setup_new_users_with_vm_uuid@ are set).
-# Calling to the @activate@ method of the users controller. (see below).
+# Self-activation using the @activate@ method of the users controller.
h3. User agreements
-The @activate@ method of the users controller. This checks if the user @is_invited@ and whether the user has signed all the clickthrough agreements.
+The @activate@ method of the users controller checks if the user @is_invited@ and whether the user has "signed" all the user agreements.
@is_invited@ is true if any of these are true:
* @is_active@ is true
* @new_users_are_active@ is true
* the user account has a permission link to read the system "all users" group.
-Clickthrough agreements are accessed by getting a listing on the @user_agreements@ endpoint. This returns a list of collection uuids. This is executed as a system user, so it bypasses normal read permission checks.
+User agreements are accessed by getting a listing on the @user_agreements@ endpoint. This returns a list of collection uuids. This is executed as a system user, so it bypasses normal read permission checks.
-The available user agreements are represented in the links table as @link_class: signature@ and @name: require@ and (system_user_uuid → uuid of collection containing user agreement text file)
+The available user agreements are represented in the Links table as @link_class: signature@ and @name: require@ and (system_user_uuid → uuid of collection containing user agreement text file)
On workbench, it checks @is_invited at . If true, it displays the clickthrough agreements which the user can "sign". If @is_invited@ is false, the user ends up at the "inactive user" page.
@@ -61,7 +77,7 @@ h3. User profile
The user profile is checked by workbench after checking if user agreements need to be signed. The requirement to fill out the user profile is not enforced by the API server.
-h3. Pre-activated user accounts
+h3(#pre-activated). Pre-activated user accounts
It is possible to create a user account for a user that has not yet logged in.
@@ -71,9 +87,9 @@ It is possible to create a user account for a user that has not yet logged in.
h3. Federated users
-Hmmm?
+In the API server config, set @auto_activate_users_from@ with a list of cluster ids. A federated users from one of the listed clusters which @is_active@ on the home cluster will be automatically set up and activated on this cluster.
-h3. Deactivating users
+h3(#deactivating_users). Deactivating users
Setting @is_active@ is not sufficient to lock out a user. The user can call @activate@ to become active again. Instead, use @unsetup@:
@@ -95,21 +111,6 @@ Does not revoke API tokens.
h3. Activation flows
-h4. Open instance
-
-Policy: anybody who shows up and signs the agreements is activated.
-
-<pre>
-auto_setup_new_users: true
-new_users_are_active: false
-</pre>
-
-# User is created and auto-setup. At this point, @is_active@ is false, but user has been added to "All users" group.
-# Workbench checks @is_invited@ and finds it is true, because the user is a member of "All users" group.
-# Workbench presents user with list of user agreements, user reads and clicks "sign" for each one.
-# Workbench tries to activate user.
-# User is activated.
-
h4. Private instance
Policy: users must be manually approved.
@@ -126,14 +127,44 @@ new_users_are_active: false
# On refreshing workbench, the user is still inactive, but is able to self-activate after signing clickthrough agreements (if any).
# Alternately, directly setting @is_active@ to true also sets up the user, but workbench won't display clickthrough agreements (because the user is already active).
+h4. Federated instance
+
+Policy: users from other clusters in the federation are activated, users from outside the federation must be manually approved
+
+<pre>
+auto_setup_new_users: false
+new_users_are_active: false
+auto_activate_users_from: [home1]
+</pre>
+
+# Federated user arrives claiming to be from cluster 'home1'
+# API server authenticates user as being from cluster 'home1'
+# Because 'home1' is in @auto_activate_users_from@ the user is set up and activated.
+# User can immediately start using workbench.
+
+h4. Open instance
+
+Policy: anybody who shows up and signs the agreements is activated.
+
+<pre>
+auto_setup_new_users: true
+new_users_are_active: false
+</pre>
+
+# User is created and auto-setup. At this point, @is_active@ is false, but user has been added to "All users" group.
+# Workbench checks @is_invited@ and finds it is true, because the user is a member of "All users" group.
+# Workbench presents user with list of user agreements, user reads and clicks "sign" for each one.
+# Workbench tries to activate user.
+# User is activated.
+
h4. Developer instance
-Policy: avoid wasting developer's time clicking through extra pages.
+Policy: avoid wasting developer's time during development/testing
<pre>
auto_setup_new_users: true
new_users_are_active: true
</pre>
-# User is created and auto-setup. Also sets @is_active@ to true.
+# User is created, immediately auto-setup, and auto-activated.
# User can immediately start using workbench.
diff --git a/doc/api/tokens.html.textile.liquid b/doc/api/tokens.html.textile.liquid
index 922df5ab9..3437003a1 100644
--- a/doc/api/tokens.html.textile.liquid
+++ b/doc/api/tokens.html.textile.liquid
@@ -25,6 +25,10 @@ Browser based applications can perform log in via the following highlevel flow:
The "browser authentication process is documented in detail on the Arvados wiki.":https://dev.arvados.org/projects/arvados/wiki/Workbench_authentication_process
+h2. User activation
+
+"Creation and activation of new users is described here.":{{site.baseurl}}/admin/activation.html
+
h2. Creating tokens via the API
The browser login method above issues a new token. Using that token, it is possible to make API calls to create additional tokens. To do so, use the @create@ method of the "API client authorizations":{{site.baseurl}}/api/methods/api_client_authorizations.html resource.
commit bd14cd71274109789ea076b1b4219bdf3beef657
Author: Peter Amstutz <pamstutz at veritasgenetics.com>
Date: Thu Jun 21 13:50:59 2018 -0400
13255: Edits
Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <pamstutz at veritasgenetics.com>
diff --git a/doc/admin/activation.html.textile.liquid b/doc/admin/activation.html.textile.liquid
index d29502d55..2d2d35151 100644
--- a/doc/admin/activation.html.textile.liquid
+++ b/doc/admin/activation.html.textile.liquid
@@ -12,7 +12,7 @@ SPDX-License-Identifier: CC-BY-SA-3.0
After completing the authentication process with the SSO server and receiving a new @identity_url@, a new user object is always created.
-h3. Auto setup
+h3. Setup
If @auto_setup_new_users@ is true, as part of creating the new user object, the user is immediately setup with:
@@ -21,13 +21,17 @@ If @auto_setup_new_users@ is true, as part of creating the new user object, the
* A new git repo and @can_manage@ permission if @auto_setup_new_users_with_repository@ is true
* @can_login@ permission to a shell node if @auto_setup_new_users_with_vm_uuid@ is set to the uuid of a vm
-h3. is_active
+Otherwise, an admin must explicitly call "setup" on the user.
+
+h3. Activation
A newly created user is inactive (@is_active@ is false) by default unless @new_users_are_active at .
An inactive user cannot create or update any object, but can read Arvados objects that the user account has permission to read. This implies that if @auto_setup_new_users@ is true, an "inactive" user who has been set up may still be able to do things, such as read things shared with "All users", clone and push to the git repository, or login to a vm. (unless these services check is_active)
+{% comment %}
(I believe that when this was originally designed, being able to access git and VM required an ssh key, and an inactive user could not register an ssh key because that required creating a record. However, it is now possible to authenticate to shell VMs and http+git with just an API token).
+{% endcomment %}
At this point, there are two ways a user can become active:
@@ -53,7 +57,43 @@ The @user_agreements/sign@ endpoint creates a Link with @link_class: signature@
The @user_agreements/signatures@ endpoint returns the list of Link objects that represent signatures by the current user (created by @sign@).
-h3. Typical flows
+h3. User profile
+
+The user profile is checked by workbench after checking if user agreements need to be signed. The requirement to fill out the user profile is not enforced by the API server.
+
+h3. Pre-activated user accounts
+
+It is possible to create a user account for a user that has not yet logged in.
+
+# As an admin, create a user object.
+# Create a link with @link_class: permission@ and @name: can_login@ and (email address → user_uuid) and @properties[identity_url_prefix] = 'xxxxx-tpzed-'@ where 'xxxxx' is the @uuid_prefix@ of the SSO server.
+# When the user logs in the first time, the email address will be recognized and the user will be associated with the existing user uuid.
+
+h3. Federated users
+
+Hmmm?
+
+h3. Deactivating users
+
+Setting @is_active@ is not sufficient to lock out a user. The user can call @activate@ to become active again. Instead, use @unsetup@:
+
+* Delete oid_login_perms
+* Delete git repository permission links
+* Delete VM login permission links
+* Remove from "All users" group
+* Delete any "signatures"
+* Clear preferences / profile
+* Mark as inactive
+
+{% comment %}
+Does not revoke @is_admin@ though! Maybe we need to fix that?
+
+Does not prevent user from reading things.
+
+Does not revoke API tokens.
+{% endcomment %}
+
+h3. Activation flows
h4. Open instance
@@ -97,23 +137,3 @@ new_users_are_active: true
# User is created and auto-setup. Also sets @is_active@ to true.
# User can immediately start using workbench.
-
-h3. User profile
-
-The user profile is checked by workbench after checking if user agreements need to be signed. The requirement to fill out the user profile is not enforced by the API server.
-
-h3. Deactivating users
-
-Setting @is_active@ is not sufficient to lock out a user. The user can call @activate@ to become active again. Instead, use @unsetup@:
-
-* Delete oid_login_perms
-* Delete git repository permission links
-* Delete VM login permission links
-* Remove from "All users" group
-* Delete any "signatures"
-* Clear preferences / profile
-* Mark as inactive
-
-Does not revoke @is_admin@ though! Maybe we need to fix that?
-
-Does not prevent user from reading things?
-----------------------------------------------------------------------
hooks/post-receive
--
More information about the arvados-commits
mailing list