[jira] [Commented] (KNOX-3303) Support configurable 'sub' claim reconciliation in Client Credentials flow

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KNOX-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18081604#comment-18081604 ] 

ASF subversion and git services commented on KNOX-3303:
-------------------------------------------------------

Commit 4988a16a022b5cc030864906ce1ade7e1c213620 in knox's branch refs/heads/dependabot/pip/dot-github/workflows/tests/requests-2.33.0 from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=4988a16a0 ]

KNOX-3303: Support configurable 'sub' claim reconciliation and client_id claim in Client Credentials flow (#1208)

Implement thirdPartyApp topology config to toggle 'sub' claim between client_id and userName.
Add client_id claim to access tokens issued during client credentials token exchange.

> 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
>
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> *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)