[jira] [Work started] (CAMEL-25183) camel-openfga: support contextual tuples and condition context on the check operation

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

     [ https://issues.apache.org/jira/browse/CAMEL-25183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-25183 started by Andrea Cosentino.
------------------------------------------------
> camel-openfga: support contextual tuples and condition context on the check operation
> -------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25183
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25183
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Minor
>              Labels: openfga
>             Fix For: 4.23.0
>
>
> Follow-up to CAMEL-25028, which deliberately shipped {{camel-openfga}} without contextual tuples or condition
> context on the {{check}} operation.
> h2. Why it was left out
> A contextual tuple is a relationship supplied for the duration of one Check and not persisted. It is the mechanism
> OpenFGA offers for decisions that depend on facts the graph does not hold - "is the caller on the same network
> segment", "is this within business hours".
> It is also a self-authorization primitive. A contextual tuple derived from a message lets whoever controls that
> message assert the very relationship being checked:
> {code:json}
> {"user": "user:attacker", "relation": "owner", "object": "document:secret"}
> {code}
> Supplied as a contextual tuple, that makes {{check(user:attacker, owner, document:secret)}} answer true. The same
> applies to a condition {{context}} object, which feeds the CEL expressions a conditioned relation evaluates.
> The first release therefore omitted both rather than shipping a gate that had not been reviewed. Everything else in
> the component follows the same rule: the store, the authorization model, the relation and the operation come from the
> endpoint, and only the object may come from the message.
> h2. What is needed
> Support for both, with a trust model that is explicit rather than implied:
> * Contextual tuples and condition {{context}} configured on the endpoint, evaluated per exchange like
>   {{user}}/{{object}}/{{relation}} already are - route-author-controlled, which is the trusted side of the boundary.
> * If message-supplied contextual tuples are offered at all, they must be behind an option that is off by default,
>   documented as trusting whoever can write the body, and most likely annotated
>   {{security = "insecure:dev"}} in the same way {{failOpen}} is.
> * Contextual tuples on {{batchCheck}} too, or an explicit statement that they are not supported there.
> * Documentation stating plainly what a contextual tuple can do, because the danger is not obvious from OpenFGA's own
>   docs, which present them purely as a feature.
> h2. Notes
> {{ClientCheckRequest}} already accepts {{contextualTuples(List<ClientTupleKey>)}} and {{context(Object)}}, and
> {{ClientTupleKey}} carries a {{ClientRelationshipCondition}}, so the SDK side needs nothing new.
> Worth reviewing alongside the {{writeTuples}} decision taken in CAMEL-25028: there the endpoint's configured
> {{user}}/{{relation}}/{{object}} win over the message body precisely so that a route unmarshalling an untrusted
> payload cannot choose which relationship is written. Contextual tuples on a check are the same question in a
> different place.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)