Download your copy of our State of Authorization: Playbook Edition Get it now »

Intro to Attribute Based Access Control (ABAC)

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:

Intro to Attribute-Based Access Control - ABAC

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:

Jane Doe wants to view a confidential document at work during regular business hours.

 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:

Term Definition Examples
Subject Who or what is demanding access to an information asset. Roles, group memberships, the department/company to which the user belongs, management level, certifications or competencies, user ID
Action Action the subject wants to perform. Read and write are common values. More complex scenarios, like a bank transfer, may use multiple attributes such as “action type=transfer” and “amount=$500”.
 
Resource The information asset or object impacted by the action. For banking, the resource may be “debit account=<your account number>.” In law firms, a resource could be a document and an attribute could be “case matter = 100.”
Environment The context in which access is requested. Current time, location from where access is requested, client type (PC, smartphone, etc.), type of communication channel (I.E. protocol or encryption strength)

 

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:
 

  • 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.
  • 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.
  • Junior personnel cannot view top-secret information between 20:00 and 6:00.

 

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.

 

com.organization.user
Short name Namespace Category Data type Value range
role Subject String Junior, senior
actionId com.organization.action Action String View, edit
objectType com.organization.object Resource String Record
clearance com.organization.user Subject String None, secret, top-secret
classification com.organization.record Resource String None, secret, top-secret
status com.organization.user Subject String Current, terminated
training com.organization.user Subject String X, Y, Z
training com.organization.record Resource String X, Y, Z
project com.organization.record Resource String A, B, C, D…
project com.organization.user Subject String A, B, C, D…
employeeId com.organization.user Subject String Alice, Bob, Carol…
recordId com.organization.record Resource String 123,456,789…

 

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:

A user with role==”junior” OR role==”senior” AND user.clearance>=record.classification can actionId==”view” on objectType==”record” if classification==”secret” AND user.project == “record.project” AND status==”current” and record.training is in user.training

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:
 

A user with the role==”senior” can actionId==”edit” if user.project ==record.project AND user.clearance>= record.classification AND status==”current” and training == “training”

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:

A user with the role==”junior” can actionId==”edit” if user.project==record.project AND user.clearance>=record.classification AND user.status==”current” AND user.training==record.training

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:

Description Expected Result
Rule #1   
Can Alice, who has a secret clearance, view a top-secret document? Deny
Can Bob, who has a top-secret clearance, view a top-secret document that requires completion of Training A, even though he has not completed Training A? Deny
Can Carol, who has a secret clearance, view a secret document related to her project that she has completed the requisite training for, while she is a current employee? Permit
Rule #2  
Can Bob, who has a top-secret clearance and is a junior employee, edit a top-secret document? Deny
Can Alice, who has a secret clearance and is a senior employee, edit a top-secret document? Deny
Can Dan, who has a top-secret clearance and is a senior employee, edit a top-secret document related to her project that he has completed the requisite training for, while he is a current employee? Permit
Rule #3   
Can Bob, who has a top-secret clearance and is a junior employee, view top-secret information at 22:00? Deny
Can Dan, who has a top-secret clearance and is a senior employee, view top-secret information at 22:00? Permit

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:
 

{
        “Request”: {
            “AccessSubject”: {
                “Attribute”: [
                    {
                        “AttributeId”: “com.organization.user.role”,
                        “Value”: “Senior”
                    },
                    {
                        “AttributeId”: “com.organization.user.clearance”,
                        “Value”: “0_Secret”
                    },
                    {
                        “AttributeId”: “com.organization.user.employeeId”,
                        “Value”: “Alice”
                    }
                ]
            },
            “Resource”: {
                “Attribute”: [
                    {
                        “AttributeId”: “com.organization.record.status”,
                        “Value”: “1_TopSecret”
                    },
                    {
                    “AttributeId”: “com.organization.object.objectType”,
                        “Value”: “record”
                    }
                ]
            },
            “Action”: {
                “Attribute”: [
                    {
                        “AttributeId”: “com.organization.action.actionId”,
                        “Value”: “View”
                    }
                ]
            },
            “Environment”: {
                “Attribute”: []
            }
        }
}

 

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.

Archived under:
  Join us on LinkedIn for more insights
About the author

The world’s largest enterprises and government agencies continually depend on Axiomatics’ award-winning authorization platform to share sensitive, valuable and regulated digital assets – but only to authorized users and in the right context.