What is ABAC?

[00:00:00]
>> Kyle Cook: Awesome. So now that we've kind of looked at role-based access control, we're going to look a little bit more at kind of the limitations we've already run into before we dive into attribute-based access control, which is where most of the complexity of this workshop is going to come and most of the benefits you're going to see from the system are going to come. So we've already talked about how role-based access control excels when you have role-centric permissions, admins can do this, viewers can do that, and those permissions are generally relatively coarse-grained.

[00:00:26]
That means you don't have a lot of different attributes that you're checking, and that's really where role-based access control falls apart is when you start looking at other things besides the role, such as the document status or the creator ID. Those things are attributes outside of the role, and when you start to introduce those, role-based access control really falls apart. Another thing that role-based access control really falters at is when you want to deal with environmental factors.

[00:00:48]
This could be anything, such as what the time of day is, what computer is the user accessing this data from, are they connected to your company VPN? It's just anything that's related to the environment the user is in and not directly related to the user or the thing that they're accessing. This even relates back to an earlier question where we talked about maybe you want different permissions for a user based on what page they access the document from for creating it.

[00:01:13]
This would be like an environmental factor that role-based access control really doesn't handle very well. We've already seen how your permissions start to explode in complexity, and it only gets worse as your system gets larger, and you kind of try to create this hybrid approach where you create these helper functions like we've done, but as you can see that already starts to introduce lots of problems where now your permissions are kind of fractured throughout your entire application.

[00:01:35]
This is where we essentially want to graduate from role-based access control to attribute-based access control, and the thing specifically to look for in your code if you're using role-based access control, is when you get these large permissions, that's a giant red flag, that's probably the number one instance where you should move away. If you find yourself using lots of helper functions, again, a time to move away, or if you have lots of different checks for attributes across your codebase.

[00:01:58]
For example, maybe you only have one document read permission, but every time you access that read permission, you check things like the lock status and the user's role and things like that, that's another red flag for this type of system. So as I said, moving forward, we're going to be using attribute-based access control, and the huge difference, the only thing really that's different between attribute-based access control and role-based access control, is instead of looking just at the user's role, we look at every single attribute that makes up the thing we're trying to check.

[00:02:26]
And there are four main categories of attributes we look up. The first is the subject, and this is just who is making the request. 99% of the time it's going to be a user, but maybe you have an organization or a team that can do certain things, so it could be something besides a user, but in most applications this is your user. Next you have the resource, this is your document, your project, whatever you're trying to access or modify, that is the resource.

[00:02:50]
You then have the action, this one's self-explanatory, what are you trying to do? Usually it's like create, read, update, delete, and so on. Lastly, we have those environmental factors. These can be anything from the time of day, IP address, what device you're accessing your data from. These are things that are kind of outside the control of your normal system, but you still may want to control what people can do based on these certain things.

[00:03:13]
And the main way that attribute-based access control differs for how we use it is we take all these things, the subject, the resource, the action, and the environment, and we take all the attributes associated with them, the user's ID, their role, the document ID and status. We combine all those together and we shove them into some type of policy engine, and that policy engine is going to parse all of that data and it's going to spit out essentially true or false.

[00:03:37]
Does the user have access to do this thing based on all the other factors around them, the resource, the action, environment, and so on. So instead of just looking at role and mapping directly to permission, we instead now have this policy engine that has to handle all of this crunching of data for us. So we have a little bit more complexity, I should say a lot more complexity, when it comes to the actual functionality of making these checks inside of our application.

[00:03:59]
Now a simple attribute-based access control policy could look something like this JSON object, where you have an action, in our case update, we have a resource which is a document, and then we have a set of conditions, and this is really where the power of attribute-based access control comes in, it's because these conditions can check anything. It can check any attribute on anything, so you can check, for example, the role of the user, that's a very common thing you're probably going to check all the time.

[00:04:22]
You can check different attributes of your document or resource, so like who created this, is this thing locked, is the status draft. You'll notice this is essentially the exact code on if an author can update something or not, but now we've condensed this into essentially a JSON object that we can use inside of our code and parse what this actually means, and it's all dynamic. We can get the user's ID from the user and use that inside of this code.

[00:04:44]
Now our policy won't look exactly like this, but this is kind of a general idea of what attribute-based access control looks like. Now the main reason that attribute-based access control solves the problems we saw with role-based access control is because instead of creating individual permissions for every permutation of something we want to do, instead we just add conditions onto our permissions.

[00:05:04]
So for example, if we want to check if they can update their own document, we just check that the creator ID of the document is the user's ID. It's as simple as that, and we can add and remove as many permissions or conditions to each permission as we want, so we can make something a really complicated check or a really simple check depending on what conditions we want to add. Now we can take a look at a simplified version of how this would look inside of our code, and we get something that looks like this.

[00:05:28]
So we're going to be creating something called a permission builder. This is kind of our policy engine behind the scenes. This is where we tell the permission builder what someone can do, and then we essentially get back a bunch of functions we can run that parse the data through that. And in order to tell this engine what it can do, we just have a simple allow function. That's the main thing we're doing with this builder, is we just tell them we want to allow them or disallow them from doing different things.

[00:05:53]
Now, generally when it comes to writing out permissions, adding explicit denies is generally not something you want to do, you generally only want to allow permission. Instead of disallow, because when you have permissions that both allow and disallow, it can be really confusing to know which one should take priority and overall it makes your system much more complex. So in our example, we will only be writing out the allowed permission, but if you really want, you could add in a denied permission as well, and it's not too much more code.

[00:06:19]
Now each one of these permissions you'll notice has a few different parts. You can see we have the subject, or sorry, the resource we want to act upon, in our case a document. We have the action we want to perform, which in our case is a read action, and then we have a list of conditions that we want to have be applied. So we're saying an author can read any document as long as the status of the document is published.

[00:06:41]
They also can read any document as long as the status is archived, and they can read any document as long as the status is draft and the creator ID is equal to their ID. And the way that the permissions work in this attribute-based access control system is as long as one of these permissions returns true, you get a true result when you try to check your permission. So down here you can see we're saying permissions.can, same exact can function.

[00:07:04]
It also looks pretty much the same. We're passing it along the resource, we're passing along the action, and we're passing it along the specific data for that resource as well. This is the big difference between role-based and non-role-based access control, is now we are passing along the exact resource itself with all of its attributes to our permission checker. So we're just checking, is there at least one permission that we have allowed this user to do that matches the criteria we pass into this can function.

[00:07:29]
If so, it returns true. That's why you can see we have three different permissions for read, because there are three different scenarios where the user can read documents, and at least one of those must be true. So as long as the status is published, as long as the status is archived, or if the status is draft and the creator ID is equal to the user ID, they have access. And the way this works, you can kind of think about it as every allow statement you create is like an OR syntax, so it's either this one or this one or this one, and when you define multiple conditions inside of one object, those are like AND statements.

[00:08:01]
So the status has to be draft and the creator ID must be the user ID if that makes sense. And you can make these as complex or as simple as you want. For example, here, we have allowed document create with no condition at all, and that just means that they can create any document no matter what the attributes of that document are, they have blanket permission to do that. So if you leave off the condition, that just acts as a blanket allow them no matter what the document looks like.