Is this a good strategy for implementing access control?

Question

I'd like to implement a database-driven access control system. I've been reading about ACL, roles, RBAC, etc., but it seems like the most common schemes have some major drawbacks. RBAC, for example, seems to be clunky when it comes to implementing fine-grained access control (for example, allowing a certain role to update only particular columns of a particular record).

What if I structured my access control list like this:

| role  | table | action | columns  | conditions        |
| ----- | ----- | ------ | -------- | ----------------- |
| user  | user  | view   | name, id | self.id = user.id |
| user  | user  | update | password | self.id = user.id |
| admin | user  | update | *        |                   |
| admin | user  | create | *        |                   |
| admin | user  | delete | *        |                   |

The idea is that a user's role(s) would be checked against this table when they try to access the database (so, implemented at the model level). action can be any one of {create, view, update, delete, list}. The self scope would be a reserved keyword that references the current user's properties. This would allow us for example, to only allow users to update their own passwords (and not someone else's).

Is this robust? Obviously I would still need a separate list to control access to other types of resources like URIs, etc.

Answer 1

Great question. You are hitting the limitations of ACLs and RBAC. There is another way which is more flexible called attribute-based access control (ABAC).

The following diagram shows how access control has evolved over time to cater to more complex scenarios (more users, more data, more devices, more context).

More specifically, you are struggling with the fact that RBAC doesn't support relationships. ABAC does however. ABAC is based on attributes. An attribute is just a key-value pair e.g. role == manager or location == Arizona.

ABAC uses policies with attributes to express authorization scenarios. For instance, in ABAC you can express scenarios such as:

• A user with the role == doctor can do the action == view on a resource of type == medical record if the doctor location == the patient location.

There is a standard called XACML (eXtensible Access Control Markup Language) which you can use to implement ABAC. There are even products that offer XACML specifically for databases and data access control such as the Axiomatics Data Access Filter.

If you want to learn more on ABAC I recommend you turn to 2 great resources:

1. NIST: Guide to Attribute Based Access Control (ABAC) Definition and Considerations (pdf)
2. Webinar on the NIST document.