Before you start
In order to understand this guide correctly you must be familiar with some Auth0 FGA Concepts and know how to develop the things that we will list below.Step by step
For the current model, a user can be related as anadmin to an object of type repo. If we wanted to have Anne be related to two repos, repo:1 and repo:2, we would have to add two relationship tuples, like so:
In general, every time we wanted to add a new admin relationship to a repo we’d have to add a new tuple. This doesn’t scale as the list of repos and users grows.
01. Modify authorization model
Another way of modeling this is to have an authorization model as follows: In this model, we have:- added a new type
orgwith one relationrepo_admin. - added a new relation
ownerfor typerepo. - re-defined the relation
adminforrepo. A user can be defined as anadmindirectly, as we have seen above, or through therepo_admin from ownerclause. How this works, for example, is that ifuseris related asrepo_admintoorg:xyz, andorg:xyzis related asownertorepo:1, thenuseris anadminofrepo:1.
02. Adding relationship tuples where user is another object
With this model, we can add tuples representing that anorg is the owner of a repo. By adding following relationship tuples, we are indicating that the xyz organization is the owner of repositories with IDs 1 and 2:
03. Adding relationship tuples to the other object
Now, imagine we have a new user Becky. If we wanted to have Becky be theadmin of all repos without having to add one tuple per repo, all we need to do is add one tuple that says that Becky is related as repo_admin to org:xyz.
04. Validating user access
We can now verify that Becky anadmin of all the repos owned by org:xyz:
05. Revoking access
Suppose now that we want to prevent users from being anadmin of repo:1 via org:xyz. We can delete one tuple:
With this change, we may now verify that Becky is no longer an admin of repo:1.