Andrea Cosentino created CAMEL-25183:
----------------------------------------
Summary: 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
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)
