oscerd opened a new pull request, #27185: URL: https://github.com/apache/camel/pull/27185
Fixes [CAMEL-25183](https://issues.apache.org/jira/browse/CAMEL-25183), the follow-up [CAMEL-25028](https://issues.apache.org/jira/browse/CAMEL-25028) deferred. Two endpoint-only options, each evaluated per exchange and applied to `check`, `batchCheck`, `listObjects`, `listRelations` and `listUsers`: | option | shape | |---|---| | `contextualTuples` | semicolon-separated `user,relation,object` triples, each part a Simple expression | | `conditionContext` | a `Map<String, Object>` resolved from the registry (`conditionContext=#myContext`) | ```java to("openfga:check?storeId={{fga.store}}&relation=reader" + "&user=user:${exchangeProperty.CamelKeycloakTokenSubject}" + "&object=document:${header.documentId}" + "&contextualTuples=user:${exchangeProperty.CamelKeycloakTokenSubject},member,team:${header.team}"); ``` ## Neither option can come from the message, and not behind a flag either A contextual tuple is read exactly like a stored one. `user:anne,owner,document:secret` makes `check(user:anne, owner, document:secret)` answer **true** whatever the store holds — it is an assertion that the relationship exists, not a hint. So a tuple the caller could choose would let it assert the very relationship being checked, which is the whole decision. CAMEL-25183 left open whether to offer message-supplied tuples behind an off-by-default option. This PR closes that shut instead: gating the primitive still ships it, and the useful cases are all facts the *route* knows. A condition context gets the same treatment, because a condition can decide a relation. The IT demonstrates the grant rather than asserting it — `dave` is denied, the identical check with `contextualTuples=user:dave,owner,document:budget` is allowed, and the plain check denies again afterwards, against a real OpenFGA. That also proves the tuple is not persisted. ## Three smaller decisions worth a look **`conditionContext` is a map, not an expression** — deliberately asymmetric with `contextualTuples`. OpenFGA types every condition parameter in the authorization model (`int`, `bool`, `timestamp`, `ipaddress`), so a map lets the route author supply the right Java type rather than a string the server would reject. A mistyped value comes back as an HTTP 400, which this component already treats as a denial rather than as an unavailable decision point, so the failure direction is safe either way. **An unresolved part denies rather than being dropped**, with `CamelOpenFgaDenyReason=invalid-contextual-tuple`. Dropping would be the safer direction arithmetically — losing a contextual tuple can only make a check stricter — but it silently answers a different question than the endpoint was configured to ask. Revert-checked: switching to drop-the-bad-tuple fails that test. **A malformed option fails when the endpoint starts**, not per message, so a typo does not surface as something that reads like a policy decision. **A typed wildcard is accepted here**, unlike on the check subject: `user:*` in a contextual tuple is how a route says "this one is public for this request", and the route author wrote it. ## Testing 106 unit tests and 13 ITs pass. The new unit tests cover the tuples reaching the request, per-exchange evaluation of each part, the absent-option case still sending `null`, the deny-on-unresolved path, the wildcard, the registry condition context, start-time rejection of a malformed option, and the list operations carrying both. Rebased on current `main`; a full reactor leaves `git status` clean. The generated diff adds exactly `contextualTuples` and `conditionContext` and removes no option — I compared the option-name sets rather than reading the re-indexing by eye. --- _Claude Code on behalf of @oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
