Stack Overflow: ABAC vs. RBAC via XACML Policies

Axiomatics   ·   Friday, January 11th, 2019

The Axiomatics technical teams across sales engineering, development and customer relations often engage with the Stack Overflow community to get insights and answers. They also contribute knowledge on access control and dynamic authorization.

This question on access control models, asked by Haris Qureshi, presents a use case and coinciding challenge, all of which David Brossard,  addresses in detail.

I am studying about various types of access control models, and came across to know that ABAC and RBAC are the popular ones. I’ve a basic scenario for one of my projects and I couldn’t understand should I go with RBAC or ABAC. I have admin, owner and member roles in my identity server (IS).

• Admin can view, delete and update users.
• Owners can view and update.
• Members can view only.

At the moment, I am using HTTP verbs to achieve desire results, i.e. owners can not access DELETE requests and members can’t access PUT & DELETE.

Challenges:

I have a dashboard where I am displaying different sections like top-users, billing, services, top-consumers etc.

• I need to populate a nav-bar based on user roles and attributes from server, e.g. members should not have access to see other users (Add, List) in nav-bar. Nav-bar items depends on user role, so can we manage them via RBAC?
• We have a plan to add roles like operations, marketing, support, etc. Does this means we need to create a separate DB schema to maintain access rights for each role?
• In the dashboard, I need to hide/show view, update and delete buttons in users, services, etc. Now members can see users but have no permission to update or delete them. They cannot view stats, billing and other private information.
• Owners can see all users related to their departments/organization, but admin can see all the users for all departments/organization. Here we need to consume the same API for all consumers, but the API should respond differently for different roles. Roles can be 10s and 100s, so we can not create different APIs for each role.

Question:

We can implement all these scenarios via RBAC, but for managing nav-bar and view-related implementation, we need to add business logic in our server instead of using WSO2-IS and WSO2-APIM. Is there any way to manage view permissions like hide/show buttons and sections, and even consume the same API, but return different results for different API consumers?

ACL, RBAC, and ABAC

Historically, access control has been tackled through access control lists (ACL), then role based access control (RBAC) and, lately, attribute based access control (ABAC). ACLs grew unwieldy and hard to manage, which is why NIST came up with RBAC in 1992 (yep, it’s that old). RBAC is well-known, mature, and built into most IAM products and applications. For instance, a user directory (LDAP, AD., etc.) maintains users and role assignments and provides applications with those roles which the app can then use to determine whether access should be granted. With RBAC, fine-grained access (e.g. access based on relationships as in your case whereby a user can only see their own data) is impossible, so either (a) the application developer writes custom code to achieve the right access, or (b) you use ABAC.

Why ABAC?

ABAC gives you the ability to define fine-grained access based on any kind of attribute (not just role and not just user attributes) by using policies to describe what can (or cannot) happen. ABAC is sometimes called PBAC (policy-based access control). You refer to XACML which is the language in which ABAC policies are implemented. You can also look into ALFA (Wikipedia), a simpler language that maps directly into XACML.

You can find the rest of the detailed discussion on this topic and guidance from David Brossard here on Stack Overflow.