Benefits & Limitations of ABAC

[00:00:00]
>> Kyle Cook: Awesome. So, we had a lot of brain burning essentially to get to this point where we have this attribute-based access control system set up. Let's talk about what are the actual benefits that we get from this and maybe some drawbacks associated with it as well. So the first thing that we can talk about is where attribute-based access control really excels because I find that this is probably the best method for doing permissions, at least over role-based access control.

[00:00:24]
The big benefit is you now have the ability to check any attribute across any resource or subject in your database. So it gives you really fine-grained permissions without having to worry about these permissions exploding throughout your application. You also get the ability to have environment aware permissions, for example, only things can happen on the weekend, or maybe you can only do this while you're connected to VPN.

[00:00:46]
All of these things are really difficult with role-based access control, but they're trivial with attribute-based access control as we saw. Also, you can add in things like field-level restrictions. This does add an extra level of complexity, but it gives you an extra level of things you can do in your application if it's something you truly need. Now, of course, there are downsides to attribute-based access control.

[00:01:08]
The biggest one, as you probably saw, was the complexity associated with the TypeScript code. As you saw, there was lots of TypeScript that we had to write, and it wasn't simple TypeScript, it was rather complex TypeScript that is very easy to mess up if you're not super familiar with the more complex sides of TypeScript. Another huge downside to this is if you want to make your conditions more complicated.

[00:01:28]
Every condition we did was a very simple, this equals that. We didn't do anything else more complicated. If you wanted to add things like greater than or equal to between and things like that, you're going to add a huge level of complexity, not only on top of your TypeScript, but also on top of your can function, your permitted fields function, and your function that deals with everything related to converting your code to a SQL query.

[00:01:49]
So there's a huge explosion in complexity as soon as you want to add these extra more advanced features. Another thing is that attribute-based access control, especially the more advanced version that we just went over, is pretty much huge overkill for most small, even medium sized projects. Things like field-level permissions and complex conditions and automatic query generation are not things you need for a smaller to even medium sized project.

[00:02:14]
So going with just basic role-based access control or basic attribute-based access control is probably better for those smaller projects than jumping into a more advanced attribute-based access control like we looked at here. Now, as we see attribute-based access control, it does give us the ability to do all these additional things such as be able to check attributes, have this one unified API and the ability to do everything else, but by using the basic version, we essentially eliminate the overhead of what I consider to be the much more complicated TypeScript side of things for things like field-level permissions and automatic query generation.

[00:02:51]
No, yeah, just Dustin. For operations like the update and delete permissions, should we enforce the data parameter, or is there a use case where calling can without it is fine? Yeah, so the reason you may want to not have the data parameter along is like let's say that you had a page that was like, it was like, I want to update a document, but it's like listing all the documents that you can update.

[00:03:18]
Going to that page means I just have the ability to update one document. Like let's say a common use case would be I want to update 8 documents at one time on one page, maybe your UI has that. You essentially want to just go to that page and say, can they update documents in general, let them go to that page, then the filtering from the database on which documents they can update will only show them the ones that they can update.

[00:03:40]
If that makes sense. For the most part, you're probably not going to be using it without that field at the end because usually you're checking for individual updates or individual deletes, but sometimes you may have a thing where you're saying, I want to update every document for one project all at once, and in that case, you may not want to pass along the individual document if that makes sense.