Hierarchical Permissions

In this article, we will show you how to create a hierarchical permission tree for your application. The permission tree defines the resources and permissions of your multi-layered application.

For each step there is a section for a fictional application, which helps you to understand the steps better. The fictional application is a file management application. It is a multi-tenant application, which organizes files in folders. Folders are organized in spaces and can have sub-folders.

tip

It is very helpful to extend your notes with a drawing of the permission tree. This helps you to understand the permission tree better.

Define the resources

Think about the resource types of your application, that might have access rights on them. For example, if you have a blog application, you have the resources article and comment. If you have a file management application, you have the resources folder and file.

Only write down the resources, which are relevant for the permissions to which you want to enable permission management. For example, if you have a file management application, you don't need the resource user, because you don't need permissions to users, but rather from users.

In a fictional file management application, we might have these resources:

• tenant: The tenant is the biggest resource, which contains all other resources. The tenant is the root of the permission tree.
• space: A space is a sub resource of the tenant. A tenant can have multiple spaces.
• folder: A folder is a sub resource of a space or another folder. A space or folder can have multiple folders.
• file: A file is a sub resource of a folder. A folder can have multiple files.

Define the permissions

Think about the permissions, which a user can have for a resource. For example, if you have a blog application, you have the permissions create, update, delete, createComment, updateComment, deleteComment for the article resource. If you have a file management application, you have the permissions download, delete for the file resource.

tip

You can define as many permissions as you want. But you should only define the permissions, the granularity of which makes sense for your application. For example, if you have a file management application, and you know that you will always allow modification of all file properties, it makes no sense to define the permission updateName for the file resource.

In our fictional file management application, we have these permissions:

Tenant permissions

• inviteMember: The user can invite members to the tenant.
• manageRoles: The user can manage the roles of the tenant.
• rename: The user can rename the tenant.
• createSpace: The user can create a space in the tenant.

Space permissions

• inviteMember: The user can invite members to the space.
• rename: The user can rename the space.
• createFolder: The user can create a folder in the space.

Folder permissions

• inviteMember: The user can invite members to the folder.
• rename: The user can rename the folder.
• createFile: The user can create a file in the folder.

File permissions

• download: The user can download the file.
• rename: The user can rename the file.
• delete: The user can delete the file.

Access Inheritance

Hierarchical access trees are used to bequeath permissions on levels below the current. This means that when a member gets assigned a role on a resource, this role is passed on all resources below that level (where this resource is the parent).

For example: