Page 1

TGIF XACML – What’s a XACML condition?

It’s that time of the week when the creative juices go south and the urge to relax hits all-time records. And I know you are all craving for some XACML goodness before you head out for the weekend. After all, just a spoonful of XACML makes the… Uh who am I kidding? Let’s get on with this new episode of TGIF XACML. Today, let’s focus on a XACML condition.


A condition is an element of the XACML policy language. Unlike targets, it can only occur in rules. The condition is used to further define the scope of XACML rules. The scope defines when the rule will trigger. Both the target and the condition therefore help define the scope of policy sets, policies, and rules.

Here’s the OASIS XACML standard’s definition for conditions.

Condition represents a Boolean expression that refines the applicability of the rule beyond the predicates implied by its target. Therefore, it may be absent.

Where can I use a condition?

Conditions can only be used in:

  • rules

Use conditions to define a stricter scope on rules such that they only apply to specific scenarios. Bear in mind that conditions will only be triggered once all parent targets (in the containing rule and parent policy (set)) have been processed.

If we have targets, why use conditions?

Good question! I’m glad you asked. Targets are bit like the simple version of a condition. Targets can only be used to compare an attribute to a value e.g. role==manager. As a result, it’s impossible to express relationships using targets e.g. Permit if the condition, bright and bold. Conditions, by contrast to the simpler target, can use any of the functions available in the XACML standard and can compare any number of attributes one to another.

In other words, any time you have to implement relation-based access control, use a condition. Some examples include:

  • Users cannot approve a purchase order they created themselves (Deny if userId==purchaseOrder.creator)
  • Doctors can view the medical records of patients to whom they are assigned (Permit if userId==patient.assignedDoctor)

Other instances where you want to use XACML Conditions is when the attribute values need some kind of manipulation or combiniation. For instance if you want to compare the sum of two numbers to a given limit, then you will need to resort to a condition such as:



