Attribute-based Access Control (ABAC)

As one of our older assets, this may not reflect the most current information for our offerings. Also visit our documents portal or contact us for support.

ABAC explained

Attribute Based Access Control, otherwise known as Policy Based Access Control (PBAC) is typically used to safeguard data in applications, databases, microservices, and APIs, within complex architecture.

ABAC is used to grant access based on a user’s location, role, the time of day, the device being used, the resource in question, and the desired action, i.e., all the attributes necessary to enforce secure authorization dynamically and in real-time. Put simply, attributes act like the levers in a lock, in that all of them must be aligned – with a policy – before access to data is granted.

Pros and cons of ABAC

Attribute Based Access Control offers organizations a level of dynamic security that simply isn’t possible with static authorization models, such as Role Based Access Control (RBAC). The benefits from ABAC security make it ideal for meeting specific data security business challenges that require granular and context-aware authorization.

Pros of ABAC

Policy-based simplifies authorization

One key benefit of ABAC is that access to data is governed by corporate policies; changes are made centrally and enforced across the organization.

Regulatory changes are easy to implement. changes to people’s access rights when they move role, join or leave the company are automatically applied, and auditing access rights is much simpler.

Granular and contextual for greater security

Another key benefit is the richness of authorization. You can control who can do what, when, how, why, from where, and from what device, in real-time. A good example of this would be when protecting data to meet export data controls. A policy could read: Model X Blueprints (what) can only be edited (why) by an R&D or Design Senior Manager with US citizenship (who) during US office hours (when) from a company facility in Europe or the US (where) via a Grade 5 security-cleared company laptop (how). If one requirement of the policy isn’t met, the resource will not be made available.

Data integrity enables more effective operations

Authorization is often only considered as a method to stop unauthorized access to data. However, ABAC ensures data integrity, i.e., sensitive data can only be accessed securely by the right people or applications under the right conditions, so it can be used more effectively.
Rather than being forced to block access to sensitive data, you can make the data work for you know it is secure.

Regulatory compliance

Any organization that collects personal data must protect it. GDPR and HIPPA among other regulations, make it critical to safeguard Personal identifiable Information (PII). Protecting it according to a person’s role will not provide the level of security necessary. The data must be secured with the strictest controls, while ensuring it can still be used by those people and applications that need it. Doctors need access to patient data, but not from their phones when sat at an airport, they must be in a secure environment to use it.

Cons of ABAC

Although there are many benefits of Attribute Based Access Control, not all organizations will have a need for it.

Only applicable for complex authorization requirements

Implementing Attribute Based Access Control requires the mapping of authorization policies in order to develop a rich policy set that can securely govern access – something that Axiomatics customers often do for a specific part of their business. Organizations with little or no sensitive data should not consider investing in ABAC until they warrant the investment, nor should organizations that do not have complex authorization requirements.

How are attributes used in ABAC to express access controls?

Attribute Based Access Control uses attributes as building blocks in a structured language that defines access control rules and describes access requests.

Attributes are sets of labels or properties that can be used to describe all the entities that must be considered for ABAC authorization purposes. Each attribute consists of a key-value pair such as “Role=Manager” or “Resource=Blueprint” or “Action=Edit”.

Main components of ABAC – the XACML standard

Axiomatics implements Attribute-Based Access Control through XACML. The XACML policy language is as expressive as a natural language. For example, consider the following sentence: “A user wants to do something with an information asset in a given context”.

A sentence like this includes four grammatical building blocks that can be used to enforce ABAC security.

• a subject
• an action
• a resource
• the environment in which the request is made

With these four XACML components, Attribute Based Access Control is enforced dynamically and in real-time.

The four building blocks of ABAC authorization

The subject

The subject, who is demanding access to an information asset.

General attributes describing the subject, for instance, roles, group memberships, the department/company to which the user belongs, management level, certifications or competencies, user ID, etc., can often be retrieved from an HR system or directory (LDAP).

These attributes may also be available in the token received from the authentication service used during login, for instance, a SAML token.

The action

The action that the user wants to perform. Common action attributes in authorization requests are “read” and/or “write”. In more complex scenarios, the action may be described by a combination of attributes.

When you access your online bank, the action may for instance be described by multiple attributes, such as “action type=transfer”, and “amount=$500”.

The resource

The resource identifying the information asset or object impacted by the action. Resource attributes render the characteristics that identify the information asset.

In the online banking example directly above, the resource most likely is your “debit account=”, in a document management system, attributes typically correspond to the metadata or tags entered when the document is checked-in, in eHealth applications the resource is probably a part of the health record identified by the patient ID, etc.

The environment

The environment identifying the context in which access is requested.

Common environment attributes are related to the current time and location from where access is requested, to the type of communication channels, such as protocol or encryption strength, or client type (PC, smartphone, etc.). Authentication strength may also be relevant to authorization.

Context data can principally be of any type that is relevant to consider to minimize risks or to plan precautions: the number of transactions already made in the last 24 hours, normal user behavior patterns, relations to a third party, availability of related legal contracts, etc.

Policy-based Access Control

As mentioned earlier Policy Based Access Control (PBAC) is essentially the same things as ABAC, as it’s the attributes with a policy that are enforced, as can be seen in this example:

• A policy states that “all users belonging to the sales department should have read access to proposals sent to customers within the sales region to which the user belongs”.
• An access request evaluation based on the following attributes and attribute values should, therefore, return PERMIT:
  Subject’s “department”=”sales”
  Subject’s “sales region”=”NW”
  Action=”read”
  Resource “type”=”proposal document”
  Resource “region”=”NW”

Attributes take system Integration to a new level

Attributes are often retrieved from different information systems within the infrastructure. A policy can thus combine the state of data in many systems to resolve an authorization request. In the example above from a sales department, the user’s department may be retrieved from an HR system, the region from a CRM system, and the document type from a document management system. Authorization thereby enables integration to support workflows that incorporate IT support from multiple IT systems, something that is virtually impossible to handle with traditional access control models.