Thursday, April 7, 2022

Software Engineering: RAED for Permissions

 In any given important software being used by many people, access control is an important part of security. For example, I have the proper permissions to edit this blog and you do not.

But there's many ways to implement access control. For example, Unix-like file systems generally have read-write-execute permissions. A user, group, or "other" can each have a combination of permissions to read, write, or execute a file. An admin might use the chmod command to edit a user's permissions.

Windows implements file access control differently. There are permissions such as "Full control", "Modify", "Read & execute", and just "Read" that can be allowed or denied to a user or group.

Windows File Permissions

CRUD is another way permissions might be implemented. A user can be allowed to create, read, update, or delete files or other types of data in any combination.

At my last job I was tasked with coming up with an authorization system for our microservices. Rather than use some framework for authorization, I decided to build our own. I was replacing WordPress permissions, which were similar to CRUD. For any given type of page, a user might be allowed any combination of the creation, reading, updating, or deleting permissions, depending on what an admin had checked. For example, our online magazine had CRUD permissions. All of our customers could read the magazine. Specific content creators could create new articles and upload them. Editors could update anyone's articles to fix grammar, spelling, or links. Finally, admins could delete articles.

Designing permissions was important. We didn't want to give a user the wrong set of permissions, otherwise they might be allowed to delete important data. Or, with insufficient permissions, they might not be able to do their job.

I decided to use something I had previously created: RAED, a superior access control design for general-use permissions.

RAED stands for read-add-edit-delete and is a set of eclipsing permissions to be used with file systems, RESTful APIs, or anything else that requires access control. It's basically CRUD, but much better.

Other permissions become confusing when certain combinations are used. For example, what does it mean when you can write something, but you cannot read something? When would you be allowed to delete data without being able to update it?

With RAED, there is no confusion because if you have one level of permission, you have all of the permissions below (or to the left of) it. If you can add, then you can read. If you can edit, then you can read and add. And finally, if you have the delete permission, you also have the read, add, and edit permissions for that particular thing. For any given permission level, just makes sense to have the lower permission level. When will a user need to delete data, but should be forbidden from reading or editing that same data?

RAED is simpler to display. Instead of four sets of radio buttons (Allow/Deny) in CRUD, you have five radio buttons (the first one being no permissions). Example:

Database Permission:

RAED doesn't work for all access control systems and permissions, for example, when you only need a simple binary Yes/No for Can-Upload-Photo-Permission or similar. However, if this meets your needs, I highly encourage you use RAED.