One of the great benefits of Attribute Based Access Control (ABAC) is that it can be as coarse or fine-grained as you need it to be. You start with two attributes: role and data, and you have Role Based Access Control (RBAC). But from there, it gets much more interesting, as you can add as few or as many attributes as necessary to your authorization policy in order to control who can access what. Attributes such as time of day, location of user, device being used, etc. The context of each attribute is then taken into consideration at the time of request before access is granted or denied.

Read on to find out how you can use your policies built from attribute to define access control, enabling secure sharing, protection of critical assets and compliance with internal and regulatory requirements.

Attributes are used to express rich policies

Attribute Based Access Control Architecture

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”.

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:

  • 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, and so on, 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 channel, 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”
  • 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, 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.

For more information on the basics of ABAC, you may want to check out this whitepaper on the New School of Thought.



Leave a Reply

Your email address will not be published. Required fields are marked *