Attribute-Based Access Control – ABAC

ABAC is a “next-generation” authorization model that provides dynamic, context-aware, and risk-intelligent access control. It helps achieve efficient regulatory compliance, effective cloud services, reduced time-to-market for new applications, and a top-down approach to governance through transparency in policy enforcement.

Attributes are Used to Express Rich Policies

Attribute Based Access Control (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 authorization purposes. Each attribute consists of a key-value pair such as “Role=Manager”.

Attribute-Based Access Control (ABAC)

The XACML Standard

Axiomatics implements Attribute-Based Access Control – ABAC 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:

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

Each of these can be described using attributes:

  • 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=<your account number>”, 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.

Policy-based Access Control

Attribute evaluation then enables effective policy-based authorization. Let’s consider 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”
    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, 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.