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