I really respect OpenFGA & team behind it, I used it in multiple projects and it completely eliminate the AuthZ from our code.
But it always had this issue with Admin management, It is hard for Admins to understand and maintain.
That’s why I created an Admin UI for OpenFGA, The main goal is that the UI is Dynamic and it changes as per your OpenFGA Model, Then you can Easily Add users
I built this because my team was constantly struggling with managing permissions in our applications. we tried building admin UIs multiple times, but every time the OpenFGA model changed, we had to rework the UI layer to match it one way or another.
So mainly the UI understand your OpenFGA schema and automatically renders the management interface based on the entities and relationships defined in your model.
Fun to see a write up applying multi-armed bandits.
I had a bit of trouble following the article as I don't understand the problem space well enough. When framing this problem, the authors wrote:
Answering "Can user X access resource Y?" requires traversing relationship graphs. In this context, traversal performance isn't just a feature; it is the fundamental constraint of the system's architecture.
Concretely, in an OpenFGA / Auth0 FGA deployment where graph traversal becomes enough of a bottleneck that introducing a planner like this becomes compelling, how is the graph and the traversal manifested? What's actually going on?
Would the relationship graph be represented as a bunch of relations stored in a single SQL DB? Or does querying and traversing the graph require making a bunch of API calls to various downstream services over the customer's network?
In OpenFGA/Auth0 FGA, the “relationship graph” is not usually a separate graph database or a pile of downstream service calls. It’s an implicit graph whose edges are the relationship tuples you’ve stored, interpreted through the authorization model (the DSL that says how one relation implies another, how to follow parents, groups, etc.).
These are persisted in the OpenFGA datastore (commonly Postgres).
What “traversal” actually does at runtime
A Check(user=X, relation=R, object=Y) request is evaluated by resolving the model for (Y#R) and reading whatever tuples are needed to prove/disprove membership.
Traversal becomes painful when checks cause High fan-out (e.g., a document inherits viewers from a folder, that folder has 50 groups, each group contains groups…)
or like Deep nesting (group-of-group chains)
That’s exactly the niche where smarter planning/strategy selection helps.
Do checks require “a bunch of API calls to downstream services”?
Normally, no. OpenFGA/Auth0 FGA doesn’t need to call your microservices to traverse your domain graph. The check is decided from:
- the authorization model, and
- tuples in the OpenFGA store,
- plus any contextual tuples you included in the request (ephemeral edges that behave as-if written, but aren’t persisted).
I don’t understand why Thompson sampling would be used for an experiment that can be rapidly repeated. Isn’t reconfiguring the FPGA orders of magnitude slower than measuring latency? It seems like you could produce a high confidence posterior by resampling so fast that there is no point in prioritizing what needs to be revisited (especially with good priors).
I really respect OpenFGA & team behind it, I used it in multiple projects and it completely eliminate the AuthZ from our code.
But it always had this issue with Admin management, It is hard for Admins to understand and maintain.
That’s why I created an Admin UI for OpenFGA, The main goal is that the UI is Dynamic and it changes as per your OpenFGA Model, Then you can Easily Add users
I built this because my team was constantly struggling with managing permissions in our applications. we tried building admin UIs multiple times, but every time the OpenFGA model changed, we had to rework the UI layer to match it one way or another.
So mainly the UI understand your OpenFGA schema and automatically renders the management interface based on the entities and relationships defined in your model.
https://github.com/yehia2amer/OpenFGA-Admin-UI
Thanks for that Yehia, looks pretty good and useful!
Fun to see a write up applying multi-armed bandits.
I had a bit of trouble following the article as I don't understand the problem space well enough. When framing this problem, the authors wrote:
Concretely, in an OpenFGA / Auth0 FGA deployment where graph traversal becomes enough of a bottleneck that introducing a planner like this becomes compelling, how is the graph and the traversal manifested? What's actually going on?Would the relationship graph be represented as a bunch of relations stored in a single SQL DB? Or does querying and traversing the graph require making a bunch of API calls to various downstream services over the customer's network?
In OpenFGA/Auth0 FGA, the “relationship graph” is not usually a separate graph database or a pile of downstream service calls. It’s an implicit graph whose edges are the relationship tuples you’ve stored, interpreted through the authorization model (the DSL that says how one relation implies another, how to follow parents, groups, etc.).
What the graph “is” in a typical deployment
Edges = tuples like: document:1#viewer@user:anne document:1#viewer@group:eng#member document:1#parent@folder:A
These are persisted in the OpenFGA datastore (commonly Postgres).
What “traversal” actually does at runtime
A Check(user=X, relation=R, object=Y) request is evaluated by resolving the model for (Y#R) and reading whatever tuples are needed to prove/disprove membership.
Traversal becomes painful when checks cause High fan-out (e.g., a document inherits viewers from a folder, that folder has 50 groups, each group contains groups…) or like Deep nesting (group-of-group chains)
That’s exactly the niche where smarter planning/strategy selection helps.
Do checks require “a bunch of API calls to downstream services”?
Normally, no. OpenFGA/Auth0 FGA doesn’t need to call your microservices to traverse your domain graph. The check is decided from: - the authorization model, and - tuples in the OpenFGA store, - plus any contextual tuples you included in the request (ephemeral edges that behave as-if written, but aren’t persisted).
I don’t understand why Thompson sampling would be used for an experiment that can be rapidly repeated. Isn’t reconfiguring the FPGA orders of magnitude slower than measuring latency? It seems like you could produce a high confidence posterior by resampling so fast that there is no point in prioritizing what needs to be revisited (especially with good priors).
Edit: FGA != FPGA. This is purely software.