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:
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:
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 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”.
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.”
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:
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.
None, secret, top-secret
None, secret, top-secret
X, Y, Z
X, Y, Z
A, B, C, D…
A, B, C, D…
Alice, Bob, Carol…
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.
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.
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.
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.
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:
Validating Our Policies
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:
Can Alice, who has a secret clearance, view a top-secret document?
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?
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?
Can Bob, who has a top-secret clearance and is a junior employee, edit a top-secret document?
Can Alice, who has a secret clearance and is a senior employee, edit a top-secret document?
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?
Can Bob, who has a top-secret clearance and is a junior employee, view top-secret information at 22:00?
Can Dan, who has a top-secret clearance and is a senior employee, view top-secret information at 22:00?
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:
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.