Limitations of RBAC

[00:00:00]
>> Kyle Cook: So let's go ahead and actually see what are all the main things we gained from this. I've talked about them a little bit, but we now have one main single source of truth for all of our permissions, minus those small helper functions, which we'll talk about and solve later. We have much more readable code because instead of a bunch of if statements, we have code that you can essentially just read like English, and you don't really need to look any deeper than that.

[00:00:18]
We get full type safety, if I typed document or create incorrectly, it would throw an error, so we have that particular problem solved, and it's easy for me to update my permissions cause everything lives in one single file. Now if you want to be able to follow along exactly as you are, the code we're going to be having here is 4-Basic-RBAC. Just make sure you go ahead and check that code out. Well, now we get to dive into essentially the limitations of role-based access control.

[00:00:42]
This is where I find that role-based access control really falls apart and you need to lean towards a more advanced system. So as soon as we start to add more granular permissions to our system, things are going to fall apart. We have a few permissions I want to add. The first is that documents can be locked. If a document is locked, we are able to prevent editing, but admins should still be able to edit documents.

[00:01:02]
Also, draft documents currently are visible to everyone. You can see a draft document right here. I want to restrict that quite a bit. The only people that can see draft documents are the authors of the actual draft document, or if they're editors and admins, they can see all the drafts since they need to be able to edit them, and viewers should not be able to see any drafts at all. So authors can see their own drafts, editors and admins can see all drafts, and viewers are restricted from any drafts at all.

[00:01:27]
Also, I want to restrict the edit permission for authors. They should only be able to edit documents that they actually created. And of course, the document can't be locked, and they should only be able to edit documents that are drafts. As soon as they publish a document, it should no longer be able to be edited. So, a little bit of a permission matrix to explain all that is right here, so you can see, published and archived documents can be viewed by absolutely everyone.

[00:01:50]
A draft document can be viewed by admins and editors, but authors can also view a draft document as long as they are the ones that created it themselves. Unlocked documents can be edited by admins and editors, and authors can only edit unlocked documents as long as it's a draft document that they themselves created. Finally, admins can edit locked documents and delete documents, and authors and admins can create documents.

[00:02:15]
So the create and delete logic is exactly the same, but our view logic and our edit logic has changed drastically because now we have these new sets of permissions inside of our code we need to handle. And this is where you'll really start to see the problems of this simple role-based access control, and that is that we're not just depending on our role, we're depending on, such as the department of the user, we're depending on the creator ID, that is locked status, the status of the document.

[00:02:38]
All these different things, and if we attempt to implement this in role-based access control, you're going to start to see these permissions explode, just like we saw with the Project read. You can see here we have document update all, document update unlocked, and so on, and every single time you add a new permission to your system, you need to create a permission in this array to handle it, and then you need to make sure you handle that inside your code with helper functions or something else of the like.

[00:03:00]
So while it may look like we have a single point to define everything, as our permissions get more complex, you can see that these permission handling things, it's kind of squeak out of our permission system and start to infect different parts of our application. So is it fair to say that one of the drawbacks of role-based access control is you're limited in the granularity of the permission? Yes, 100%.

[00:03:22]
Role-based access control is great when you have one permission that handles like true false for everything, but as soon as you start dealing with attributes of the things such as the user's department or the project's status and things like that, then you start to really run into problems with the role-based access control, unless you only have a few instances of these things, but in my experience, almost every project you work on has lots of these more granular permissions, and role-based access control just doesn't really fit that type of system.

[00:03:52]
Yes. Can you combine role-based access control with attribute-based, or is it either or? So, yes you can combine them, but attribute access control looks at attributes, and a role is just an attribute of a user, so technically attribute-based access control is already using the role in its own type of way, if that makes sense. And we'll get to that when we talk about attribute-based access control.