In the previous blog post we reviewed the concept of access review and discussed how well access control models deal with it. Also, at the end of that first part, we took note of the commonly-held concern that Attribute-Based Access Control (ABAC) complicates access reviews to the point that they become virtually impossible to do. If true, this is perhaps one of the most serious obstacles that could prevent wide adoption of the ABAC model.

Here we examine this issue futher with the intention of showing that the concern above is founded on a way of thinking that need not apply to ABAC, and that by coming out of that frame of thought we can find ways to implement well-performing access reviews for ABAC.

We start by describing the standard mindset that stems from access control models prior to ABAC.

The factors that affect access review performance

Let’s consider the access models discussed in Part 1 and their associated methods for calculating access reviews. It is easy to identify the main factors that contribute to their performance:

  1. The effort needed to determine the value of a cell in the access matrix.
  2. How hard it is to visit a set of cells (e.g. a row or a column) depending on the way the matrix is represented. I include here aspects like how data is related to each other, and where it’s located.
  3. The ability to avoid visiting empty cells in the access matrix.

ACLs and Capability Lists incur a rather low cost with respect to factor A. Determining the content of a cell in the access matrix is usually a matter of finding the subject or the resource, and searching through its list of resource-action, respectively subject-action, pairs. In RBAC, A weighs a little more, but only marginally. The binary relations subject-roles and role-permissions are fully precomputed, so that finding the content of a cell in the access matrix is ‘just’ a join of these two relations. By the way, RBAC also incurs some cost in resolving role hierarchies, but let’s omit role hierarchies here for the sake of simplicity..

If we now consider factor B, the first of two factors that concern the cost of navigating through the access matrix, we’ve seen how ACLs and Capability Lists show asymmetric qualities depending on whether we want to do a subject- or a resource-centric access review. For RBAC this factor may contribute more or less cost depending on the way the subject-roles and role-permissions relations are stored. For instance, in SharePoint’s take on RBAC, the role-permissions relation is spread out in ACLs which are attached to the documents. Thus, performing a subject-centric access review with SharePoint requires visiting, in principle, all stored documents, regardless of the user.

Finally, with regard to factor C, it is clear that ACLs, Capability Lists and RBAC, all come with representations of the access matrix that avoid storing empty cells. Thus all these models make it trivial to avoid visiting empty cells in the access matrix.

ABAC and access reviews, like water and oil?

Firmly implanted in the standard mindset, we now examine ABAC with respect to the three factors A-C.

In spite of the commonly held criticism, ABAC doesn’t necessarily get a low mark across all of A-C. In particular, ABAC has very good potential with regard to factor B, because an ABAC policy defines the value of each cell in the access matrix independently of any other cells. Thus, visiting a row, or a column, of the matrix is as easy (and as hard) as evaluating the policy for each cell in the row or column. We can say that, in ABAC, the access matrix can be accessed randomly. Compare this with the difficulties that ACLs have with subject-centric access reviews, for example.

The real problem for ABAC is with A and C, because ABAC does not do any precomputation of the access matrix (caching techniques notwithstanding). An ABAC policy can be arbitrarily complex, so computing the value of each cell may demand considerable effort. ABAC’s reliance on distributed sources of attribute data (usually called Policy Information Points, or PIPs) compounds performance even further. Furthermore, before a cell is evaluated there is no way to know whether it’s empty or not. So, in order to visit a column of the access matrix, every single cell in that column has to be examined, evaluating the ABAC policy in each case..

Can anything be done regarding A and C? It may seem we cannot. ABAC fares poorly regarding A and C because it does not precompute the access matrix in any way. Arguably the lack of precomputation of the access matrix is essential to ABAC, in that it allows to accommodate dynamic changes to the access matrix as a result of changes to subject or resource attributes. Drop that and ABAC loses one of its main winning concepts.

Jumping out of the box

The key out of the conundrum is to realize that, while the dynamic nature of ABAC is essential to its definition, dynamism is a requirement that applies mainly to single and direct access queries. These are normal access queries that take place the instant a subject attempts to perform an action on a resource. Using ABAC terms, they are the queries posed by a Policy Enforcement Point (PEP) to a Policy Decision Point (PDP).

