Duplicate Store and Authz Model creation using OpenFGA APIs

[chahat-agarwal]

Hi Team,

Noticed something unusual.

When I was creating "Test" store from Playground it says "already exist"(Assume validation is applicable only on Playground). But, when I consume OpenFGA create store API to create "Test" (same Store name) - I was able to do "n" number of times.

Attaching Screenshot for your reference with the timestamp present in the response to track.

The same is also applicable for Authorization Model creation using OpenFGA APIs.

[ewanharris]

👋🏻 Hey @chahat-agarwal,

the API itself does support creating stores with the same name, this is because the id field is the identifier for a store and the name is intended for a readable value for display.

However, for usability purposes, the playground does force uniqueness on a name because it only shows the name in the dropdown so it's difficult to tell stores apart if multiple are created (as you can see by creating multiple stores with the same name via the API 😄 ).

[chahat-agarwal]

Ideally, it should replicate the same flow from API is what I feel :) The same case is with Authz model creation within a given store, it does create multiple times.

Suggestion: In Production setup, when we disable the Playground and consume OpenFGA APIs for store and authz model creation/update. Then, CI CD process in Production would go for a toss. There are alternate ways to overcome the creation of store but not with Authz model if NO changes.

From Playground:
When we try to hover on "Test" store created, it allows to select ONE randomly among all the duplicate stores. It would ideally create confusion as everytime a different store and auth model id may get picked.

Apart from the above, If API also has limitation with conversion of .fga model to JSON which inturn is required by API, then we may have to plan for FGA CLI/ SDKs for CI CD process. (Open for suggestions)

[ewanharris]

For deploying an authorization model, one approach is to only deploy from within CI/CD if there are changes to the model, for example in GitHub actions using a paths filter so that the step to deploy the model is ran only when the relevant files are changes. That said, I do think a command the CLI to compare a model against a previous model would be good to help visualize changes.

As for limitations in the conversion, the OpenFGA API itself only deals with the JSON representation of a model (CLI, playground, and dashboard convert from DSL to JSON prior to writing the model to OpenFGA), so there is no limitation in terms of what the API accepts. Could you maybe expand on what your concerns here are?

[chahatagarwal]

Yes, I am aware of paths Filter in Github actions, but even if there is an additional space added by mistake still the Authz model remains unchanged and the workflow starts it's execution (Just an example, there could be many scenarios).

The challenge is JSON remains as it is and when the API trigger happens, it creates a new Authz MODEL ID. But, eventually it should return error stating no changes to Authz model. This is my understanding.

[ewanharris]

The API itself does not perform any comparison of the model to previous models on a write so it would not return an error related to no changes. Theoretically, a store could be used for authorization models used for different purposes so it's not necessarily correct to simply compare against the previously written model.

This type of functionality would fall within the scope of consumers of the API (the CLI, frontends etc.) that would be able to improve the experience and build interfaces to allow developers to understand the changes better.