[
https://issues.apache.org/jira/browse/CAMEL-25183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino reassigned CAMEL-25183:
----------------------------------------
Assignee: 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
>
> 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)
