[
https://issues.apache.org/jira/browse/KNOX-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130568#comment-18130568
]
ASF subversion and git services commented on KNOX-3529:
-------------------------------------------------------
Commit 15eb586f0816e4d169fd3057b86039668c142f79 in knox's branch
refs/heads/master from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=15eb586f0 ]
KNOX-3529: Count the per-user token limit per token type (#1467)
Client credentials and API keys no longer count towards the per-user limit
of JWTs (and vice versa): KNOXTOKEN counts JWTs, authorization codes and
refresh tokens, CLIENTID counts client credentials and APIKEY counts API keys.
The previous behavior (all token types counted together) can be restored by
setting knox.token.limit.per.user.by.type.enabled to false.
Co-authored-by: Claude <[email protected]>
> Count the per-user token limit separately for each token type
> -------------------------------------------------------------
>
> Key: KNOX-3529
> URL: https://issues.apache.org/jira/browse/KNOX-3529
> Project: Apache Knox
> Issue Type: Improvement
> Components: JWT, Server
> Affects Versions: 2.0.0, 2.1.0, 3.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 3.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Problem
> The per-user token limit ({{knox.token.limit.per.user}}) currently counts
> every token stored for a user, regardless of type, except KnoxSSO cookies
> ({{TokenResource#enforceTokenLimitsAsRequired}}). The token state service is
> shared across the whole gateway, so tokens issued by one service (or
> topology) count against the limits of all the others.
> This causes trouble when a client uses one token type to get another. Example:
> - Topology A runs the {{CLIENTID}} service with
> {{clientid.knox.token.limit.per.user=100}}. A user creates 10 client
> credentials there.
> - Topology B runs the {{KNOXTOKEN}} service with
> {{knox.token.limit.per.user=150}}. A client exchanges those credentials for
> access tokens via {{/oauth/v1/token}}.
> - Topology B can mint only 140 access tokens, because the 10 client
> credentials count against its limit too. API keys owned by the same user
> reduce it further.
> - With {{knox.token.user.limit.exceeded.action=REMOVE_OLDEST}} it's worse:
> the oldest tokens are usually the long-lived client credentials or API keys,
> so minting an access token revokes the credential that was used to get it.
> Client credentials and API keys are long-lived credentials. Access tokens
> issued by {{KNOXTOKEN}} are usually short-lived. Counting them together means
> neither limit means what an admin expects.
> h3. Proposal
> Count tokens only against the limit for their own type. Every stored token
> already records its type ({{TokenMetadata.TYPE}}: {{JWT}}, {{CLIENT_ID}},
> {{API_KEY}}, {{KNOXSSO_COOKIE}}, ...), and
> {{TokenStateService#getTokens(userName)}} already returns that metadata, so
> no storage change is needed.
> * {{TokenResource}} gets a hook that returns the token types its limit
> counts. The default is everything except {{KNOXSSO_COOKIE}}, {{CLIENT_ID}}
> and {{API_KEY}} (so {{JWT}}, {{AUTH_CODE}} and {{REFRESH_TOKEN}}).
> - {{ClientCredentialsResource}} counts only {{CLIENT_ID}} tokens, and
> {{APIKeyResource}} counts only {{API_KEY}} tokens.
> - {{enforceTokenLimitsAsRequired}} filters the user's tokens by that hook
> before comparing against the limit. {{REMOVE_OLDEST}} then revokes the oldest
> token of the same type only.
> - Tokens with no {{TYPE}} metadata (stored by older versions) are treated as
> {{JWT}}.
> This changes what the limit means. Counting each token type separately
> becomes the default, controlled by a new service parameter that defaults to
> {{true}}. Deployments that want to keep today's behavior, where all of a
> user's tokens count together, can set it to {{false}}:
> {code:xml}
> <param>
> <name>knox.token.limit.per.user.by.type.enabled</name>
> <value>false</value>
> </param>
> {code}
> For {{CLIENTID}} and {{APIKEY}}, the parameter takes the usual prefix
> ({{clientid.}} / {{apikey.}}).
> Note: existing deployments will allow more tokens per user after upgrading,
> because each API now has its own budget instead of sharing one combined cap.
> For example, a user could have up to {{knox.token.limit.per.user}} JWTs plus
> that many client credentials, where before the two together were capped at
> that number. This is documented as an upgrade note.
> h3. KnoxIDF tokens
> KnoxIDF auth codes ({{AUTH_CODE}}) and refresh tokens ({{REFRESH_TOKEN}})
> stay in the default count, together with {{JWT}}. They are short-lived and
> deleted on use (auth codes are consumed on redemption, refresh tokens on
> rotation), so they don't build up the way long-lived client credentials and
> API keys do. Excluding them would also leave them with no per-user limit at
> all.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
