Andrea Cosentino created CAMEL-24735:
----------------------------------------
Summary: camel-spiffe - add a SpiffeSecurityPolicy to authorize on
the peer SPIFFE ID
Key: CAMEL-24735
URL: https://issues.apache.org/jira/browse/CAMEL-24735
Project: Camel
Issue Type: New Feature
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
h2. Background
{{camel-spiffe}} can obtain and verify workload identity, and {{camel-opa}} can
decide whether a caller is allowed - but there is no built-in way to make a
routing decision on a SPIFFE identity without writing it by hand.
{{camel-shiro}} ships {{ShiroSecurityPolicy}}, {{camel-keycloak}} ships
{{KeycloakSecurityPolicy}}, and {{camel-opa}} ships {{OpaSecurityPolicy}}.
{{camel-spiffe}} ships none, so the identity half of the pairing has no
{{AuthorizationPolicy}}.
h2. Proposal
A {{SpiffeSecurityPolicy implements AuthorizationPolicy}} that authorizes a
route segment on the caller's SPIFFE ID:
{code:java}
from("netty-http:https://0.0.0.0:8443?sslContextParameters=#spiffeSsl";)
.policy(spiffePolicy) //
acceptedSpiffeIds=spiffe://example.org/frontend
.to("direct:handleOrder");
{code}
Design notes:
* The peer SPIFFE ID must come from the *verified* TLS peer certificate, never
from a header - see CAMEL-24730 for why that distinction matters in this
component.
* A deny throws {{CamelAuthorizationException}}, matching the sibling policies.
* Follow the {{OpaSecurityProcessor}} shape rather than the shiro/keycloak one:
extend {{DelegateAsyncProcessor}}, not {{DelegateProcessor}}, since the
{{Policy}} SPI advises an async processor and the older two do not comply.
* It should compose with {{camel-opa}} rather than duplicate it: this policy
answers "is the peer who they claim", and the OPA policy answers "may they do
this". Storing the verified SPIFFE ID as an exchange property lets
{{includeProperties}} (CAMEL-24643) hand it to a Rego policy.
h2. Scope
{{main}} only. Additive.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
