Intro to Attribute Based Access Control (ABAC)

Axiomatics   ·   Monday, July 23rd, 2018

Access control has gone beyond simply need-to-know to include need-to-share authorization. Traditionally, the focus of authorization and access control has been on building barriers to sensitive data and only making it available to a select few. But that’s changed as companies want to get more from their data and make it really work for them. Authorization is now about facilitating user access to the right data under the right conditions. One approach is Attribute Based Access Control, or ABAC.

ABAC is a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes.

This diagram shows the methodology:

The eXtensible Access Control Markup Language (XACML) Standard

XACML is a standard that defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies. Vendors may implement ABAC through XACML.

The XACML policy language is as expressive as a natural language. For example, consider the following sentence:

 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 “building blocks” can be described using attributes:

Gathering Authorization Requirements

Now let’s define the authorization requirements for Jane Doe’s organization, which we will call The Organization.

The Organization has the following authorization requirements:
 

Identifying Required Attributes

Now, referring back to the authorization requirements we defined for The Organization in the previous step, we will create an attributes table.

The columns in our attribute table include:

• Short name: the user-friendly name of an attribute e.g. role or citizenship. It is the name usually displayed in editors and reporting tools.
• Namespace: the context to which the attribute belongs. Namespace follows the reverse domain name notation naming convention, like we use in Java. So, if we have com.organization.user, we can append a short name like role to create the fully qualified XACML attribute identifier com.organization.role.
• Category: a concept that comes straight from XACML that states an attribute always belongs to a category. There are 4 commonly used categories: subject, action, resource, and environment; they are defined in step 2 of our tutorial.
• Data type: a classification of the data. Attribute values can be of different types in XACML. The most commonly used are string, integer, and Boolean. There over a dozen data types available to choose from.
• Value range: an optional field to specify a pattern or range of provided values. Attribute values may be completely random (e.g. a user’s first name). Others belong to a fixed list of values e.g. state names or a pattern e.g. zip codes.

Authoring the Authorization Policies

Now we need to write our authorization requirements into attribute-based rules.

Original requirement: Any person must have the same clearance level or higher as the classification of the document he or she is requesting to view, must also be working on that project, be a current employee, and have finished the appropriate training.

Attribute-based rule:

Original requirement: Only senior personnel with a top-secret clearance can edit records that are classified as top secret or below if they are working on the project the record is part of, are a current employee, and have finished the appropriate training.
Attribute-based rule:
 

Original requirement: Junior personnel can edit a record if their clearance is greater than or equal to the classification of the record, if they are working on the project the record is part of, are a current employee, and have finished the appropriate training.

Attribute-based rule:

Original requirement: Junior personnel cannot access top-secret information between 20:00 and 6:00.
Attribute-based rule:  To write the next requirement as an attribute-based rule, we will use Abbreviated Language For Authorization (ALFA) language. ALFA offers a lightweight and compact syntax to write XACML policies programmatically.
The rule below implements the time-based access control mentioned in the original requirement:

Deploying the Policies

Now that we have finished creating our policy, let’s deploy it. Different implementations of XACML have different ways of deploying policies. At the very least, we need to make sure our policies our associated with a Policy Decision Point (PDP).
The PDP is responsible for evaluating the applicable policy and rendering an authorization decision.

Defining Policy Information Points (PIPs)

Policy Information Points (PIP) are the components in the ABAC architecture that store attribute values. PIPs come in a variety of form factors including LDAP directories, databases, and web services.

During the process of an evaluation, the PDP can call out to one or more PIP endpoints. For instance, a SQL database may communicate via Java Database Connectivity (JDBC).

It is important that we make sure our connection is configured to map information the PDP needs.

Configuring the user attributes

 Now we need to map the following attributes and the way we do it depends on the implementation of XACML we are using.
 ·     com.organization.user.role
·      com.organization.user.clearance
·      com.organization.user.status
·      com.organization.user.training
·      com.organization.user.project
·      com.organization.user.employeeId
 To map these attributes, all we need to know is:
·      The attribute we want to map, such as com.organization.user.role
·      The source table, in our case Users
·      The key attribute – username for employeeId
 

Configure the resource attributes

 We map these resource attributes as well:
·      com.organization.object.objecttype
·      com.organization.record.classification
·      com.organization.record.training
·      com.organization.record.project
·      com.organization.record.recordid
 

Validating Our Policies

Description

We can use access reviews to verify that the policies do deliver the desired use cases. The tests best suited for this are the PEP-PDP tests. For this, we develop independent, self-contained tests that do not use external data.
We also plan for tests that take into account the data sources (PIP). Tests can be used to verify that policies do not have side effects or gaps. In both cases, we make sure tests are always defined as a single unit test and then run together in a series or batch.

Use Case Tests

Here’s a table:

Testing with Policy Information Points (PIP)

We use tests with policy information points to validate that the overall solution has been correctly configured.

We evaluate whether or not:

• The authorization domain to which the PDP belongs is properly connected.
• Attributes are correctly mapped to the data.
• The PDP can properly communicate with PIPs.

Now let’s take the use case tests we defined and keep the key attributes only. This would include the user identifier, the resource identifier, and the action identifier as well as time of day, in our example.

We now will send XACML requests from a Policy Enforcement Point (PEP). The first use case test in Rule #1 in the table above would look like this:
 

Conclusion

In this tutorial, we have reviewed the fundamentals of Attribute Based Access Control and demonstrated how it offers dynamic, context-aware and risk-intelligent access control while going through an example. 

For more information on Attribute Based Access Control, visit how to Protect critical assets and enable information sharing.