oscerd opened a new pull request, #27419:
URL: https://github.com/apache/camel/pull/27419
Follow-up to CAMEL-24735 (#27385), from @davsclaus's review there. The code
is correct; the documentation that shipped with it is not — worth fixing before
4.23.0 goes out, so no user meets it.
### The documented route denies every request
The policy example configured no client authentication:
```java
from("netty-http:https://0.0.0.0:8443?sslContextParameters=#spiffeSsl";)
.policy(spiffePolicy)
```
`SSLContextServerParameters.clientAuthentication` defaults to `null`, so the
JSSE default applies and the server never *requests* a client certificate.
`SSLSession.getPeerCertificates()` then throws `SSLPeerUnverifiedException`,
`SpiffePeerIdentity` returns null, and the policy denies — correctly, failing
closed. But that means the documented route rejects **every** request, and the
only signal is an authorization failure.
The example now builds the server `SpiffeSSLContextParameters` with
`clientAuthentication=REQUIRE`.
### Two caveats a reader could not have inferred
Both now in an `[IMPORTANT]` block:
- **The server must use `SpiffeSSLContextParameters`**, not a plain
truststore that happens to trust the SPIFFE CA. Such a truststore accepts any
SVID that CA issued, which is a weaker check than the allow-list this policy
appears to give you.
- **Only camel-netty and camel-netty-http put the `SSLSession` on the
message today**, as `CamelNettySSLSession`. Behind platform-http, jetty,
undertow or servlet there is no session on the exchange, so the policy has no
verified certificate to read and denies everything. A reader seeing a generic
`AuthorizationPolicy` would reasonably assume otherwise.
The catalog copy of the component doc is a verbatim mirror and is updated in
step — the two files are byte-identical after the change.
### Negative tests
Five, and I want to be clear that **the current code already passes all of
them** — they pin behaviour rather than fix it:
- a `String`-valued `CamelNettySSLSession` header — a sender cannot assert
an identity, because an `SSLSession` does not convert from a `String`;
- the two near-miss ids, `spiffe://example.org.evil/frontend` and
`spiffe://example.org/frontend/x`;
- a malformed `spiffe://` URI SAN;
- a leaf certificate that is not an `X509Certificate`.
**Mutation check**, since tests that pass on unchanged code prove nothing by
themselves: changing `isAuthorized` from the exact `Set.contains` to a prefix
match fails `deniesAnIdWhosePathOnlyStartsWithTheAllowedOne` and nothing else.
The trust-domain near-miss is *not* covered by that mutation — it rests on the
exact-match semantics of `Set.contains` over parsed `SpiffeId`s, and I'd rather
say so than imply all five are mutation-validated.
### The open question, answered rather than implemented
You asked whether `sslSessionHeader` should be required to start with
`Camel`. It should not, and the String-header test is the demonstration: an
`SSLSession` is a Java object, so it cannot arrive through an HTTP string
header at all — the conversion simply yields null and the policy denies. Adding
a name constraint would suggest a threat that does not exist here.
Module suite 46 tests green. Docs and tests only, no `@UriParam` change, so
nothing regenerates.
🤖 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]
