oscerd opened a new pull request, #27385:
URL: https://github.com/apache/camel/pull/27385
# CAMEL-24735: camel-spiffe - SpiffeSecurityPolicy
`camel-spiffe` can obtain and verify workload identity, but until now it
shipped no `AuthorizationPolicy` — the
identity half of the pairing had no built-in way to make a routing decision
on a SPIFFE ID (unlike `camel-shiro`,
`camel-keycloak` and `camel-opa`, which ship `ShiroSecurityPolicy` /
`KeycloakSecurityPolicy` / `OpaSecurityPolicy`).
## What this adds
`SpiffeSecurityPolicy implements AuthorizationPolicy` authorizes a route
segment on the caller's **verified** SPIFFE ID:
```java
SpiffeSecurityPolicy spiffePolicy = new
SpiffeSecurityPolicy("spiffe://example.org/frontend");
from("netty-http:https://0.0.0.0:8443?sslContextParameters=#spiffeSsl";)
.policy(spiffePolicy)
.to("direct:handleOrder");
```
## Design
- **Identity comes from the certificate, not a header.** The peer SPIFFE ID
is read from the verified TLS peer
certificate the consumer puts on the exchange (the `CamelNettySSLSession`
header for camel-netty-http, via
`SSLSession.getPeerCertificates()`), never from a message header a sender
could set — the same principle as
CAMEL-24730. It fails closed when the peer presented no verified
certificate (mutual TLS is required).
- **Follows the `OpaSecurityProcessor` shape**, extending
`DelegateAsyncProcessor` (as the `Policy` SPI advises)
rather than the older `DelegateProcessor` used by shiro/keycloak, so the
guarded part of the route keeps running on
the asynchronous routing engine; only the in-memory authorization check
runs on the calling thread.
- **A deny throws `CamelAuthorizationException`**, matching the sibling
policies, so the route stops and the regular
`onException` machinery applies. The failing policy is also recorded in the
`Exchange.AUTHENTICATION_FAILURE_POLICY_ID` header.
- **Composes with camel-opa rather than duplicating it.** This policy
answers "is the peer who they claim to be"; on a
successful authorization it stores the verified SPIFFE ID as the
`CamelSpiffePeerId` exchange *property*, so an OPA
policy downstream can forward it to a Rego rule via `includeProperties`
(CAMEL-24643).
- Set exactly one of `acceptedSpiffeIds` (comma-separated allow-list) or
`acceptAnySpiffeId=true`; setting both is
rejected and setting neither fails closed, mirroring
`SpiffeSSLContextParameters`.
A certificate with no SPIFFE URI SAN, or with more than one, is treated as
not a valid SVID and denied — the policy
refuses to guess which identity to trust.
## Tests
- `SpiffeSecurityPolicyTest` — allow a listed peer (and expose its id as a
property); deny a peer not on the list; deny
when there is no TLS session at all; deny when the peer presented no
verified certificate; deny a certificate with no
SPIFFE id; deny a certificate carrying more than one SPIFFE id.
- `SpiffeSecurityPolicyAcceptAnyTest` — authorize any verified peer under
`acceptAnySpiffeId`; still fail closed when
no verified peer is present.
- `SpiffeSecurityPolicyConfigTest` — reject both options / neither / an
all-whitespace allow-list; allow-list
authorizes only the listed peers; `acceptAnySpiffeId` authorizes any.
Additive, `main` only. Component documentation updated (plus the catalog
mirror). No upgrade-guide entry — it is a new
feature, not a migration.
---
_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]
