We are super excited to announce that we launched Permify Playground to create and test your authorization in a browser. Our playground consists 4 sections; Authorization Model, Visualizer, Authorization Data and Enforcement. Let's examine these sections by following a simple example.
Authorization Model
You can create your authorization model in this section with using Permify authorization language, Permify Schema. You can define your entities, relations between them and access control decisions with using Permify Schema. We already have a couple of use cases and example that you can choose to see how authorization can be structured with Permify Schema. Also, you can check our docs to learn more about how to model authorization in Permify.
To demonstrate how playground works, let's choose the "empty" option from our dropdown to create a simple authorization model as follows:
We have 2 permissions these are editing repository and deleting repository. Repository has parent child relation with organizations. Lastly organizations can have organizational wide roles such as admin and member. After completing your authorization model you can just save it with hitting the save button and start testing it.
Visualizer
We get loads of feedback about the observability and reasonability of the authorization model across teams and colleagues. So we put a simple visualizer that shows how your authorization structure looks at a high level. In particular, you can examine relations between entities and their permissions. Here is a visualization for example model that we created above.
Authorization Data
You can create sample authorization data to test your authorization logic. In Permify, authorization data stored as relation tuples and these tuples stored in a database that you preferred. The basic relation tuple takes the form of:
entity # relation @ user
So the entity can be any entity that you defined in your model. If we look up our example it can be an organization or repository (since the user is empty). The relation can be one of the defined relations in the selected entity. Lastly, the user is basically the user or user set in our system. Let's say we want make user 1 admin in organization 1 then we need to create an example relational tuple according to our model as follows:
organization:1#admin@user:1
To create a relation tuple in playground just hit the "new" button and a pop up will open.
You can choose entity, relation and the subject (user or user set) with entering identifier to create sample data. Let's create the relation tuple organization:1#admin@user:1 as follows.
And this created tuple shown in the Authorization Data section as follows.
Let's add one more relation tuple to perform a sample access check. I want to add repository:1 into organization:1 as follows:
Created relational tuple after this will be: "repository:1#parent@organization:1#..." We used “...” when subject type is different from user entity. #… represents a relation that does not affect the semantics of the tuple.
Enforcement ( Access Checks)
Finally as we have a sample data lets perform an access check from the right below. Let's check whether user:1 can edit the repository:1. Since organization:1 is parent of repository:1 ( repository:1#parent@organization:1#... ) and user:1 has an admin role in organization:1 ( organization:1#admin@user:1 ) user:1 should allow to edit the repository:1 because the we define rule of the edit permission action as:
action edit = owner or parent.admin
which parent.admin indicates admin in the organization that repository belongs to. So let's type "can user:1 edit repository:1" and hit the check button to get result.
Let's try to get unauthorized result. Type "can user:1 delete repository:1" on the question input. Since only owners can delete the repository this access check will result as unauthorized.
As we seen above this is how you can model your authorization and test it with sample data in Permify Playground. Check out our docs for different modeling use cases, creating and storing relational tuples and more. As you planning to build or refactor and authorization mechanism we would love to help and hear from you. Check out our open source for how we're handling authorization based on Google Zanzibar.
If you have an idea or any kind of suggestions? Join the community in Discord to discuss.
