Attribute Based Access Control (ABAC) leverages attributes in combination with a set of policies to determine authorization decisions. A request is sent from an application, API gateway, or something else that acts as a Policy Enforcement Point (PEP). The Policy Decision Point (PDP) receives the request and applies it to the authorization policies that it has in place. While doing so, the PDP might leverage one or more Policy Information Points (PIP) in order retrieve additional attribute values.
Attributes are bags of values
The request that comes into the PDP is asking, “Can Alice edit record 123?” The policy in place says, “Employees can view any record,” and, “Managers can edit records in their own department.”
This means that the PDP will have to try to determine the values for a couple of attributes as it is evaluating the request against the policy. What is the user’s role? What is the user’s department? What is the record’s department?
But wait, this is ABAC and not RBAC. So why is there a role? Well, roles are still used, and in an ABAC world, a role is simply just another attribute.
So the PDP needs to resolve what role Alice has. Is she an employee, or is she a manager? Only managers are allowed to edit a record (and they have to be in the same department). But being an employee or a manager is not exclusive. A manager is probably also an employee, and with that, a user can obviously be both an employee and a manager. So how does the PDP handle that?
Introducing bags of values
This is where the power of XACML comes into play. Every attribute in XACML is considered a bag of values. Think of it as an array of values. In our example where the PDP is resolving the user roles through a PIP, it might do so by executing an LDAP search for example. This might result in multiple values (employee and manager), and these two values are placed in the bag. Depending on how the policy is configured, it is enough that the bag contains the correct value in order for that target or condition to evaluate to true and, in our case, get a Permit decision.
Handling bags – XACML functions
There are several functions within XACML that can operate on bags. The following lists some of the functions that may be useful when handling bags.
Handling single-valued bags
If it is explicitly known that an attribute will only contain one value it is possible to use a function to convert it to a single value. This is done by using the StringOneAndOnly function if operating on an attribute of datatype string.
Checking for values inside bags
There are other functions that operate on bags of values; one example is StringIsIn that returns true if one string value is in a bag of string values. This function exists for other datatypes too e.g. integer or boolean.
Measuring the size of bags
Sometimes knowing how many roles a user has could be interesting. In this case we want to measure how many values the role attribute has. To do so there is a function called stringBagSize(). As with the other functions, it exists for other datatypes.
Every attribute in XACML is considered a bag of values. This means that one attribute definition can hold multiple values. For example, in the case of a role attribute, the values it holds could be both employee and manager. Values are not unique which means that a bag could contain the same value twice.
The “Question of the Week” – an ongoing feature that will tackle technical and usage questions. We’ll have input from our sales engineers and customer relations teams. If you have a question to consider, please send it to email@example.com.