[jira] [Commented] (CAMEL-24643) camel-opa - allow exchange properties in the OPA input document

["Andrea Cosentino (Jira)" <ji...@apache.org>]

    [ 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)