This is a two-parts blog post on the difficulties of doing access reviews with Attribute-Based Access Control (ABAC) and how to work around them.
In this post we discuss what an access review is, what it is used for, how it’s performed depending on the access control model and notice that it’s hard to do an access review with ABAC.
What is an access review?
You have set up a neat access control solution. With time, users are added, permissions are changed, objects are deleted. Now, you pick a user and wonder: Which objects does this user have access to? And then, what actions can this user perform on those objects?
You are after what is usually called an ‘access review’.
An access review is a query involving a set of users/processes (we shall call them “subjects” from now on) and/or resources. Subject-centric access reviews produce the set of resources (together with actions) that a given subject can access. Resource-centric access reviews are analogous, but they start from a fixed resource instead.
Access reviews are of fundamental importance for before-the-fact (or apriori) audits, when it is important to determine what resources can be accessed by a subject, or who are the subjects that can access a resource/group of resources. Access reviews are also useful to communicate to users what their permissions are.
Access reviews are easy, with an access matrix
It is easier to explain what an access review is if we appeal to the concept of the access control matrix, a common conceptual artifact when talking about access control. As we are here talking about simple, direct, non-administrative access control, you can think of this matrix as a two dimensional one, with subjects at the rows, and resources at the columns. Then the cell at the intersection of the row for Bob with the column for bank account A555 contains the actions that Bob is allowed to perform on account A555.
Talking about access reviews, what is Bob entitled to do according to the access matrix? Easy. Find Bob’s row and there you have it: Each cell in that row tells us something that Bob can do on some resource.
Who can access account A555? Easy. Find A555’s column and there you have it. Each cell in that column identifies a subject and an action that the subject is allowed to perform on A555.
So far so good, but as we all know, there’s always a catch.
Access control matrixes are just conceptual tools. They help visualize things. But when you have a few tens of thousands of subjects and millions of resources, it is neither viable to actually construct such a matrix nor feasible to manage it. Furthermore, in practical situations, the cells of such a matrix will be mostly empty.
Enter the access control model: ACLs, capabilities, DAC, RBAC, you name it. One way or the other, they all propose a mechanism to represent the data in the access matrix without actually building it. Of course they also attend to many more requirements, like the need to build an access matrix that matches and easily adapts to the needs of business.
What this all means, in short, is that performing an access review very much depends on the actual access control model we have chosen for our system. We all know that two of the most important aspects that affect the time performance of an algorithm are data representation and data locality. Access reviews, in the sense that they require an algorithm to be computed, are no exception.
Let’s take a look at one of the earliest, but still widely used, access control models, the Access Control List (ACL). In this model, the access matrix is represented column-wise, eliminating empty cells.
In terms of locality, many ACL implementations attach the ACL to the object, meaning that in order to find the ACL corresponding to a resource, you first need a pointer to the resource itself. As a consequence, resource-centric access reviews are extremely easy to implement (it’s result is actually the ACL for the resource!), but subject-centric access reviews are much harder (in terms of computation). You basically need to iterate over all resources in the system and over each ACL to determine if a given subject has access to the resource.
ACLs may be wonderful for resource-centric reviews, but they have all sorts of other problems. No wonder the industry has moved over to other access control models. By the way, capability lists is a model analogous to ACLs, almost like an academic exercise (though it was actually implemented a few times in the 70s) where the access matrix is represented row-wise. As you can imagine, it’s great for subject-centric access reviews, but has awful consequences for resource-centric ones.
Access reviews in Role-Based Access Control
Role-Based Access Control (RBAC) has been the dominant access control model of the last two decades, so how does it lend itself to access reviews?
In terms of data representation, RBAC models the access matrix indirectly through the introduction of the ‘Role’ as an intermediary between subjects and permissions, where the latter are nothing but pairs of resources and actions.
To perform a subject-centric access review, things are not as simple as with the Capability Lists model, but still are quite straightforward. Given a subject, determine all their roles, and for each role, determine all the permissions. Trivial. Or? Well, it depends on data locality of course. Or, in other terms, it depends on how easy it is to navigate through the subject-role and role-permission relations. Take for example SharePoint’s claims-based access control model which, in general terms, is little more than RBAC with an ACL flavor. Claims behave like roles, but the mechanisms provided by the SharePoint API to access the role-permission relation start from a reference to the document (i.e. the resource). Finding all the claims a user has is just an AD query, but mapping each claim to the set of associated permissions requires visiting each single document in the system.
The case of SharePoint’s own flavor of RBAC illustrates the point that it’s not only a matter of access control model, but also of how the model is accessed using the offered APIs. We shall return to this later, when we discuss ABAC.
Resource-centric access reviews in RBAC are quite similar to subject-centric reviews but they navigate the relations in the opposite direction: From the resource, find all permissions over it; then, for each permission, determine all the roles that have those permissions; and, finally, find all subjects that have (or can activate) any of those roles.
Attribute-Based Access Control
The Attribute-Based Access Control (ABAC) model differs from all access models discussed so far in that the access matrix is never explicitly constructed, not even using a combination of relations like in RBAC. Instead, ABAC relies on an access control policy that implicitly defines the access matrix. Given a subject, a resource and an action, the policy defines whether the subject can perform the action on the resource. In other words, the policy defines the contents of each cell of the access matrix. If we were to physically construct the access matrix, we would have to evaluate the ABAC policy for each combination of subject, resource and action.
Because the policy defines the matrix on the basis of attributes of the subject, the resource, the action and even the environment, ABAC makes explicit the kind of organizational information that is implicitly encoded in a role. Practitioners are increasingly aware of the advantages of such an approach, which explains the interest in ABAC languages, like XACML.
ABAC has proven superior to RBAC in many respects; an opinion sustained also by the attempts, more or less successful, to extend RBAC with attributes (pdf).
Now one can imagine thinking, especially if you’re coming from the RBAC side of things: ‘The generality and flexibility of ABAC comes at a high cost; it surely makes some tasks much harder than with previous models, right?’
Richard Kuhn, one of the inventors of RBAC, puts it like this (pdf):
“Generally speaking, RBAC trades up-front role structuring effort for ease of administration and user permission review, while ABAC makes the reverse trade-off: it is easy to set up, but analyzing or changing user permissions can be problematic.”
In the quote, “user permission review” is nothing other than our friend, the subject-centric access review.
Indeed, the flexibility and dynamism of the ABAC model, with its implicit access control matrix, implies that an access review would have to evaluate the policy for every cell in a column or row of the matrix. Given that the policy is evaluated on the basis of attribute data that most probably resides in multiple and disparate locations, the performance of such approach is deemed to be extremely low.
Summing up for the day
We have discussed access reviews, their importance in terms of authorization management and how their implementations depend on the access control model. We have also noticed, like many others before, that ABAC does seem to complicate the computation of access reviews.
In the next installment on this blog we shall examine at close range the causes of such complexity, realize that they are in part a consequence of trying to apply old approaches to access reviews, and hint at a couple of alternative techniques to achieve well-performing ABAC access reviews.