oscerd commented on PR #25259:
URL: https://github.com/apache/camel/pull/25259#issuecomment-5140753562

   Thanks @gnodet — all three addressed in 67c2962:
   
   **🔴 HIGH — validatePermissions() bypass:** Confirmed and fixed. Added 
`validateTokenTypeFromIntrospection` and 
`validateAuthorizedPartyFromIntrospection` to the `validatePermissions()` 
introspection branch (after the audience check), with the same gating 
(`!getExpectedTokenTypesAsList().isEmpty()` / 
`!ObjectHelper.isEmpty(getExpectedAuthorizedParty())`), matching the 
CAMEL-23875 audience pattern. Good catch — with a permissions-only + 
introspection config the flow does skip authenticateToken/validateRoles, so 
both checks were bypassable.
   
   **🟡 LOW — tests:** Added two introspection tests mirroring 
`testTokenMissingExpectedAudienceRejectedWithRequiredPermissionsIntrospection`: 
`testTokenWrongTokenTypeRejectedWithRequiredPermissionsIntrospection` (token 
has the permission but `typ=Refresh` while `Bearer` is expected) and 
`testTokenWrongAuthorizedPartyRejectedWithRequiredPermissionsIntrospection` 
(permission ok but `azp=attacker-client`). Both assert the route is not 
reached. 11 tests pass.
   
   **🟡 MEDIUM — typ vs token_type:** I kept `getClaim("typ")` deliberately and 
added a code comment explaining why. This feature validates the JWT **`typ`** 
claim — the token *category* (Keycloak emits `Bearer`/`Refresh`/`ID`) — which 
Keycloak forwards on its introspection response. RFC 7662 `token_type` is the 
OAuth token type (`Bearer`) and can't distinguish an access token from a 
refresh/ID token, so it can't express what this check is for. Since this is 
`camel-keycloak`, relying on Keycloak's introspection contract is reasonable; 
using `getTokenType()` would validate the wrong field. Happy to reconsider if 
you'd prefer an explicit `token_type` fallback, but it would change the 
semantics.
   
   Re-requesting review.
   
   _Claude Code on behalf of Andrea Cosentino (@oscerd)._


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to