Croway opened a new pull request, #1955:
URL: https://github.com/apache/camel-spring-boot/pull/1955

   Cherry-pick of #1910 onto `camel-spring-boot-4.22.x`.
   
   **Original PR:** #1910 — camel-undertow-spring-security-starter - validate 
the JWT issuer and audience
   **JIRA:** [CAMEL-24497](https://issues.apache.org/jira/browse/CAMEL-24497)
   
   ### What it fixes
   
   `jwtDecoderByIssuerUri` built the JWT decoder with 
`NimbusJwtDecoder.withJwkSetUri` and only attached a claim-set converter, so 
Spring Security's default validator ran: signatures and timestamps were 
checked, but the `iss` claim was not, and the configured `clientId` was used 
solely to build the `ClientRegistration` — it was never bound to the incoming 
token.
   
   Because every client of a Keycloak realm shares the same signing key, a 
token minted for any other client of that realm passed the signature check and 
was accepted by this starter. That's an auth-bypass: a low-trust client's token 
could be replayed against an endpoint intended for a different, more privileged 
client of the same realm.
   
   The decoder now installs `JwtValidators.createDefaultWithIssuer` for the 
realm the client registration already points at, plus a new 
`JwtAudienceValidator` that binds the token to the configured `clientId` via 
its `aud` or `azp` claim.
   
   ### Behavior change
   
   This changes acceptance behavior for tokens that were previously accepted 
despite having the wrong issuer or audience — that is the intended effect of 
the fix. For deployments that rely on tokens minted for a different client of 
the same realm, the audience check can be disabled with 
`camel.security.undertow.keycloak.validate-audience=false` to restore the old 
tolerance.
   
   ### Verification on this branch
   
   - Cherry-pick of the original commit applied cleanly with no conflicts — 
this branch already carries the same generated doc files (`intro.adoc`, 
`undertow-spring-security.adoc`) as `main`, so all 10 changed files from the 
original commit (code, tests, docs, generated JSON) applied as-is.
   - Built `camel-undertow-spring-security-starter` and its dependencies: 
`./mvnw -DskipTests -Dfastinstall install -pl 
components-starter/camel-undertow-spring-security-starter -am` — BUILD SUCCESS.
   - Ran the module's tests: `cd 
components-starter/camel-undertow-spring-security-starter && ../../mvnw verify` 
— `Tests run: 9, Failures: 0, Errors: 0, Skipped: 0` 
(`JwtAudienceValidatorTest`: 5 tests, `KeycloakIssuerUriTest`: 4 tests), BUILD 
SUCCESS.
   - The SNAPSHOT parent/`camel-version` were temporarily repointed to the last 
released `4.22.0` to make the build resolvable locally. 
`tooling/camel-spring-boot-dependencies/pom.xml` still had `org.apache.camel` 
core entries pinned to `4.22.1-SNAPSHOT` on this branch (532 entries), so those 
were also temporarily repointed to `4.22.0`; the `org.apache.camel.maven` 
plugin entries and the `org.apache.camel.springboot` reactor-module entries 
were left untouched. All of these temporary edits were reverted (`git checkout 
-- pom.xml tooling/camel-spring-boot-dependencies/pom.xml`) before pushing; the 
build did not dirty any files under `catalog/` this time. Final diff against 
`origin/camel-spring-boot-4.22.x` contains only the 10 files from the 
cherry-picked commit.
   
   _Claude Code on behalf of Federico Mariani_


-- 
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