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.Our platform
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.
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.
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.
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.
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.
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.
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”.
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.
With these four XACML components, Attribute Based Access Control is enforced dynamically and in real-time.
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 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 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 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.
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:
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.
Learn what your organization should review to reflect the broader identity and security strategy of an orchestrated authorization process.Get the white paper
Mark Cassetta shares his view on how the authorization market will mature, including a new way of thinking about authorization deployments.Watch now
No matter where your sensitive data is stored or how complex or distributed your architecture is, we can help you safeguard and securely share sensitive data. Our team are experts in defining requirements and tailoring the Attribute Based Access Control products from our dynamic authorization suite to meet customers’ needs.
See how Axiomatics enables you to balance the demands of your security team and your business users with the authorization solution that our customers love.
In the meantime, check out this example demo...Book a full demo