Page 1

TGIF XACML – What’s a XACML target?

Today’s Friday, the weather has been amazingly nice these past few weeks in Stockholm which is all the more surprising since September is on the slope down to darker, wetter, and colder days. The weekend ahead looks promising. I’ll be heading out to fellow colleague, Andreas’ summer house out in the archipelago.

The view from the Axiomatics offices towards Skeppsholmen and AF Chapman

The view from the Axiomatics offices towards Skeppsholmen and AF Chapman

But before I walk out the door, I thought I’d share a bit of XACML know-how to chew on over the next couple of days. In the training sessions we regularly give at Axiomatics, attendees often ask what a target is.

XACML Target


A target is an element of the XACML policy language. It can occur in policy sets, policies, and rules. The target is used to define their scope. The scope defines when the policy (set) / rule will trigger. For instance, for a rule to trigger and yield a Permit decision for managers in Greece, the target would have to contain two attribute matches:

  • role==manager, and
  • userLocation==Greece

There can be any number of matches. A match is always between an attribute (role, department, location, classification…) and a value. Matches can then be assembled together using logical operands (AND, OR).

Where can I use the target?

Targets can be used in:

  • Policy Set elements
  • Policy elements
  • Rule elements


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 user in Greece can read a document in the Greece region
 policy readDocument{
 	target clause actionId=="read" and resourceType=="document"
 	apply firstApplicable
 	rule allowReadIfCorrectRegion{
 		target clause userLocation=="Greece" and documentRegion=="Greece"

The above example will yield a Permit if and only if the user trying to read a document based in Greece is also based in Greece.


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

Previously in TGIF XACML…

Previous tidbits can be found here:


Ready to roll at the Cloud Identity Summit 2013, Napa #CISNapa

It’s already day 2 of the Cloud Identity Summit. Day 1 focused on workshops and so will day 2 along with bootcamps and interops including workshops on Microsoft Identity & the Cloud. Standards will be hailed like never before: OAuth 2.0, OpenID Connect, and SCIM will be represented in a standards-focused workshop while SAML, the star of the conference, will be highlighted in a hands-on demo of PingFederate by John Da Silva.
In the afternoon, I will have the privilege of completing the standards quintet as I take on my developer hat to talk about XACML, and the latest efforts around REST and JSON APIs / encoding for XACML 3.0. I will be uploading my slides later for those of you who want to check them out.
Happy CIS 2013!


Call out to a XACML Policy Decision Point (PDP) from PHP

Today, I have the pleasure to invite a fellow colleague, Patrick McDowell, to post on my blog. Today’s topic is around reaching out to other languages other than just Java and C# for XACML-based authorization. Today’s choice? PHP, naturellement as both Patrick and I are huge WordPress fans.

If you have been programming in PHP it is very likely that you have interacted with an external authentication service. For example Google and Facebook provide external authentication services that people can use to allow other providers to authenticate users for you using standard protocols such as SAML, OAuth, and OpenID.
Once a user has been authenticated, we then need to determine what that user is authorized to do inside of an application or service. This authorization logic can be externalized and defined using a standard language called XACML.
XACML stands for eXtensible Access Control Markup Language. The standard defines a declarative access control policy language implemented in XML and a processing model describing how to evaluate authorization requests according to the rules defined in policies.
Unlike the typical role-based security methodology used in many applications XACML authorization decisions are made in real time, and are made based on attributes about the user, the resource, and the context. For example a bank teller might have access to an account but should not be permitted to access his or her own account; the teller should not have access to accounts outside of his or her bank. XACML policies can be evaluated in real time to determine whether the teller should be permitted to access an account.
Additionally authorization decisions are made externally from the application, therefore security policy is not hardcoded into the application, which makes it easier for security policies to be changed. and Security administrators gain easier access to the authorization logic.
XACML requests include:

  • Subject
  • Action
  • Resource
  • Environment

And the XACML Policy Server (PDP, aka Policy Decision Point), will return:

  • Decision (Deny, Permit, Indeterminate, Not Applicable)
  • Status
  • Obligations or Advice

To keep this simple, we are simply going to ask the XACML Authorization server to confirm that:
Users with Teller Role (Subject), can View (Action), Bank Accounts (Resource)
This request in raw XACML looks like this:

<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:1.0:subject-category:access-subject" >
      <xacml-ctx:Attribute AttributeId="" IncludeInResult="true">
         <xacml-ctx:AttributeValue DataType="">teller</xacml-ctx:AttributeValue>
   <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="true">
         <xacml-ctx:AttributeValue DataType="">view</xacml-ctx:AttributeValue>
   <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:resource" >
      <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="true">
         <xacml-ctx:AttributeValue DataType="">bank account</xacml-ctx:AttributeValue>

The same request can be produced in PHP with SOAP like this:

$regReq = new stdClass();

$regReq->Version = "3.0";
$regReq->ID = "abcde1234";
$regReq->ReturnContext = true;
$regReq->Request = new stdClass();

$regReq->Request->Attributes = array();

$regReq->Request->Attributes[0]= new stdClass();
$regReq->Request->Attributes[0]->Attribute = new stdClass();
$regReq->Request->Attributes[0]->Attribute->AttributeId = "";
$regReq->Request->Attributes[0]->Attribute->AttributeValue = new stdClass();

$regReq->Request->Attributes[1]= new stdClass();
$regReq->Request->Attributes[1]->Attribute = new stdClass();
$regReq->Request->Attributes[1]->Attribute->AttributeId = "urn:oasis:names:tc:xacml:1.0:action:action-id";
$regReq->Request->Attributes[1]->Attribute->AttributeValue = new stdClass();

$regReq->Request->Attributes[2]= new stdClass();
$regReq->Request->Attributes[2]->Attribute = new stdClass();
$regReq->Request->Attributes[2]->Attribute->AttributeId = "urn:oasis:names:tc:xacml:1.0:resource:resource-id";
$regReq->Request->Attributes[2]->Attribute->AttributeValue = new stdClass();
$regReq->Request->Attributes[2]->Attribute->AttributeValue->any="bank account";
$regReq->Request->Attributes[3]= new stdClass();

The following PHP code creates the WS client and sends the request to the PDP.

ini_set('soap.wsdl_cache_enabled', 0); // Turn off the cache if you like
$client = new SoapClient("http://axiomatics:8080/asm-pdp/pdp?WSDL", Array("trace" => 1));
$result = $client->AccessQuery3($regReq);

The result returns a stdClass like this:

stdClass Object ( [Response] => stdClass Object ( [Result] => stdClass Object ( [Decision] => Permit [Status] => stdClass Object ( [StatusCode] => stdClass Object ( [Value] => urn:oasis:names:tc:xacml:1.0:status:ok ) ) ) ) )

The response to this request will return an object called Result with a field labeled Decision set to Permit, as well as other information about the request such as Obligations / Advice and information about the request.
To handle the response in PHP, all you need is the following code snippet:

if ( $result->Response->Result->Decision == "Permit") { 
 echo "Permit.. Tellers can view bank accounts";

The response does depend on the policy, and if the request did not find an appropriate target it is possible the response could be NotApplicable, which essentially means the Policy Decision Point (PDP), did not have enough information to make a decision.
The XACML Policy is also written in XML, and look like this in Raw XML:

<xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="" Version="1.0" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit">
        <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <xacml3:AttributeValue DataType="">bank account</xacml3:AttributeValue>
          <xacml3:AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"  AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="" MustBePresent="false"/>
        <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <xacml3:AttributeValue DataType="">view</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="">teller</xacml3:AttributeValue>
          <xacml3:AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"  AttributeId="" DataType="" MustBePresent="false"/>
  <xacml3:Rule RuleId="51179cb3-5319-4a35-a13e-ac1db27b5d93" Effect="Permit">
    <xacml3:Description>doctor can view medicalrecord</xacml3:Description>
  <xacml3:Rule RuleId="a2af1648-41c0-4843-ba4f-c1284d367957" Effect="Deny">

If you don’t like working with raw XML, Axiomatics offers an Eclipse Plug-in which uses a “Pseudocode” called ALFA (Axiomatics Language for Authorization) which makes writing these policies much simpler. It can be downloaded for free here.