[
https://issues.apache.org/jira/browse/KNOX-3303?focusedWorklogId=1016772&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1016772
]
ASF GitHub Bot logged work on KNOX-3303:
----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Apr/26 19:28
Start Date: 21/Apr/26 19:28
Worklog Time Spent: 10m
Work Description: smolnar82 opened a new pull request, #1208:
URL: https://github.com/apache/knox/pull/1208
[KNOX-3303](https://issues.apache.org/jira/browse/KNOX-3303) - Support
configurable 'sub' claim reconciliation in Client Credentials flow
## What changes were proposed in this pull request?
This PR enhances the OAuth2-style Client Credentials flow in Apache Knox by
introducing a configurable way to reconcile the sub (subject) claim in issued
access tokens.
Key features:
1. Topology Configuration: Added a new `thirdPartyApp` parameter
(defaults to `true`) to the `CLIENTID` service.
2. Metadata Persistence: The `thirdPartyApp` flag is now stored in the
Token State Service metadata when client credentials are generated.
3. Subject Reconciliation:
* If `thirdPartyApp=true` (default): The `sub` claim remains the
technical `client_id`.
* If `thirdPartyApp=false`: The `sub` claim is set to the `userName`
of the credentials owner.
4. Client ID Claim: When `thirdPartyApp=false`, a new claim named
client_id is added to the JWT payload, referring to the original technical
identity (the token ID). This is in line with the claims listed in [RFC
9068](https://datatracker.ietf.org/doc/html/rfc9068#section-2.2).
## How was this patch tested?
Extended the automated test suite to verify the new logic:
1. TokenMetadataTest: Verified that thirdPartyApp metadata defaults to
true and correctly parses explicit boolean values.
2. TokenServiceResourceTest: Confirmed that ClientCredentialsResource
correctly reads the topology configuration and persists it into the database.
3. JWTFederationFilterTest: Validated that AbstractJWTFilter correctly
reconciles the Subject principal based on the metadata flag and adds the
TokenIdPrincipal when required.
4. JWTTokenTest: Verified that the client_id claim is correctly included
in the issued JWT when a technical identity is present.
Commands run:
```
mvn test -Dtest=TokenMetadataTest -pl gateway-spi
mvn test -Dtest=TokenServiceResourceTest -pl gateway-service-knoxtoken
mvn test -Dtest=JWTFederationFilterTest -pl gateway-provider-security-jwt
mvn test -Dtest=JWTTokenTest -pl gateway-spi
```
**TODO**: E2E testing using a local Knox instance
## Integration Tests
N/A - Sufficient unit and mock-based integration tests were added to cover
the logic within the affected services and filters.
## UI changes
N/A
Issue Time Tracking
-------------------
Worklog Id: (was: 1016772)
Remaining Estimate: 0h
Time Spent: 10m
> 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: 10m
> 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)
