[
https://issues.apache.org/jira/browse/CAMEL-24643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112697#comment-18112697
]
Andrea Cosentino commented on CAMEL-24643:
------------------------------------------
Merged via https://github.com/apache/camel/pull/26187
_Claude Code on behalf of oscerd_
> camel-opa - allow exchange properties in the OPA input document
> ---------------------------------------------------------------
>
> Key: CAMEL-24643
> URL: https://issues.apache.org/jira/browse/CAMEL-24643
> Project: Camel
> Issue Type: Improvement
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> h2. Problem
> {{camel-opa}} (CAMEL-24634) builds its OPA {{input}} document from message
> headers only:
> {code:java}
> for (Map.Entry<String, Object> entry :
> exchange.getMessage().getHeaders().entrySet()) {
> {code}
> (OpaPolicyEvaluator#buildInput)
> That leaves out the place where Camel's authentication components actually
> put verified identity. {{KeycloakSecurityProcessor}} reads and stores the
> authenticated principal in *exchange properties*:
> * {{KeycloakSecurityConstants.ACCESS_TOKEN_PROPERTY}}
> * {{KeycloakSecurityConstants.TOKEN_SUBJECT_PROPERTY}}
> * {{KeycloakSecurityConstants.TOKEN_THUMBPRINT_PROPERTY}}
> and it deliberately prefers properties over headers -
> {{preferPropertyOverHeader}} defaults to {{true}}, documented as preventing
> "header-based token override attacks", with {{allowTokenFromHeader}} offered
> as a way to switch the header channel off entirely.
> h2. Why this matters
> The premise of CAMEL-24634 was that {{camel-spiffe}} / {{camel-keycloak}}
> establish *who the caller is* and {{camel-opa}} decides *whether they are
> allowed*. Today those two halves cannot be composed directly: a route that
> authenticates with {{KeycloakSecurityPolicy}} and then authorizes with
> {{camel-opa}} has to copy the verified subject from an exchange property into
> a message header so the policy can see it.
> That is the wrong direction. It moves trusted identity into the exact channel
> {{camel-keycloak}} treats as untrusted, and it makes the safe composition the
> awkward one.
> h2. Proposal
> Add an {{includeProperties}} option, mirroring the existing
> {{includeHeaders}}: a comma-separated allow-list of exchange property names,
> contributing a {{properties}} object to the input document alongside
> {{headers}}.
> {code:java}
> {
> "headers": { ... },
> "properties": { "CamelKeycloakTokenSubject": "alice" },
> "body": ...,
> "exchangeId": "...",
> "routeId": "..."
> }
> {code}
> Notes:
> * Default to *empty* rather than {{*}}. Unlike headers, exchange properties
> are mostly Camel-internal bookkeeping, and dumping all of them would be noise
> at best. This also keeps the change fully backwards compatible.
> * Reuse the existing name-matching and JSON-safety conversion from
> {{buildInput}}, including the shallow-conversion contract.
> * The same rule as for headers applies: the component's own decision
> headers/properties must never be fed back in.
> * Document the {{keycloak -> opa}} and {{spiffe -> opa}} compositions in
> {{opa-component.adoc}}, since making that pairing natural is the point of the
> change.
> h2. Scope
> {{main}} only. Additive option, no behaviour change for existing routes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
