When and How Can I Express Negative Logic in XACML?

Brian Colaluca   ·   Thursday, August 18th, 2016

When authoring an access control policy, you may be creating a logical structure that calls for a negative expression. For example, you might be protecting a resource where access approval requires that the requestor not be a part-time employee [e.g. not(employeeType==partTime)].

Negative Logic in XACML

In the natural language scenario above, there are two options to go about expressing negative logic. The first is to place a range of finite values, such as true/false, part-time/full-time and construct your policies or rules as a case statement. For our scenario, the ALFA code may look something like this:

policy checkemployeeType{     apply firstApplicable     rule fullTime{         target clause employeeType=="fullTime"         permit     }     rule partTime{         target clause employeeType=="partTime"         deny     }     /**      * Optionally add a catch all case      */     rule other{         target clause ... // Here you'd have to define other checks     }     /**      * Catch all      */     rule defaultDeny{         deny     } } 

Note that in this case statement, if the employeeType attribute is equal to “partTime”, a deny is returned.

For the second option, a negative condition can be written. Since negative logic cannot be expressed in XACML targets, you will have to use a Condition within a rule instead. In this case, the ALFA code would look as follows: 

policy checkemployeeType{     apply firstApplicable     rule notPartTime{         condition not(employeeType=="partTime")         permit     } } 

In this example, if an employee held the attribute value of “partTime”, a permit would not be returned for this rule. This doesn’t mean a Deny would be returned.

Negative logic and multi-valued attributes

When we write the following statement in a Target:

• employeeType == “partTime”

We are actually stating that there must be at least one value for employeeType that is equal to “partTime”. This doesn’t mean it is the only value. If knowing the number of values is important, then use a condition to measure the number of values of the given attribute.

In a condition, writing not(employeeType==”partTime”) translates to: if none of the values of the employeeType attribute are equal to “partTime”.

Negative logic and the absence of values

Negative logic (or negative rules) can be tricky at times. Imagine for instance the following scenarios:

• Deny if employeeType == “partTime”
• Permit if not(employeeType==”partTime”)

In both cases, if the value is missing, then access would not be denied (rule #1) and access would be permitted (rule #2). Think about the presence of attribute values when defining negative logic.

Conclusion

If your policies request a negative expression, then you must use a XACML condition within a XACML rule. Otherwise, you will need to create an enumeration of all possible values for a case statement within a target.

Watch out for negative logic and missing attribute values, for instance:

• deny access if not (employeeStatus == active)

If the value for employeeStatus is missing, then access would not be denied. Think about implement a double check:

• deny access if not (employeeStatus == active)
• permit access if employeeStatus == active AND …

Further Reading 

eXtensible Access Control Markup Language (XACML) Version 3.0 (OASIS Standard)
ALFA for XACML v.1.0