Attribute-based access control, otherwise known as policy-based access control (PBAC) is typically used to safeguard data in applications, databases, microservices, and application programming interfaces (APIs), within complex architecture.
ABAC is used to grant access based on a user’s location, role, 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 of ABAC security make it ideal for meeting specific data security business challenges that require granular and context-aware authorization.
Pros of ABAC
ABAC offers several advantages including:
- 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 roles, join or leave the company are automatically applied, and auditing access rights is much simpler.
- Granular and contextual for greater security: 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. The General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HIPAA) 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 sitting 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 ABAC requires the mapping of authorization policies 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? ABAC 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 eXtensible access control markup language (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, ABAC is enforced dynamically and in real-time.
The four building blocks of ABAC authorization
1. 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 security assertion markup language (SAML) token.
2. 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”.
3. The resource
The resource identifies 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.
4. The environment
The environment identifies 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 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 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.
Axiomatics and ABAC
No matter where your critical assets are stored or how complex or distributed your architecture is, we can help you safeguard and securely share them. Our team has experts in defining requirements and tailoring our ABAC solution to meet your policy-driven authorization needs.