[
https://issues.apache.org/jira/browse/KNOX-3303?focusedWorklogId=1016983&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1016983
]
ASF GitHub Bot logged work on KNOX-3303:
----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Apr/26 07:51
Start Date: 23/Apr/26 07:51
Worklog Time Spent: 10m
Work Description: hanicz commented on code in PR #1208:
URL: https://github.com/apache/knox/pull/1208#discussion_r3129132574
##########
gateway-provider-security-jwt/src/main/java/org/apache/knox/gateway/provider/federation/jwt/filter/AbstractJWTFilter.java:
##########
@@ -405,22 +406,34 @@ public Subject createSubjectFromTokenIdentifier(final
String tokenId) throws Unk
// token id until it is created, the username is always the same
// in the record. Using the token id makes it a unique username for
// audit and the like.
- final String username = metadata.isClientId() ? tokenId :
metadata.getUserName();
-
- return createSubjectFromTokenData(username, null);
+ // However, in case of service-to-service communications, it might
+ // be useful to return the actual userName during the token exchange
+ // step in the client credentials flow (this is controlled by the
thirdPartyApp)
+ // flag that was (or wasn't) submitted while the client credentials were
created
+ final String userName = (metadata.isClientId() &&
metadata.isThirdPartyApp()) ? tokenId : metadata.getUserName();
+ final String clientId = (metadata.isClientId() &&
!metadata.isThirdPartyApp()) ? tokenId : null;
+ return createSubjectFromTokenData(userName, null, clientId);
}
return null;
}
@SuppressWarnings("rawtypes")
protected Subject createSubjectFromTokenData(final String principal, final
String expectedPrincipalClaimValue) {
+ return createSubjectFromTokenData(principal, expectedPrincipalClaimValue,
null);
+ }
+
+ @SuppressWarnings("rawtypes")
+ protected Subject createSubjectFromTokenData(final String principal, final
String expectedPrincipalClaimValue, final String tokenId) {
Review Comment:
nit: I think the last param should be called clientId as per the updated
logic
##########
gateway-service-knoxtoken/src/test/java/org/apache/knox/gateway/service/knoxtoken/TokenServiceResourceTest.java:
##########
@@ -1487,6 +1487,37 @@ public void
passcodeShouldNotBeInResponseIfTokenStateServiceIsDisabled() throws
testPasscodeToken(false, false, false);
}
+ @Test
+ public void testClientCredentialsThirdPartyAppConfig() throws Exception {
+ tryClientCredentialsThirdPartyAppConfig(null, true);
+ tryClientCredentialsThirdPartyAppConfig("true", true);
+ tryClientCredentialsThirdPartyAppConfig("false", false);
+ }
+
+ private void tryClientCredentialsThirdPartyAppConfig(String configValue,
boolean expectedValue) throws Exception {
+ try {
+ tss = new PersistentTestTokenStateService();
+ final Map<String, String> contextExpectations = new HashMap<>();
+ if (configValue != null) {
+ contextExpectations.put("clientid.thirdPartyApp", configValue);
Review Comment:
Is this test correct? You don't use the `clientid.` prefix in
`ClientCredentialsResource`
Issue Time Tracking
-------------------
Worklog Id: (was: 1016983)
Time Spent: 0.5h (was: 20m)
> 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: 0.5h
> 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)
