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]