17722: Adjust token expiry behavior

* Admins tokens have API.MaxTokenLifetime by default, but admins can create
  token which are not restricted by API.MaxTokenLifetime.

* Login.TokenLifetime does no longer implies untrusted tokens

* Added Login.TrustLoginToken to determine whether tokens issued by login are
  considered "trusted"

* Updated documentation page

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <peter.amstutz@curii.com>

diff --git a/doc/admin/token-expiration-policy.html.textile.liquid b/doc/admin/token-expiration-policy.html.textile.liquid
index 9d84bf6660236964f45aa637496d0b9fbe12aecf..c71d86c47f234b6cd3db8b2580faabcc46eb6a0c 100644 (file)
--- a/doc/admin/token-expiration-policy.html.textile.liquid
+++ b/doc/admin/token-expiration-policy.html.textile.liquid
@@ -56,7 +56,18 @@ Clusters:
 
 This is independent of @Workbench.IdleTimeout@.  Even if Workbench auto-logout is disabled, this option will ensure that the user is always required to log in again after the configured amount of time.
 
-When this configuration is active (has a nonzero value), the Workbench client will also be "untrusted" by default.  This means tokens issued to Workbench cannot be used to list other tokens issued to the user, and cannot be used to grant new tokens.  This stops an attacker from leveraging a leaked token to aquire other tokens, but also interferes with some Workbench features that create new tokens on behalf of the user.
+h2. Untrusted login tokens
+
+<pre>
+Clusters:
+  zzzzz:
+    ...
+    Login:
+      TrustLoginTokens: false
+    ...
+</pre>
+
+When `TrustLoginTokens` is `false`, tokens issued through login will be "untrusted" by default.  Untrusted tokens cannot be used to list other tokens issued to the user, and cannot be used to grant new tokens.  This stops an attacker from leveraging a leaked token to aquire other tokens, but also interferes with some Workbench features that create new tokens on behalf of the user.
 
 The default value @Login.TokenLifetime@ is zero, meaning login tokens do not expire (unless @API.MaxTokenLifetime@ is set).
 
@@ -73,25 +84,25 @@ Clusters:
     ...
 </pre>
 
-Tokens created without an explicit expiration time, or that exceed maximum lifetime, will be clamped to @API.MaxTokenLifetime@.
+Tokens created without an explicit expiration time, or that exceed maximum lifetime, will be set to @API.MaxTokenLifetime@.
 
 Similar to @Login.TokenLifetime@, this option ensures that the user is always required to log in again after the configured amount of time.
 
-Unlike @Login.TokenLifetime@, this applies to all API operations that manipulate tokens, regardless of whether the token was created by logging in, or by using the API.  Also unlike @Login.TokenLifetime@, this setting does not imply any additional restrictions on token capabilities (it does not interfere with Workbench features that create new tokens on behalf of the user).  If @Login.TokenLifetime@ is greater than @API.MaxTokenLifetime@, MaxTokenLifetime takes precedence.
+Unlike @Login.TokenLifetime@, this applies to all API operations that manipulate tokens, regardless of whether the token was created by logging in, or by using the API.  If @Login.TokenLifetime@ is greater than @API.MaxTokenLifetime@, MaxTokenLifetime takes precedence.
 
-Admin users are permitted to create tokens with expiration times further in the future than MaxTokenLifetime, or with no expiration time at all.
+Admin users are permitted to create tokens with expiration times further in the future than @MaxTokenLifetime@.
 
 The default value @MaxTokenLifetime@ is zero, which means there is no maximum token lifetime.
 
 h2. Choosing a policy
 
-@Workbench.IdleTimeout@ only affects browser behavior.  It is strongly recommended that automatic browser logout be used together with one or both token lifetime options, which are enforced on API side.
+@Workbench.IdleTimeout@ only affects browser behavior.  It is strongly recommended that automatic browser logout be used together with @Login.TokenLifetime@, which is enforced on API side.
 
-@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 .
+@TrustLoginTokens: true@ (default value) 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.
 
-@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.
+@TrustLoginTokens: false@ 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 using the @SystemRootToken@.
 
-In every case, admin users may always create tokens with no expiration date.
+In every case, admin users may always create tokens with expiration dates far in the future.
 
 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.
 

