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

Sandor Molnar updated KNOX-3303:
--------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

> 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: 1h 50m
>  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)

Reply via email to