Attribute based Access Control

Is Attribute-based Access Control (ABAC) the future? According to Gartner, it is. As per Gartner, by2020, 70% of enterprises will use attribute-based access control as the dominant mechanism to protect critical assets.

But have they? I don’t think so.

In my experience, ABAC has a lot of potential and  addresses key challenges with traditional Role-based Access Control (RBAC). More on that shortly.  One of the key reasons ABAC is not widely implemented (yet) is that organizations don’t have the requisite knowledge, skillset or simply the awareness to effectively utilize ABAC as an access control mechanism. Also, I feel organizations and to some extent, even the security community is content with the benefits and shortcomings of existing RBAC model and do not want to make too many disruptions; despite Identity and Access Management (IAM) being one of key problem areas for organizations.

Let’s delve deeper. Let’s start by understanding RBAC and ABAC. RBAC, put simply, creates groups of users (E.g., Administrator, Developer or even app specific groups such as Cashier, Doctor) and allots permissions / roles to that group (E.g. read / write / delete access to certain data or features) . All the users in that group, then have similar access permissions. This approach works and is widely in use but has its own set of challenges.

Below is a non-exhaustive, generalized list of challenges with RBAC:

• Ever increasing authorization complexities are causing an explosion of number of roles / groups. This explosion leads to role maintenance overheads.
  
• Often the roles created in the solution do not accurately reflect the real-word authorization requirements. This leads to people getting either liberal or restrictive permissions thus impeding the execution of their job responsibilities.
  
• RBAC can only consider membership to a group as parameter for making authorization decisions. If there are scenarios based on environmental context such as geography of access, time of access, classification of data, etc., these have to be managed via creation of additional roles / groups. Users will have to then request membership to multiple groups in order to obtain access to the same system. This again goes back to the challenge of role explosion. Further, administrators have to define and maintain multiple access policies associated with each group / role.
  
• When employees move to another role in the organization, the type of access they had in their earlier role has to be amended or removed to reflect their new role. For example, when an employee moves from HR to Payroll division, their level of access to employee data has to be changed accordingly. (see diagram above). Similarly, when employees leave the organization, his role and access have to be removed permanently.

So how does ABAC address these challenges? To be continued..

Reference: https://www.nccoe.nist.gov/sites/default/files/library/sp1800/abac-nist-sp1800-3-draft.pdf