Access reviews do not have the same crave for immediacy. They are executed every so often and cannot be so dependent on environmental attributes or any other contextual data that can vary from a minute to the next.

I mean then than an access review for ABAC can depart from the requirement to evaluate the ABAC policy at review-construction time. In terms of factor A above, this means that we can select what to compute of the access matrix, in advance and before the actual access review is requested.

Furthermore, I claim that for ABAC it doesn’t make particularly much sense to perform access reviews on very dynamic attribute data. This implies that an access review, for ABAC, cannot just be the same as evaluating a column or row of the access matrix. For obtaining that column or row requires building somehow a snapshot of the access matrix, and nothing tells me that what I see in such a snapshot will hold a second later. In terms of factor C (and coincidentally also of factor B), the implication is that resolving an access review may actually not require visiting a row or column of the access matrix.

Reconciliation

So if access reviews need not require runtime inspection of the access matrix or visiting whole columns/rows of the matrix, then we are challenging the choice of A, B and C as fundamental concerns. And when we do so, new approaches to access reviews open up. Here are three of them:

1. Reduce ABAC to a simpler access model

This is about precomputing the access matrix and converting it into a format that facilitates access reviews in the old sense. You need to take a snapshot of the subject and resource attributes and fix the environmental context to determine a kind of “frozen” access matrix. Then, using the ABAC policy and exploiting its internal regularity, proceed to calculate the contents of the matrix.  

When devising a solution along these lines, it is fundamental to be able to accommodate changes to attribute data so that a change to a user’s attributes does not imply recalculating the whole access matrix. The same holds for resource and other attributes, of course.
Axiomatics has successfully applied this approach in the Axiomatics Claims Provisioner for SharePoint.

2. Translate an access review to a query

An ABAC policy, when instantiated to a single subject, can be seen as a function that defines implicitly a whole row of the matrix. Under the appreciation that it is not necessary to evaluate this function on every cell of the row, the idea is to instead use the function as a filter to query (the sources of) resource attribute data. If we can convert this function to a query over those data sources, and if the execution of such a query is optimized, then we would have an efficient method to compute the access review.
Given the attribute data is usually spread among several non-collocated data sources, the requirement of efficiency tends to imply that attribute data be virtualized or even moved to the same location.

Axiomatics’ ARQ-SQL component implements this approach by translating each access review into a SQL query. The query must then be evaluated against the attribute data sources using a data virtualizer that exposes a SQL interface, or against a single SQL DB to which the corresponding attribute data has been previously copied using traditional Extract-Transform-Load (ETL) methods. You can read more about ARQ in this blog post.

3. Represent the result of access reviews as conditions

This is the most radical departure from the standard mindset. As I wrote above, ABAC excels at reflecting dynamics and accommodating the context of an access. The traditional access review result consists in a list of resources that a subject has access to, or analogously a list of subjects that have access to a resource. In a very dynamic environment, a traditional access review result is probably old and useless by the time it’s printed. Wouldn’t it be better if an access review informed on the conditions under which a subject is given access, or the conditions under which a resource can be accessed?

Using RBAC we could list the roles that provide access to a resource instead of listing the subjects that have those roles. In ABAC, we can instead explain how to access the resource using parts of the policy.

Naturally, the conditions extracted from the policy need to be presented in an easy-to-understand manner, hopefully in some kind of structured natural language.
Imagine if the access review for Bob read “Bob can print documents registered in the Marketing Department, either owned by himself or his subordinates Carl and Sven”. But I’d better wrap up and leave the details of this fascinating new approach for a later blog.

Conclusions

In this blog post we have examined one of the thorns on the side of the ABAC idea. After studying how access reviews are implemented over older access control models, we have identified the main reasons why ABAC access reviews have been long considered to be too complicated to do. We have hopefully shown, by stepping out of that frame of thought, how that need not be the case.  



Leave a Reply

Your email address will not be published. Required fields are marked *