RBAC and domain specific roles

Question

I have some doubts about RBAC which I cannot wrap my head around. So I would like to hear what you guys think.

Though I understand the concept of RBAC, I cannot figure out how to apply that to my specific use case:

I have a system that a company uses to audit its Franchises. So the components involved are:

1. The actual audit document
2. 2 different reports that are generated based on a single audit.
3. 4 types of aggregate reports that are generated based on the results, including tables and graphs.

This is how I'm planning to set up the RBAC.

I know how to use RBAC to allow the admin to give access to different user groups to various reports in 2 and 3.

My dilemma comes from point #1.

Suppose I create a role called Auditor and allow them access to perform audits, it wont do much, as each auditor has to be assigned to a Franchise for the audit to become accessible to them. So the question is why bother creating a role in the first place.

On the other hand, I need to designate a specific set of users that are eligible to be assigned audits.

So my question is, keeping in mind that Auditor is a specific type of user that the application depends on to function, unlike the other roles that can be left to the imagination of the admin, is it sensible to make it a part of RBAC, or is there a better solution?

I hope you understand what I am trying to say here.

PS: I also saw some mentions of ABAC but couldn't make heads or tails of it.

Answer 1

In the RBAC model, user are assigned to roles, roles allow to perform "transactions", and all activities performed by the users (except identification and authentication) are part of some "transactions".

Your model is very similar, with the difference that individual users are assigned to roles via a groups, and that you prefer the use of "permission" rather than "transaction", which has the benefit of clarifying that granting a transaction is in fact a permission to perform some activities with access to some sets of data.

A granted permission is however not a guarantee in the RBAC model. It is perfectly legitimate that granted permissions are constrained/restricted based on some additional logic or rules that are not part of the role definition. For example, a view audit report permission does not necessarily guarantee access to all audit reports, but can restrict the viewing to only those audit reports the user is the author from; or the audit reports of the Franchise the user is dynamically assigned to.

Accordingly, the Auditor role could be the permissions to create, modify and view audit reports (no, audit reports are never deleted). And these permissions would be restricted to the Franchise the user is assigned to. The benefit of having a role, is that you can combine transactions/permissions differently. For example, you could have a CEO role with full view access to audit reports, but not any permission to change. Maybe one day, the audit department will hire a reviewer with view and update permission. The role has the advantage of keeping organizational responsibilities flexible.

Your narrative suggest that there is no real need for an Auditor role. But this would mean that auditor user can perform activities/transactions outside the context of any role. This would no longer be pure RBAC according to the definition above. In fact, I suspect that some role based logic is currently hard coded in auditor users instead of staying flexible and customizable via the role.

The question left open is whether the Auditor's permissions should be constrained by hard coded rules (e.g. assignment of the user to Franchise) or if they should be decoupled, moving the constraints into the definition of the permission (e.g. no longer view, but view on <set of franchise>. While this is the paramount of flexibility, it might however imply defining much more roles (roles by set of franchises) and risk inconsistencies (e.g if assigned to a franchise for which there is no permission in the user's role)

Answer 2

With RBAC all you have is the role. You can designate the auditors by assigning them the Auditor role but you'd need additional code to check if the user is assigned to the franchise in order for them to be allowed to perform the audit or view the documents.

With ABAC you have more flexibility, but it's also a bit more involved. You can define policies and rules that use attributes. An attribute is nothing more than a property of an entity in the application or of the environment the application resides in. Policies and rules can be defined using a procedure similar to assigning roles in RBAC and you'll need to implement code that evaluates them.

An access control policy for the perform_audit action could look something along the lines of:

Perform audit (policy)
|-- target: [action-name] == "perform_audit"
`-- Assigned auditors can perform audit (rule)
    |-- target: ([subject-role] == "Auditor" or [subject-is-auditor] == "true")
    |           and [subject-franchises] contains [audit-franchise]
    `-- permission: allow

The names in square brackets are attribute names. The target is a filter for selecting policies and rules that match the request.

When a request for the perform_audit action comes, you collect all the relevant attributes within that context and pass them to a part of the application that checks the rules against the attribute values. If a conforming rule is found then you return the permission specified by the rule. If no rule is found then a default permission can be returned instead (in most of the cases it's deny).