oscerd opened a new pull request, #26435: URL: https://github.com/apache/camel/pull/26435
## What `validateJwtSvid` now accepts a JWT-SVID that matches **any** configured audience, instead of silently enforcing only the first. ## Why ```java JwtSvid svid = client.validateJwtSvid(token, audiences[0]); ``` An endpoint configured `audience=spiffe://example.org/a,spiffe://example.org/b` validated only against `a`. Nothing warned; `b` was silently ignored. Two things make that worse than a cosmetic bug: - **The same option meant two different things.** `fetchJwtSvid`, on the line directly above, already passed every audience to the Workload API. So `audience` was a list for minting and a single value for validating. - **Validation is the security check.** Silently enforcing a narrower rule than the operator configured is the wrong failure mode for the step that decides whether a caller is authenticated — and it matters more since #26420, which removes `CamelSpiffeAudience` from that path and leaves the configuration as the only input. ## What changed The Workload API validates one audience at a time (`validateJwtSvid(String token, String audience)` — there is no multi-audience overload), so a configured list has to be tried in turn. The token is accepted on the first audience that matches; the last failure is rethrown only once every audience has failed. A single configured audience behaves exactly as before — one call, same exception on failure. The loop deliberately keeps the last `JwtSvidException` rather than mapping failures to a generic error: a failure can be the audience *or* the token itself (expired, bad signature), and only after every audience has been tried is it knowable which. `resolveAudiences` already guarantees a non-empty array, so the loop always runs — I made that invariant explicit rather than leaving a reader or a static analyser to prove it. ## Testing Three new cases in `SpiffeMultiAudienceTest`: - a token matching the **second** configured audience is accepted - validation **stops at the first** audience that matches (no pointless second call) - when **no** audience matches, the failure propagates The first and third were confirmed to **fail with the fix reverted**. The 7 pre-existing `SpiffeProducerTest` cases are unchanged and green. Full reactor build green. ## Note for the reviewer This touches the same method as **#26420** (CAMEL-24730, audience/operation header pinning). I based this on `main` so it can merge independently rather than stacking; whichever lands second needs a trivial rebase of `validateJwtSvid`. `main` only. `camel-spiffe` is new in the unreleased 4.23.0, so no released behaviour changes. _Claude Code on behalf of @oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
