[
https://issues.apache.org/jira/browse/KNOX-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3303:
--------------------------------
Description:
*Description*
Apache Knox currently supports an OAuth2-style Client Credentials flow where:
1. Users can generate a long-lived client_id and client_secret (via the
CLIENTID service).
2. These credentials can be exchanged for short-lived access tokens.
3. The issued access tokens contain a sub (subject) claim in the JWT
payload, which is currently always set to the client_id.
While this behavior is standard for third-party applications where the
client_id represents the application identity, certain internal
service-to-service use cases require the sub claim to reflect the *actual
username* of the person who created the credentials, rather than the technical
client_id.
This JIRA proposes adding a topology-level configuration to allow
administrators to choose between these two behaviors.
*Proposed Changes*
*_1. Topology Configuration_*
Add a new configuration parameter called thirdPartyApp to the CLIENTID service
definition in the topology.
* *Name:* thirdPartyApp
* *Default Value:* true
*_2. Metadata Persistence_*
When the client_id and client_secret pair is generated via
ClientCredentialsResource, Knox should:
* Read the thirdPartyApp value from the service configuration.
* Store this value as a new metadata field (e.g., thirdPartyApp) in the
Token State Service (database) associated with that client_id.
*_3. Token Exchange Reconciliation_*
During the exchange of client credentials for an access token:
* Knox should retrieve the metadata for the provided client_id.
* The sub claim of the newly issued JWT should be reconciled as follows:
* If thirdPartyApp is *true* (default): The sub claim remains the
{*}client_id{*}.
* If thirdPartyApp is {*}false{*}: The sub claim should be set to the
*userName* associated with the credentials metadata.
{*}Backward Compatibility{*}{*}{*}
For existing tokens in the database that do not have the thirdPartyApp metadata
field, the logic should default to true to maintain the current behavior (using
client_id as the sub).
was:
{*}Description{*}{*}{*}
Apache Knox currently supports an OAuth2-style Client Credentials flow where:
1. Users can generate a long-lived client_id and client_secret (via the
CLIENTID service).
2. These credentials can be exchanged for short-lived access tokens.
3. The issued access tokens contain a sub (subject) claim in the JWT
payload, which is currently always set to the client_id.
While this behavior is standard for third-party applications where the
client_id represents the application identity, certain internal
service-to-service use cases require the sub claim to reflect the *actual
username* of the person who created the credentials, rather than the technical
client_id.
This JIRA proposes adding a topology-level configuration to allow
administrators to choose between these two behaviors.
{*}Proposed Changes{*}{*}{*}
{*}_1. Topology Configuration_{*}{*}{*}
Add a new configuration parameter called thirdPartyApp to the CLIENTID service
definition in the topology.
* *Name:* thirdPartyApp
* *Default Value:* true
{*}_2. Metadata Persistence_{*}{*}{*}
When the client_id and client_secret pair is generated via
ClientCredentialsResource, Knox should:
* Read the thirdPartyApp value from the service configuration.
* Store this value as a new metadata field (e.g., thirdPartyApp) in the
Token State Service (database) associated with that client_id.
{*}_3. Token Exchange Reconciliation_{*}{*}{*}
During the exchange of client credentials for an access token:
* Knox should retrieve the metadata for the provided client_id.
* The sub claim of the newly issued JWT should be reconciled as follows:
* If thirdPartyApp is *true* (default): The sub claim remains the
*client_id*.
* If thirdPartyApp is *false*: The sub claim should be set to the
*userName* associated with the credentials metadata.
{*}Backward Compatibility{*}{*}{*}
For existing tokens in the database that do not have the thirdPartyApp metadata
field, the logic should default to true to maintain the current behavior (using
client_id as the sub).
> Support configurable 'sub' claim reconciliation in Client Credentials flow
> --------------------------------------------------------------------------
>
> Key: KNOX-3303
> URL: https://issues.apache.org/jira/browse/KNOX-3303
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 3.0.0
>
>
> *Description*
> Apache Knox currently supports an OAuth2-style Client Credentials flow
> where:
> 1. Users can generate a long-lived client_id and client_secret (via the
> CLIENTID service).
> 2. These credentials can be exchanged for short-lived access tokens.
> 3. The issued access tokens contain a sub (subject) claim in the JWT
> payload, which is currently always set to the client_id.
>
> While this behavior is standard for third-party applications where the
> client_id represents the application identity, certain internal
> service-to-service use cases require the sub claim to reflect the *actual
> username* of the person who created the credentials, rather than the
> technical client_id.
> This JIRA proposes adding a topology-level configuration to allow
> administrators to choose between these two behaviors.
> *Proposed Changes*
> *_1. Topology Configuration_*
> Add a new configuration parameter called thirdPartyApp to the CLIENTID
> service definition in the topology.
> * *Name:* thirdPartyApp
> * *Default Value:* true
>
> *_2. Metadata Persistence_*
> When the client_id and client_secret pair is generated via
> ClientCredentialsResource, Knox should:
> * Read the thirdPartyApp value from the service configuration.
> * Store this value as a new metadata field (e.g., thirdPartyApp) in the
> Token State Service (database) associated with that client_id.
>
> *_3. Token Exchange Reconciliation_*
> During the exchange of client credentials for an access token:
> * Knox should retrieve the metadata for the provided client_id.
> * The sub claim of the newly issued JWT should be reconciled as follows:
> * If thirdPartyApp is *true* (default): The sub claim remains the
> {*}client_id{*}.
> * If thirdPartyApp is {*}false{*}: The sub claim should be set to the
> *userName* associated with the credentials metadata.
>
> {*}Backward Compatibility{*}{*}{*}
> For existing tokens in the database that do not have the thirdPartyApp
> metadata field, the logic should default to true to maintain the current
> behavior (using client_id as the sub).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
