Organizing your Permissions

Permissions are a crucial part in any collaborative application. A set of rules who is allowed and able to perform certain actions. Of course permissions apply every where, where people work together, not just in computer and web applications. Even dough I want to discuss only permissions in online web or distributed applications.

You can build any kind of web applications, at some point it will be necessary to introduce the concept of permissions. In many discussions I had, the subject can even become quite emotional. Designing a permission system, is a bit like playing god. You can make the rules within the world of that application. In this post, I want to discuss some common catch ups and show some solutions, so you can provide the permission system you need for your app without wasting to much effort in over engineering and performance considerations.

Super User

First thing people often agree is, that there should be an administrator or super user, who is allowed to do anything with everything in the system. This can happen by assigning all available permissions to him or implement a bypass of permission checks in code.

// bypass
if (user.id == 0) {
  return true;
}
const permissions = await loadUserPermissions(user.id);
return permissions.includes(neededPermission);

Going All In

When starting an app, project manager love to increase complexity. That is the moment, when they feel very innovative. Thinking about the app, the permission system has to be done RIGHT. Having groups, to determine departments and project groups, and having roles, to determine the job someone has and because the system is going to grow, groups can have sub groups and roles can have sub-roles. basically describing each as a tree structure. One will support adding permissions additive, the other also supports removal of permissions from the higher levels.

The computation of the permission in such a tree can be quite slow, there are lots of edge cases. It is getting really fun, when you also introduce tenants or separation into enterprises. I believe this kind of structure is able to kill a project, when introduced to early.

Powerful Simple System

Specially when starting out with a new application, I would propose to you, to keep the permissions simple.

That is it, permissions work additive. I believe this structure is good, because now it is up to the admin how the groups are getting used. a user can have multiple groups, a group can have multiple permissions. In such a system, it is up to the administrator, and user manager to decide how the groups get used. It is still possible to design some kind of hierarchy, by doing name spacing, or to use groups in multiple ways, by prefixing then with an 'R' for a role-group, or a 'I'm for individual groups. In code it will be just a one way join, to determine all permissions. a user has.

Moving from the simple approach to the complex one, can be done lossless, but starting out on a new project implementing a giant permission system can reduce the initial momentum and I want you to be able to move fast on your projects.

Types of Permissions

Same kind of usage of a simple list of permissions can be used for the permissions, there can be permissions, that grand access to a software module, and more detailed permissions to individual features. Such permissions can be easily maintained within the code.

Second, kind of permissions can become more complex, permissions by ownership or assignment. meaning the user is only supposed to see or update his stuff. These kind of permissions usually fall out of the general permission management and have to get managed with extra logic on the modules code level. The code can add or remove available permissions in the permissions table. New permissions can be created to reflect the existence of other entities in your system, they can be registered when you use a on the controller/router in code. Or permissions could even get registered from third party software, such a smart contracts or software that used your apps for authentication.

// in some express js application the following call
// can return handle permission checking as well 
// as creating the permission in the 'permission' table
app.get('/user/:id', requirePermisson('viewUserDetails'), userController.getUserById) 

I hope these thoughts will help you when designing a permission system the next time.