diff --git a/lib/config/config.default.yml b/lib/config/config.default.yml
index 8ad2cb53fca8d20fce9a091f5a6b781e7e8c9835..69fd11768ac643398b8f86fcee34aa8639acab46 100644 (file)
--- a/lib/config/config.default.yml
+++ b/lib/config/config.default.yml
@@ -771,8 +771,15 @@ Clusters:
       # Default value zero means tokens don't have expiration.
       TokenLifetime: 0s
 
+      # If true (default) tokens issued through login are allowed to create
+      # new tokens.
+      # If false, tokens issued through login are not allowed to
+      # viewing/creating other tokens.  New tokens can only be created
+      # by going through login again.
+      TrustLoginTokens: true
+
       # When the token is returned to a client, the token itself may
-      # be restricted from manipulating other tokens based on whether
+      # be restricted from viewing/creating other tokens based on whether
       # the client is "trusted" or not.  The local Workbench1 and
       # Workbench2 are trusted by default, but if this is a
       # LoginCluster, you probably want to include the other Workbench

diff --git a/lib/config/export.go b/lib/config/export.go
index 890d4ce4711eb4f06a00ada8e9e5adc63b2d7999..8f98258bf2549b6d04b2011d96522d94c1e16a3c 100644 (file)
--- a/lib/config/export.go
+++ b/lib/config/export.go
@@ -180,6 +180,7 @@ var whitelist = map[string]bool{
        "Login.Test.Enable":                                   true,
        "Login.Test.Users":                                    false,
        "Login.TokenLifetime":                                 false,
+       "Login.TrustLoginTokens":                              false,
        "Login.TrustedClients":                                false,
        "Mail":                                                true,
        "Mail.EmailFrom":                                      false,

diff --git a/lib/config/generated_config.go b/lib/config/generated_config.go
index 9e59f8c9238606ed8b0926ad2841ce66d20e3565..d9c9af027cd56099af78635ebe3966621f6936af 100644 (file)
--- a/lib/config/generated_config.go
+++ b/lib/config/generated_config.go
@@ -777,6 +777,12 @@ Clusters:
       # Default value zero means tokens don't have expiration.
       TokenLifetime: 0s
 
+      # If true (default) tokens issued through login are allowed to create
+      # new tokens.
+      # If false, tokens issued through login are not allowed to create new tokens,
+      # new tokens can only be created by going through login again.
+      TrustLoginTokens: true
+
       # When the token is returned to a client, the token itself may
       # be restricted from manipulating other tokens based on whether
       # the client is "trusted" or not.  The local Workbench1 and

diff --git a/services/api/app/models/api_client.rb b/services/api/app/models/api_client.rb
index 015b61dc494c1c7b3cff629407cb0ebdc0ff656c..6ff29c83e43771bf0d96145505c4efcb246b3382 100644 (file)
--- a/services/api/app/models/api_client.rb
+++ b/services/api/app/models/api_client.rb
@@ -15,7 +15,7 @@ class ApiClient < ArvadosModel
   end
 
   def is_trusted
-    (from_trusted_url && Rails.configuration.Login.TokenLifetime == 0) || super
+    (from_trusted_url && Rails.configuration.Login.TrustLoginTokens) || super
   end
 
   protected

diff --git a/services/api/app/models/api_client_authorization.rb b/services/api/app/models/api_client_authorization.rb
index 7e7140369171a56dc3ba2a2ad4b9eb531f798cb4..52f2cee064905fd6a81e4e9e60a774dfc80bab55 100644 (file)
--- a/services/api/app/models/api_client_authorization.rb
+++ b/services/api/app/models/api_client_authorization.rb
@@ -406,9 +406,9 @@ class ApiClientAuthorization < ArvadosModel
   protected
 
   def clamp_token_expiration
-    if !current_user.andand.is_admin && Rails.configuration.API.MaxTokenLifetime > 0
+    if Rails.configuration.API.MaxTokenLifetime > 0
       max_token_expiration = db_current_time + Rails.configuration.API.MaxTokenLifetime
-      if (self.new_record? || self.expires_at_changed?) && (self.expires_at.nil? || self.expires_at > max_token_expiration)
+      if (self.new_record? || self.expires_at_changed?) && (self.expires_at.nil? || (self.expires_at > max_token_expiration && !current_user.andand.is_admin))
         self.expires_at = max_token_expiration
       end
     end