We're optimizing Permify's DSL, Permify Schema constantly to ease the modeling of any kind of authorization structure.
With the latest improvements now you can,
📌 Define multiple relation types to a when defining entity relations.
📌 Lock a relation type to validate your entity relations.
In Permify, defining relations is such a core part that affects stored authorization data, access control checks and of course the model of the authorization. The goal of these improvements are related with empowering two concepts; validation and reasoning.
Let’s take a look at the schema below to show how defining multiple relation with lock feature can effect validation and reasoning of the authorization model.
Since its a simple demonstration, I didn't complete the schema (adding actions etc.) In this kind of organizational wide models, we often came across with a situation that some relations can have more than one entity type. For example organization admin is user but it can be also a member of any department right ? Even that user who is admin can also be a department manager too.
Above relation definition types is not wrong, they’re incomplete. We improved our DSL and give it a capability of adding multiple relation types and locking them exactly for this case. So, now the organization entity can be updated as;
Lets deconstruct the line relation admin @user @department#member @department#manager, basically we extend our admin relation in more definitive way. So admin is user (obviously) but also this user can be department member or department manager too. And now you can specify additional relation types with just adding them one after another.
The # represents the user subset for the entity, which we're familiar with from the relational tuple form. We called that locking the relation type, simply you can lock the entity just with its one relation inside it as we seen in department#manager or department#member.
Furthermore de admin relation types now differentiates from member, which indicates that member of the organization theoretically cannot be a department member or department manager. I said theoretically because if you try to create a these relational tuples
organization:1#member@user:1
department:1#member@user:1
System will successfully create these two, because defining multiple relation types are optional. The main purpose is locking relational tuple creation according to the types to validating and reasoning the schema not for the deny the wrong creation.
As a conclusion; even both of these organization entity definitions are correct, second one is definitely tells more about the authorization logic and the relation types of the organization entity. And it’s important for the validation and reasoning the relational tuples that created according to that model.