The following uses the ALFA syntax. You can download the plugin for free from the Axiomatics website. Check out YouTube for a video example.

 * A manager in purchasing can approve a transaction in the same region
 policy readDocument{
    target clause actionId==&quot;approve&quot; and resourceType==&quot;transaction&quot;
    apply firstApplicable
    rule denyDifferentRegion{
        condition not(userLocation==transactionRegion)
    rule allow{
    	target clause userRole==&quot;manager&quot; and department==&quot;purchasing&quot;

The above code implements the example used in a previous post on combining algorithms.

In the above example, note the use of:

  • a target: target clause userRole=="manager" and department=="purchasing"
  • a condition: condition not(userLocation==transactionRegion)



I hope this simple example helps to understand conditions in the XACML policy language. Stay tuned for more TGIF XACML tidbits.

Previously in TGIF XACML...

Previous tidbits can be found here:


Coarse-grained vs. fine-grained access control – part I

A few weeks ago, Baljinder Wadhwa, a consultant at HP, started an interesting thread on coarse-grained vs. fine-grained access control trying to figure out what the differences were between the two. His question generated a high level of great answers that went in different directions. This post aims at summarizing those answers, bringing in my own view, and producing a structured answer to Baljinder’s question. Here goes…

Vocabulary definition

  • Coarse: (1) composed of relatively large parts or particles <coarse sand> (2) : loose or rough in texture <coarse cloth>
  • Fine: (1) very thin in gauge or texture (2) : not coarse <fine sand> (3) : very small (4) : keen <a knife with a fine edge> (5) : very precise or accurate <a fine adjustment> <trying to be too fine with his pitches>

Definitions from the Merriam-Webster
The definitions start to hint at what the differences might be: fine-grained access control will work on smaller items whereas coarse-grained access control will work on larger items.
Granularity can apply to the message being intercepted or the information being considered for access control. Ultimately, the rules being define will allow for more or less granular AC. Examples:

  • Coarse: Employees can open the door.
  • Fine: Employees based in the US can open or close the door during office hours.
  • Finer: Employees in the Engineering department and based in the US can open or close the door during office hours if they are assigned to an active project.

A little history of access control

In application security, there are grossly speaking 3 types of access control:

  • Access control lists (ACL): with access control lists, once a user is authenticated, that user is allowed to access an application or not depending on whether that user’s id is on a list of authorized users (white list) or blocked users (black list). This mode is either all-in or all-out. It is extremely coarse-grained from that perspective. It is also coarse-grained in the sense that it only considers one dimension, that of the user, ignoring resources, actions, and context. However, it is extremely fine-grained in the sense that it becomes a user-specific rule. In the previous examples, John is the user id that would be on the ACL for the open door action.
  • Role-based access control (RBAC): sometimes, though, it is not who you are but rather what role(s) you embody. For instance, a person might be allowed to open a door. That right (or permission) is granted because that person has the role employee, not because of who they are. Typically, in RBAC, a user can have multiple roles to which different permissions can be granted. Take wordpress for instance, the popular blogging platform. WordPress lets users define roles and associate permissions to roles and then roles to users therefore transitively granting users permissions. But roles have their limits too. How do you express other conditions or parameters? What if you want to express a permission of the following form: “only employees can open the door between 9AM and 5PM”. With RBAC, you can express employee + open door. But you cannot really express the time constraint. In addition, what if you want employees who can only close doors? You would need to define employee_open and a employee_close role. This leads to role explosion.
  • Attribute-based access control(ABAC): to address this, one needs to be more discriminate, finer in terms of what information is considered to define a rule. Instead of defining permissions based on roles only, one should be able to use attributes. Attributes are any bit of data, or label, that describes a user, resource, target, object, environment, or action. Anything from an apple, its color, and weight to a person eating that apple, the location of the apple… With ABAC, you can mix and match attributes to define extremely targeted (fine-grained) rules e.g. employees can open the door between 9AM and 10AM or close the door after 5PM if and only if the employee belongs to the ‘door opener’ group.

Standards for access control

In the previous paragraph, we looked at some broadly used and accepted access control models: ACL, RBAC, and ABAC (yes, access control is for acronym lovers). Let’s check out standards that back these models.

  • ANSI INCITS 359-2009 RBAC Role-Based Access Control: this standard defines role-based access control and its model.
  • XACML: this OASIS-driven standard defines a policy language, request/response protocol, and architecture that implement ABAC.

The NIST has a webpage dedicated to RBAC which summarizes extremely well the different RBAC standards existing and their variations / applicability.

In addition to the ANSI RBAC and the OASIS XACML standards, there are standards for ACL but these tend to be OS-specific.

Of all the standards out there, XACML is the one providing the finest granularity.

Defining access control granularity

The granularity of an access control framework can be defined from two different angles:

  • the expressiveness of the grammar used to express access control rules:the more flexible a grammar and the more information it can cater for, the finer grained the resulting access control will be. XACML can consider attributes about users, resources, actions, and the environment. This makes it very fine-grained. RBAC implementations typically focus on the user role and the target application therefore losing a bit of granularity since it won’t be able to make access control decisions based on actions, other subject attributes, or the context.
  • the ability of the ‘agents’ to see more or less information: in order to make fine-grained access control decisions, there is a need for agents or interceptors to be able to inspect business messages flowing through them. If, for instance, an agent can only see the URI of an HTTP message and the user principal name, then it can (most likely) only make decisions based on that. On the other hand, if the agent is capable of inspecting the entire message, including all HTTP headers plus the payload of the message, then more fine-grained AC requests can be generated. This is why there are firewalls which typically look at TCP packets, XML gateways which look at SOAP/REST messages, and many other types of gateways / interceptors in between. Interceptors can be business app-specific e.g. interceptors for Sharepoint or SAP which enable fine-grained access control.

In a second instalment, I will focus on the issues of scale around granularity of access control. I will also list some product categories and vendors that address different levels of granularity. Stay tuned!


XACML 101 – a quick intro to Attribute-based Access Control with XACML


XACML: eXtensible Access Control Markup Language.



  1. is XML: you can actually read and write XACML with your favorite text editor (not that I would recommend writing XACML that way).
  2. is human-readable and verbose enough for users to get an understanding of what it’s doing
  3. belongs to the OASIS family of standards. You can download the latest standard material here.
  4. is eXtensible: you can add profiles to cater for specific scenarios e.g. a profile for hierarchical resources, for role-based access control, for export control…
  5. is about access control: authorizing who can do what when and how
  6. implements ABAC, attribute-based access control

What’s ABAC?

ABAC stands for attribute-based access control. It is a natural evolution from role-based access control which itself is a natural evolution from access control lists.

Access Control History in a nutshell

In a nutshell

Once upon a time there were access control lists. Once a user authenticated, its identity was known and could be used in such lists. Think of clubs and VIP lists. If you appear on a VIP list, the bouncer (enforcer) will let you in. It doesn’t matter what your role in life is…

Then someone realized that the right to do something (authorizations, entitlements…) should rather be linked to a role. Bus drivers can drive public transports buses. The role is bus driver. It is simpler and safer to use a role as an abstraction away from the user. It effectively decouples user lists (which is really about authentication) from entitlements (the right to drive a bus in that case). Entitlements can be more efficiently managed.

But today’s environments are so complex and so rich that it is no longer enough. Take the bus analogy again. There are many different buses, different routes, different schedules. What if you want to express the following access control rules:

Bus drivers can only drive buses between 9AM and 5PM on buses they are qualified to drive. With RBAC, you would have roles e.g. small-bus-morning-driver, medium-bus-morning-driver, big-bus-morning-driver… You get the picture. In this case, the size of the bus (small, medium, big) and the time of the day (morning, evening, night) are examples of attributes one wants to use to express finer-grained rules. This is where ABAC comes in.

The evolution from RBAC to ABAC is very well explained in the following presentation:

Attribute based access control (ABAC): a new access control approach for service oriented architectures, by Eric Yuan, Jin Tong, Ottawa New Challenges for Access Control Workshop, 27 April, 2005. View here (mirror).

What does XACML bring to the table?

XACML brings 3 things:

  1. an architecture: this helps understand where XACML fits in an existing architecture and how & where access control can be enforced
  2. a policy language: means to express access control rules in a standardized, interoperable, way. “Children can eat ice cream”
  3. a request / response language: the means to ask questions and to receive an answer in a standardized way: Can naughty children eat ice cream? No, they cannot.

Architecture overview

The XACML architecture contains the following points:

  1. the Policy Decision Point (PDP): the core of the architecture where policies are evaluated and decisions are reached. The PDP is to XACML what the Supreme Court is to US law.
  2. the Policy Enforcement Point (PEP): the integration items which can be anywhere in an application architecture. PEPs are extremely versatile depending on where they enforce access control. The PEP is to XACML and the PDP what police officers and judges are to courts and the law
  3. the Policy Retrieval Point (PRP): this is the point through which policies are read from the policy repository. Policy retrieval points ensure the independance of XACML from specific storage mechanisms. The PRP is to XACML what a legislation is to a legal framework: the place where law is written and maintained.
  4. The Policy Information Point (PIP): in ABAC and XACML, there is a need for attributes. Attributes are there to describe users, services, resources, actions, and the environment. Policy Information Points are attribute stores. They can be any format and located anywhere. PIPs are to XACML what the DVLA, the set of police records, the census bureau, etc… are to a nation and its citizens.
  5. The Policy Administration Point (PAP): this is where you manage your policies.

None of the keywords are actually XACML-specific. PDP, PEP, PRP, and PIP are all defined in RFC 2904: AAA Authorization Framework.

Sample policy

I wrote the following using Axiomatics’s Policy Administration Point, part of their Axiomatics Policy Server. It uses XACML’s latest draft, XACML 3.0. More on XACML 3.0 can be found in Gerry Gebel’s XACML 3.0 presentation given at Kantara.

<xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="child-eat-icecream" Version="1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
<xacml3:Description>Define which children can eat ice-cream</xacml3:Description>
 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
 <xacml3:AttributeValue DataType="">eat</xacml3:AttributeValue>
 <xacml3:AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"  AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="" MustBePresent="false"/>
 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
 <xacml3:AttributeValue DataType="">ice cream</xacml3:AttributeValue>
 <xacml3:AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"  AttributeId="food" DataType="" MustBePresent="false"/>
 <xacml3:Rule RuleId="children-eat" Effect="Permit">
 <xacml3:Description>let any child eat ice cream</xacml3:Description>
 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
 <xacml3:AttributeValue DataType="">child</xacml3:AttributeValue>
 <xacml3:AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"  AttributeId="urn:org:apache:tomcat:user-role" DataType="" MustBePresent="false"/>
 <xacml3:Rule RuleId="naughty-children-punish" Effect="Deny">
 <xacml3:Description>do not let naughty children have ice cream</xacml3:Description>
 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
 <xacml3:AttributeValue DataType="">child</xacml3:AttributeValue>
 <xacml3:AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"  AttributeId="urn:org:apache:tomcat:user-role" DataType="" MustBePresent="false"/>
 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
 <xacml3:AttributeValue DataType="">naughty</xacml3:AttributeValue>
 <xacml3:AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"  AttributeId="behavior" DataType="" MustBePresent="false"/>

Sample request and response

Request: can a child eat ice cream?

<xacml-ctx:Request ReturnPolicyIdList="true" CombinedDecision="false" xmlns:xacml-ctx="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">
<xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
<xacml-ctx:AttributeValue DataType="">eat</xacml-ctx:AttributeValue>
<xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<xacml-ctx:Attribute AttributeId="urn:org:apache:tomcat:user-role" IncludeInResult="false">
<xacml-ctx:AttributeValue DataType="">child</xacml-ctx:AttributeValue>
<xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<xacml-ctx:Attribute AttributeId="food" IncludeInResult="false">
<xacml-ctx:AttributeValue DataType="">ice cream</xacml-ctx:AttributeValue>

Response: yes he can!

<xacml-ctx:Response xmlns:xacml-ctx="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
 <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

Thank God for XACML!