[
https://issues.apache.org/jira/browse/CAMEL-25184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121519#comment-18121519
]
Andrea Cosentino commented on CAMEL-25184:
------------------------------------------
PR opened: https://github.com/apache/camel/pull/27195
Adds the readTuples, readChanges and expand operations, with
pageSize/continuationToken/startTime for paging and the
CamelOpenFgaContinuationToken header. readTuples emits the same key shape
writeTuples/deleteTuples accept, so a read-then-revoke route needs no
transformation. The Read API filter rule was established against a live OpenFGA
1.21.0 (user-only, relation-only and type-only-object filters are rejected
server-side) and is now validated up front instead of surfacing as an opaque
HTTP 400.
_Claude Code on behalf of oscerd_
> camel-openfga: add the expand, readTuples and readChanges operations
> --------------------------------------------------------------------
>
> Key: CAMEL-25184
> URL: https://issues.apache.org/jira/browse/CAMEL-25184
> 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. {{camel-openfga}} shipped with seven operations -
> {{check}}, {{batchCheck}},
> {{listObjects}}, {{listRelations}}, {{listUsers}}, {{writeTuples}} and
> {{deleteTuples}} - chosen to cover the
> authorization decision, the two filtering queries and grant/revoke. Several
> useful parts of the OpenFGA API are not
> exposed yet.
> h2. Operations to add
> * *{{expand}}* - expands a relation into its userset tree. This is the
> operation you reach for when a check answered
> something surprising and you need to see why, so it is mostly an
> introspection and debugging aid.
> * *{{readTuples}}* - queries the stored relationship tuples, optionally
> filtered by a partial tuple key. Useful for
> a route that has to report or reconcile what access exists, as opposed to
> asking whether one subject has it.
> * *{{readChanges}}* - reads the store's change log from a continuation token.
> This is the natural building block for
> keeping an external cache or projection in step with the graph, and it is
> the one operation here that a consumer
> could eventually be built on.
> h2. Store and authorization-model management
> {{createStore}}, {{getStore}}, {{deleteStore}}, {{listStores}},
> {{writeAuthorizationModel}},
> {{readAuthorizationModel(s)}}, {{readLatestAuthorizationModel}}.
> These deserve their own discussion rather than being added by reflex. They
> are administrative rather than
> integration operations, and a component that can delete the store it
> authorizes against is a different security
> proposition from one that can only ask it questions. If they are added, they
> should probably be off unless
> explicitly configured, and the documentation should say what a route holding
> those credentials can do.
> h2. Notes
> All of these already exist on {{OpenFgaClient}}, so the work is the
> Camel-side mapping: the body shape each
> operation returns, pagination for {{readTuples}} and {{readChanges}} (both
> are page-based with a continuation
> token), and the endpoint options each needs.
> The existing operations set a couple of conventions worth keeping. A query
> replaces the body with a
> {{List<String>}} of identifiers rather than SDK objects, and {{listUsers}}
> flattens OpenFGA's three subject shapes
> ({{object}}, {{userset}}, {{wildcard}}) into {{type:id}},
> {{type:id#relation}} and {{type:*}}. {{expand}} returns a
> tree, so it is the first operation that will not fit that convention and
> needs a deliberate decision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
