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

["Sandor Molnar (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KNOX-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on KNOX-3303 started by Sandor Molnar.
-------------------------------------------
> 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)