Database design: RBAC or ABAC?

Question

I have a SaaS service where multiple users can collaborate with each other. Till now users under the same subscription account could share the same database and view/edit/delete everything from each other.

Now I'd like to implement a permission system so users may be able to do only specific actions like viewing, editing, updating and deleting contents (on my SaaS system the content is primarily a list of client cards).

My first guess was to use the RBAC technique, defining roles and a bitmask of different operations, e.g.

• viewing client cards
• updating a client card
• deleting a client card
• adding client cards

Those permissions are not tied to the single card instance rather than being generic actions users can perform. The first one (viewing) seems required in any case, as it would be impossible to use the system without being able to see any card.

Unfortunately I think I would also need some kind of per-card permissions. For example, an admin user may want to let a given user to view only a subset of the cards, not all of them. Or an admin user may allow a group of users to collaborate on a specific card (or specific cards), effectively partitioning the card list across the users. In any case, I never encountered a scenario where non-admin users can set such permissions for themselves or other users.

Is RBAC espressive enough to encode such requirement? Or do I need to switch to ABAC?

Answer 1

The rule of thumb is the following:

• If you have relationships in your authorization requirements, then go ABAC.

Let me explain. With RBAC, you can do things like define roles, role hierarchies, and permissions. You can also do some level of static segregation of duty. For instance a user can be given the role manager and the role senior manager. That, as a whole, gives them the right to view client records. So far so good.

But... if you need to say things like:

• you can view clients in your region only
• you cannot view a client you have a personal (parent-child) relationship with

Then you need more than just RBAC. You will need abac like you pointed out. ABAC does not fully replace RBAC. You still need users, user metadata (such as roles) and assignments from roles to permissions. Those assignments, though, rather than happening through a role management tool, will happen in the policies.

In alfa, this is what a policy would look like:

policy clientAccess{
    target 
           clause action.name == "view"
           object.Type == "client record"
    apply firstApplicable
    rule managersCanViewAll{
        target clause user.role == "manager"
        permit
    }
    rule employeeCanViewSameState{
        target clause user.role == "employee"
        permit
        condition user.state == client.state
    }
}

This statement condition user.state == client.state is ABAC's secret sauce.

Of course there are other benefits to ABAC such as:

• easier to grow and evolve
• easier to audit
• easier to reuse across apps and APIs...

Check out these resources for more information:

• Attribute Based Access Control (ABAC)
• NIST's take on ABAC