Access control: RBAC with additional group memberships instead of object properties

Question

Given an application that shows objects (e.g. films) according to certain user permissions.

The general permission to show or create objects is implemented as RBAC with roles and permissions.

The specific permission to access an object with certain attributes (e.g. a film with the attribute “drama”) should be implemented with memberships. That means the object doesn’t have the property “drama”, it is a member of the group “drama”. If the user and the object are members in the same group, the user has the specific permission to access this object. There can be different groups for showing, creating or deleting an object, like a simple viewer group or some kind of editor group. Furthermore there is a table that specifies which group types are relevant for certain actions on certain objects. For example relevant groups for the action “show” on the object "film" could be “genre” and “age” (film's suitability for certain audiences).

The reason to implement it in the described way is to have great flexibility without touching the code. Changes to groups can be processed in the database.

General database design:

Example: The film "The Revenant" is a member of the groups "genre:drama" and "age:18". The user can access it, if he is a member of these groups too.

Does this sound like a good approach? Are there any existing solutions that are similar to this approach? Does it have major drawbacks (e.g. too many database queries - there may be several hundred users every day)?

Please share your thoughts on this issue with me - the choice of "drama" as category for the example is not a coincidence ;) I just dont know if this is a dead end or if I am heading to the right direction. I stuck at this point for quite a while.

Answer 1

At least you have a good sense of humor :-)

Your approach sounds fine. So long as you keep the number of parameters low, then you can get away with role-based access control (RBAC) and a few additional parameters e.g. group membership.

But in the long run, if you want to implement business-driven authorization (access control), you need a way to do this independently of your code: you do not want to rewrite your app code every time there is a requirements change.

To do so, there is an access control model called Attribute-Based Access Control (ABAC) that will let you define your authorization policies independently of your code.

In ABAC, you have the following concepts:

• an architecture which defines a policy enforcement point (PEP) and a policy decision point (PDP). The PEP sits in front of (or within) your app. It intercepts the business requests (e.g. a request to view a film) and sends an authorization request to the PDP. The PDP is configured with policies. Based on the request the PDP will reach a decision: either yes, Permit or no, Deny.
• a policy language: the policy language is attribute-based (hence the name ABAC). This means that you can use any number of attributes (e.g. user role, user id, user group memberships, but also user age, user location, user subscription as well as resource attributes such as movie rating, movie category, movie price...)
• a request / response scheme: this is how you ask for authorization. It is essentially a yes/no flow. "Can a user do X?", "Yes they can."

There are several implementations of ABAC out there - some of which are framework-specific e.g. CanCanCan. XACML and ALFA are two approaches that are not tied to any particular framework. You can choose from open-source and commercial implementations of either language e.g.:

• Open Source: SunXACML, ATT XACML
• Commercial: Axiomatics Policy Server