Download your copy of our State of Authorization: Playbook Edition Get it now »

DZone: Why Attribute-Based Access Control – The Evolution from RBAC to ABAC in Data Access Control

Learn more about the evolution from RBAC to ABAC in data access control, in this article, "Why Attribute-Based Access Control Will Become the Standard Model for Large Enterprises," by Mans Hakansson.

Learn more about the evolution from RBAC to ABAC in data access control.
A feature article in DZone by Måns Håkansson

Evolving from ACLs and RBAC, ABAC is now the standard model for organizations to ensure employees only have access to the information they need under the right circumstances.

Today, data is often characterized as the new oil of the digital age. Organizations are leveraging their data to enhance operational efficiency, better the customer experience, increase revenue, and boost growth. In addition, virtually every organization is now collecting data, whether it be from banks and financial institutions or healthcare organizations and industrial manufacturers.

Not only are these businesses all about collecting data, but they are also collecting it from a wide variety of sources at an accelerated pace, resulting in an increasingly complex data environment. Not to mention the business complexities collecting data brings like privacy protection, IP protection, and brand protection. However, data is only useful if it can be securely shared and leveraged across not only an entire organization but also across business partners and third-party suppliers.

For example, when a patient is admitted to the hospital for a serious illness, doctors will need access to their personal information to verify insurance policies and go over past medical history before they can decide which tests to run and a treatment plan. However, besides the doctor, not everyone in the hospital should have unfettered access to all that information about a patient.

Nurses may need some access to medical information, but they do not require access to any personally identifiable information (PII). X-ray technicians may need access to x-ray results, but they don’t need access to blood test results. Not only is it important to securely share information to treat sick patients in the medical, but it is also critical across other industries.

A good example from the manufacturing industry is IoT data hubs. Manufacturers are collecting data from IoT devices to speed up production time. By collecting data points on non-conforming events that arise on the factory floor, manufacturers can mitigate underlying problems in the manufacturing process to ensure defective products never reach the customer. However, this is proprietary information that businesses do not want to be disseminated to competitors and only certain people involved in the manufacturing process require this information.

To securely share and employ data for treating patients, improving manufacturing processes or a variety of other uses across industries, all organizations need a modern data access control model. Before we get into modern access control, it’s important to look at how access control has evolved to this point.

The History of Data Access Control

As time has gone on, the amount of information every organization is required to protect has quickly increased. When there was less data to protect, access control models were much simpler.

In the past, data access control was summed up in three stages. First, we had access control lists (ACL), an early form of digital access control that allowed access to data based on user identity. Eventually, organizations required enhanced protection of their data, resulting in a new model of access control referred to as Role Based Access Control (RBAC).

Roles enabled administrators to allocate users to different groups with specific access rights. Roles are often based on job functions, locations, and titles to facilitate access to information. Because of the simplicity of roles, they were easy for developers to reference, using various coding techniques when performing internal application access checks. RBAC worked great until organizations and applications grew, the amount of data increased exponentially, and the need to protect data, microservices, and APIs arose.

This illustration is an example of “role explosion” for just three users. Imaging roles for an enterprise with 10,000 employees.

Image title

With such exponential growth, the number of roles required became unmanageable resulting in role explosion and segregation of duty (SoD) failures. Finally, a new, more dynamic form of access control was introduced called Attribute Based Access Control (ABAC).

From RBAC to ABAC: The Evolution of Data Access Control

In the digital age, data access control is best done with an ABAC model. Unlike RBAC models, ABAC can employ user attributes, action attributes, context attributes (such as time, device and location), resource attributes (such as a record’s sensitivity), and much more. The fact that we can use multiple attributes (data) that describe the user, the resource and the context makes ABAC multi-dimensional and capable of supporting virtually any access control scenario.

Image title

A policy would look like this:

Image title

ABAC delivers a multi-dimensional access control system that — through its use of attributes and policies — prevents role explosion, increases scalability, enables relationships, eliminates SoD conflicts, and externalizes authorization for ease of management control.

What this means in a healthcare scenario (based on the policy above) is that the authorization decision process, whether if a user should be granted access to a resource, is a dynamic process that evaluates the context as a whole.

The attributes in this scenario come from multiple sources. Some are sent from the application, and these are often user and environment-related attributes such as the user’s identifier, the authentication strength (level of assurance), the resource identifier (medical record #123), and the action (view, edit, etc.). These key attributes trigger the policy and then evaluate the rules.

The authorization engine now collects the required attributes needed for the decision process to complete. These attribute values are derived from both the medical record #123 itself but also from other sources. This might include collecting data from the insurance policy of the end-user, verifying a consent, or a delegation or checking the insurance agent’s contract validity. All these aspects are factored in before the authorization decision is reached.

In addition to leveraging attributes to simply deny or grant access to data, ABAC leverages data masking to protect critical information while also allowing it to be shared and leveraged. It works by obscuring or completely redacting sensitive data items, such as a hospital patients insurance policy number or the name of a participant in a clinical trial.

Data access control has evolved to meet the changing data protection challenges organizations face in the age of unlimited data. Evolving from ACLs and RBAC, ABAC is now the standard model for organizations to ensure employees only have access to the information they need under the right circumstances.

Read the article in its entirety on DZone.

Kelly O'Dwyer-Manuel

Media Contact

Kelly O'Dwyer-Manuel
VP, Brand and Communications

Archived under: