When Should I Use an XACML Condition?

Axiomatics   ·   Tuesday, May 10th, 2016

XACML Targets

Targets are an easy way to define the scope of an authorization policy. Targets can be used in all three XACML structural elements (policy set, policy, or rule).

Targets always follow an AND / OR / AND structure. For instance, with a target, it is simple to implement citizenship == Norwegian AND department == Sales OR citizenship == Canadian. With targets, you can only use simple comparison functions that compare an attribute to a single value e.g. citizenship == Norwegian.

XACML Conditions

Conditions are more powerful in the sense that they do not have a pre-set AND / OR / AND structure. They can also use any XACML function so long as the final outcome of the Condition is a boolean value.

For instance, you could implement the following using a condition:

• Permit if the user’s age is an even number
• mod(integerOneAndOnly(user.age),2)==0

The mod() function is a function that cannot be used in a target so you have to use a condition. Because conditions are so much more powerful, they require more care. And it’s easier to make mistakes.

When Should I Use a XACML Condition?

There are a few use cases when conditions are important:

The Relationship

The main driver for using conditions is the ability to implement relationships. Relationships are in fact one of the main drivers for XACML and ABAC.

For instance:

• Indirect relationship: user.department == doc.department
• Direct relationship: user.id == doc.owner

Most reasons for using a condition will be due to a relationship.

The Negative Use Case

If you want to have a policy that says “Permit if the user is not Canadian”, then you would need to implement citizenship != ‘Canadian’. However, XACML does not have a ‘not equal’ function. To achieve this functionality, you need to use a condition containing not(citizenship==’Canadian’).

The Whitelisting / Blacklisting

Sometimes, you want to check whether a user is on a list e.g. a VIP list or a banned user list. To do so, you also need to compare two attributes. This is a special form of a relationship this time using stringIsIn:

• stringIsIn(stringOneAndOnly(user.uid), vipList)

Handling Messy Data

Sometimes the attribute values we get back are not quite clean and require some massaging, for example using lower case or prepending / appending data. XACML provides functions to do some level of data normalization and these functions can be used inside conditions.

Conclusion

Conditions make XACML very flexible.

There are many possibilities conditions enable. Can you think of one yourselves? Tweet us to discuss @Axiomatics. With conditions, XACML policies become extremely expressive and can cater to many authorization scenarios.