[
https://issues.apache.org/jira/browse/CAMEL-24754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-24754 started by Andrea Cosentino.
------------------------------------------------
> camel-opa - a verdict claimed by an inbound message survives a failed
> evaluation
> --------------------------------------------------------------------------------
>
> Key: CAMEL-24754
> URL: https://issues.apache.org/jira/browse/CAMEL-24754
> Project: Camel
> Issue Type: Bug
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
>
> h2. Problem
> {{camel-opa}} writes its verdict to {{CamelOpaDecisionAllow}} (plus
> {{CamelOpaDecision}} and {{CamelOpaPolicyPath}}) at the *end* of an
> evaluation:
> {code:java}
> boolean allowed = isAllowed(decision);
> setDecisionHeaders(exchange, decision, allowed);
> {code}
> That overwrites anything the message arrived with, so on the allow and deny
> paths a verdict claimed by an inbound message is correctly replaced.
> {{buildInput}} likewise excludes the three decision headers
> case-insensitively, so a claimed verdict never reaches OPA or its decision
> log.
> The failure paths never get there. When the policy cannot be evaluated at all
> - the OPA server is unreachable, the decision is undefined, the input cannot
> be serialized - {{evaluate}} throws {{OpaPolicyEvaluationException}} without
> touching the headers, and whatever the message carried survives:
> {code:java}
> throw new OpaPolicyEvaluationException("Failed to evaluate policy " +
> policyPath, exchange, e);
> {code}
> The same applies to {{OpaSecurityPolicy}}, which throws
> {{CamelAuthorizationException}} through the same shared {{evaluate}}.
> h2. Why it matters
> The exchange carries the exception, so a route that lets it propagate is
> unaffected. A route that *handles* it is not: {{doTry/doCatch}}, or
> {{onException(...).handled(true)}} / {{.continued(true)}}, resumes routing
> with the message still carrying the sender's own
> {{CamelOpaDecisionAllow=true}}. A downstream step reading that header sees
> "allowed" attributed to a policy that never produced it - and the component's
> own documentation presents the header as the way a route acts on the verdict,
> with a filter or a choice.
> A route author setting the header is trusted and out of scope. The reachable
> case is a consumer in front of the route that maps untrusted input into the
> header map without a strict, case-insensitive {{Camel*}}
> {{HeaderFilterStrategy}} - the header-injection class the security model puts
> explicitly in scope, and the reason a security component should not depend on
> the consumer having got it right.
> h2. Fix
> Clear the three decision headers on entry to {{evaluate}} rather than relying
> on overwriting them at the end, so every exit - allowed, denied, or a failure
> the route goes on to handle - leaves only what this component decided.
> h2. Scope
> {{main}} only. {{camel-opa}} is new and unreleased in 4.23.0, so no released
> behaviour changes and no advisory is warranted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
