feat: introduce hierarchy for can_relations #419
Conversation
@nsklikas it should suffice to just apply the new authorization model. It should not cause conflicts (OpenFGA handles multiple authorization model weird for what I remember). |
afaik the upgrade of the model brings the tuples with it, we would have to trigger the right relationship refresh to communicate the app(s) that the model id has changed in our specific case, this would trigger a clash as we do the model validation at runtime, so it's not something that can be orchestrated without scheduled downtime question is: do we validate the model consistency or we rely on openfga blindly? |
it goes `can_delete` >> `can_edit` >> `can_view` can create is not touched by this since it gets special treatment
BarcoMasile
force-pushed
the
feat/ofga-authmodel-hierarchy
branch
from
e8d2add
to
596b448
Compare
|
side note, when we create a resource what tuples do we assign ?is it can view and can edit?if yes we can drop the first |
@shipperizer for groups and roles we only add |
was more concerned about the other non OpenFGA backed resources, but, for roles and groups are we ok with can view only? |
Description
This PR introduces a hierarchy for all
can_*relations in the OpenFGA authorization model.The hierarchy is as follows
So:
can_delete>>can_edit>>can_viewCan create is not touched by this since it gets special treatment in the implementation.
Why
This is done with the intention of simplifying both user experience and developer life when it comes to reasoning about user authorization based on entitlements.
This way we can rely on some simple implications to treat entitlements. Also, this allows us to not crowd the OpenFGA store with "same user" tuples.