When Should I Use an XACML Condition?

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.


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.


Related Articles

Meeting today’s dynamic authorization and access challenges: The Axiomatics story | Dynamically Speaking
Dynamically Speaking
For more than 15 years, Axiomatics has worked with companies worldwide to define and deliver solutions to the most complex authorization and access challenge. In...
Getting started with Zero Trust using dynamic authorization | Dynamically Speaking
Dynamically Speaking
Zero Trust. It’s everywhere. It’s a methodology that’s been around for years, and we are now seeing a significant uptick in the number of enterprises...
The case for dynamic authorization in banking and finance
Attribute Based Access Control (ABAC)
More than other organizations, banks, and financial institutions face the highest levels of scrutiny when it comes to how they protect critical assets and sensitive...