[ARVADOS] updated: 2.1.0-753-g39d5dd451

[Git user]

Summary of changes:
 doc/admin/token-expiration-policy.html.textile.liquid | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

       via  39d5dd4511a1c2be101469dfbbecc4f1138b2e4d (commit)
      from  5d41e6222aed0bfd2a6005f423c3f46be803a33a (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 39d5dd4511a1c2be101469dfbbecc4f1138b2e4d
Author: Peter Amstutz <peter.amstutz at curii.com>
Date:   Mon May 10 13:21:51 2021 -0400

    17449: Clarifications and edits.
    
    Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <peter.amstutz at curii.com>

diff --git a/doc/admin/token-expiration-policy.html.textile.liquid b/doc/admin/token-expiration-policy.html.textile.liquid
index f9409e59a..9d84bf666 100644
--- a/doc/admin/token-expiration-policy.html.textile.liquid
+++ b/doc/admin/token-expiration-policy.html.textile.liquid
@@ -10,11 +10,11 @@ Copyright (C) The Arvados Authors. All rights reserved.
 SPDX-License-Identifier: CC-BY-SA-3.0
 {% endcomment %}
 
-When a user logs in to Workbench, they receive a newly created access token that grants access to the Arvados API on behalf of that user.  In the default configuration, this token does not expire until the user explicitly logs off.
+When a user logs in to Workbench, they receive a newly created token (a long string of random characters) which grants access to the Arvados API on behalf of that user.  In the default configuration, this token does not expire until the user explicitly logs out.
 
-Security policies, such as those required to comply with regulations such as HIPAA and GxP, may require "automatic logoff".  Arvados offers both several options for automatic logout, and to configure access tokens to expire by default in order to limit the window of risk associated with a token being leaked.
+Security policies, such as those required to comply with regulations such as HIPAA and GxP, may include policies for "automatic logoff".  In order to limit the window of risk associated with unauthorized access of the desktop of an Arvados user, or a token being leaked, Arvados offers options for automatic logout from the web app, and to configure access tokens to expire by default.
 
-The @Workbench.IdleTimeout@, @Login.TokenLifetime@, @API.MaxTokenLifetime@ options give configuration enables the administrator to set a expiration lifetime for tokens granted through the login flow.
+The @Workbench.IdleTimeout@, @Login.TokenLifetime@, and @API.MaxTokenLifetime@ options give the administrator ways to control automatic expiration of tokens granted through the login flow.
 
 If you are looking for information on how to expire a token manually, see how to "delete a single token":user-management-cli.html#delete-token and "delete all tokens belonging to a user":user-management-cli.html#delete-all-tokens .
 
@@ -37,13 +37,13 @@ When idle timeout is set, several behaviors and considerations apply:
 * Users should use the "open in new tab" functionality of Workbench 2.  This will share the same token between tabs without requiring the user to log in again.  Logging out will apply to all browser tabs that use the same token.
 * If the user closes a Workbench tab without first logging out, the browser will forget the token, but not expire the token (this is desirable if the user has several tabs open).
 * If the user closes all Workbench tabs, they will be required to log in again.
-* This only affects browser behavior.  Automatic logout should be used together with limiting token lifetime
+* This only affects browser behavior.  Automatic logout should be used together automatic token expiration described below.
 
 The default value for @Workbench.IdleTimeout@ is zero, which disables auto-logout.
 
 h2. Automatic expiration of login tokens
 
-Use @Login.TokenLifetime@ sets the lifetime for tokens issued through the login process.  This is the maximum amount of time a user can maintain a session before having to log in again.  This setting applies to both regular and admin user logins.  Here is an example configuration that would require the user to log in again after 12 hours:
+Use @Login.TokenLifetime@ to set the lifetime for tokens issued through the login process.  This is the maximum amount of time a user can maintain a session before having to log in again.  This setting applies to both regular and admin user logins.  Here is an example configuration that would require the user to log in again after 12 hours:
 
 <pre>
 Clusters:
@@ -62,7 +62,7 @@ The default value @Login.TokenLifetime@ is zero, meaning login tokens do not exp
 
 h2. Automatic expiration of all tokens
 
-Use @API.MaxTokenLifetime@ sets the maximum lifetime for any access token created by regular (non-admin) users.  For example, this configuration would require that all tokens expire after 24 hours:
+Use @API.MaxTokenLifetime@ to set the maximum lifetime for any access token created by regular (non-admin) users.  For example, this configuration would require that all tokens expire after 24 hours:
 
 <pre>
 Clusters:
@@ -89,10 +89,12 @@ h2. Choosing a policy
 
 @Login.TokenLifetime@ is more restrictive.  A token obtained by logging into Workbench cannot be "refreshed" to gain access for an indefinite period.  However, it interferes with some Workbench features, as well as ease of use in other contexts, such as the Arvados command line.  This option is recommended only if most users will only ever interact with the system through Workbench or WebShell.  For users or service accounts that need to tokens with fewer restrictions, the admin can "create a token at the command line":user-management-cli.html#create-token .
 
- at API.MaxTokenLifetime@ is less restrictive.  Be aware that an unrestricted token can be "refreshed" to gain access for an indefinite period.  This means, during the window that the token is valid, the user is permitted to create a new token, which will have a new expiration further in the future.  Obviously, once the token has expired, this is no longer possible.  Unrestricted tokens are required for some Workbench features, as well as ease of use in other contexts, such as the Arvados command line.  This option is recommended if many users will interact with the system through the command line.
+ at API.MaxTokenLifetime@ is less restrictive.  Be aware that an unrestricted token can be "refreshed" to gain access for an indefinite period.  This means, during the window that the token is valid, the user is permitted to create a new token, which will have a new expiration further in the future (of course, once the token has expired, this is no longer possible).  Unrestricted tokens are required for some Workbench features, as well as ease of use in other contexts, such as the Arvados command line.  This option is recommended if many users will interact with the system through the command line.
 
 In every case, admin users may always create tokens with no expiration date.
 
+These policies do not apply to tokens created by the API server for the purposes of authorizing a container to run, as those tokens are automatically expired when the container is finished.
+
 h2. Applying policy to existing tokens
 
 If you have an existing Arvados installation and want to set a token lifetime policy, there may be long-lived user tokens already granted.  The administrator can use the following @rake@ tasks to enforce the new policy.

-----------------------------------------------------------------------


hooks/post-receive
--