entity
keyword. Let’s create some entities according to our example GitHub authorization logic.”
admin
, we advise defining it at the entity with the most global hierarchy, such as an organization. Then, spread it to the rest of the entities to include it within permissions.
For the sake of simplicity, let’s define only 2 user types in an organization, these are administrators and direct members of the organization.
user
as well as this user can be a team member
.
@team#member
it specifies that if the user has a relation with the team, this relation can only be the member
. We called that feature locking, because it basically locks the relation type according to the prefixed entity.Actual purpose of feature locking is to giving ability to specify the sets of users that can be assigned.For example:organization:1#viewer@organization:O1#member
all members of the organization O1 will have the right to perform the relevant action.In other words, all members in O1 now end up having the relevant viewer
relation.You can think of these definitions as a precaution taken against creating undesired user set relationships.and
, or
and not
operators to achieve permission intersection and exclusion. The keywords action or permission can be used with those operators to form rules for your authorization logic.
and
&, or
operators,
read
action rules; user that is organization admin
and following users can read the repository: owner
of the repository, or maintainer
, or member
of the organization which repository belongs to.
read
can also be defined using the permission keyword, as follows:action
and permission
will yield the same result for defining permissions in your authorization logic. See why we have 2 keywords for defining an permission from the Nested Hierarchies section.and
operation: it creates an intersection between relations but is not necessarily tied to specific entities.
For example, in the following model, users can see a repository if they are a member or admin of any organization.
Let’s say user:1
is a member of organization:1
and an admin of organization:2
. If repository:1
belongs to organization:1
(via the parent relationship), then user:1
is granted access to edit repository:1
.
not
operator and conclude Intersection and Exclusion section.
Here is the post entity from our sample Instagram Authorization Structure example,
restricted
attribute — details of defining attributes can be found in the Attribute Based Permissions (ABAC) section — won’t be able to like or comment on the specific post.
This is a simple example to demonstrate how you can exclude users, resources, or any subject from permissions using the not
operator.
delete
action inherits the rules from the edit
action. By doing that, we’ll be able to state that only organization administrators and any relation capable of performing the edit action (member or manager) can also perform the delete action.
Permission union is super beneficial in scenarios where a user needs to have varied access across different departments or roles.
Let’s examine our modeling guides for common permission use cases.
attribute
and rule
.
attribute
.
edit
permission of the repository to check whether the organization:X has edit access or not, depending on the authority level it possess.