Page 1
Standard

The world’s fastest XACML engine

In the last few months, I have been reading statements from a wide variety of vendors / open-source XACML implementations that they have the world’s fastest 100% XACML standards-based engine.

This reminds me of heated debates that involved national pride and engineering feats when the French and Japanese were head-to-head in designing the world’s fastest trains. And the Chinese have since then caught up. The Wikipedia article is a trove of trivia when it comes to speed and how records were achieved (or what they actually mean). In the table summary, I can spot quite a few ‘current world record’ labels… If by the time you finish reading the article, your head is not spinning one way or the other, then you’re ready to take on the ‘fatest XACML engine’ claim.

So who’s the fastest? How can one claim to be the fastest? After all what does it mean? Don’t you need to compare to other engines? To date, only one such comparison has been done by academics on open-source engines [1].

In pure absolute terms, the fastest engine is the one that can process the most XACML access control requests in a given time, usually brought down to a second for comparison purposes. The statement however should raise a few questions:

  1. Are these live access control requests?
    The requests being sent are live requests. There is no caching involved (no decision caching, no attribute caching). The PDP engine is processing each and every request and is returning a decision.
  2. Are the requests actually using XACML?
    The request should be XACML-conformant. Sadly, not many implementations out there claim to conform with the XACML 2.0 standard or XACML 3.0 specification. Check that the solution you go for does. If a solution manages high levels of access control requests by cutting corners or not respecting the standard, the solution will fall apart when scaling or when evolving towards new, more demanding scenarios.
  3. How are the requests being transported?
    The form factor of the request: in a performance test or benchmark used to create those figures, any form factor can be used. If one uses XACML expressed in its XML form inside a SAML assertion inside a SOAP message, I would bank the figures would rate poorly. SOAP’s middle name is not ‘Speedy Gonzales‘. Typically, a performance test would therefore be achieved using XACML’s representation in code (Java, C, C#, depending again on the implementation. SunXACML uses Java).
  4. Do the requests & policies used in benchmarks accurately represent business complexity?

    The request and the policies should be meaningful and represent a varying level of complexity. When you are presented with a benchmark, ask to see how the results were computed and real-world complexity was simulated. A fellow vendor likes to use his kids in examples. I don’t have any so I’ll use my niece as an example – she can splutter out ‘no’ so fast that I’d reckon she might well be the fastest decision engine in the world. True, she’s not XACML-conformant and besides she’s got a deny-all policy. That’s not very useful. So remember, ask how complex a request is and how large the policy set being evaluated is.

  5. What is the architecture being used?
    Performance can be impacted or enhanced depending on several architectural considerations: how many engines are used? How are engines combined together? Can engines scale horizontally? Vertically?
  6. Do performance figures represent real production data?
    Have they simply been estimated in a lab environment? In the end, performance needs to be proven in real-time and in real-world use case scenarios. What actual experience and evidence from production systems have you been given?

It’s easy to claim one is the fastest. But one should tread carefully and check the face value of any such statement. Ask to understand how performance levels are achieved. Ask how such performance levels can be sustained and made resilient to different attacks or simply highly volatile levels of traffic.

The good news is XACML provides a very clean and decoupled architecture that makes it easy to address these concerns. It’s just a matter to make sure whether the solution you go for does respect the XACML architecture. As an architect at Axiomatics, I’m proud to say we do. And that’s business sense. Respecting the standard is a first stepping stone to a future-proof solution but it is not enough: performance is critical. Our products reach extremely high levels of performance through years of research & innovation – and we prove this on a daily basis in the world’s largest deployments – be it in terms of users, services, data, or simply throughput.

PS: don’t forget to come visit us at Gartner in San Diego later this month where we will illustrate fine-grained access control in the cloud with best-of-breed vendors Radiant Logic (attribute virtualization) and Layer 7 (SOA security – see their flyer here: http://www.layer7tech.com/beachparty/).

[1] Fatih Turkmen and Bruno Crispo. 2008. Performance evaluation of XACML PDP implementations. In Proceedings of the 2008 ACM workshop on Secure web services (SWS ’08). ACM, New York, NY, USA, 37-44. DOI=10.1145/1456492.1456499 http://doi.acm.org/10.1145/1456492.1456499

Standard

XACML 3.0 wins award at the European Identity Conference 2011 #EIC11

Today was a great day at EIC 2011 where Axiomatics is currently demoing its fine-grained authorization capabilities based on the latest version of the XACML standard, XACML 3.0.
It ended with the usual ceremony awards where Tim Cole et al. handed out awards to various projects in the identity space (cloud security, IAM, entitlements management).
A special award was handed to the XACML Technical Committee for its outstanding work on the latest version of XACML, XACML 3.0. Hal Lockart of Oracle and co-chair of the TC stepped up to accept the award and thanked the entire TC for a great group effort. He also thanked the editor of the XACML 3.0 specification, Erik Rissanen, CTO Axiomatics, for leading the effort and major contributions.
XACML 3.0 brings many new things to the table among which advice, variables inside obligations, and perhaps close to Erik’s heart, delegation. More on new features of XACML 3.0 here.
The XACML TC will be hosting a free webinar on XACML in early June. Details can be found here.

Hereafter the video of the award ceremony and Hal going on stage:

Standard

XACML 102 – Pimp my XACML – Part III: XSLT, Ajax, and stats

In a previous installment of ‘Pimp My XACML’, we illustrated how a bit of XSLT magic could actually change the structure of a XACML policy to convert into another document such as an HTML page be it XML-compliant or not.

Today, we will push the tricks further and add a bit of AJAX magic as well as some basic statistics regarding our policy.
For those of you who missed on the previous episode, check it out here. It describes how to run the samples using ant and xalan.

Adding some stats to the XSLT

This is the easy bit. All we need to do is count the number of items that match a certain pattern and display that neatly in a list inside a div for instance. The XSLT to do this is as follows:

            <div class="stats">
               <ul>
                  <li>
                     Number of policy sets:
                     <xsl:value-of select="count(//xacml3:PolicySet)" />
                  </li>
                  <li>
                     Number of policies:
                     <xsl:value-of select="count(//xacml3:Policy)" />
                  </li>
                  <li>
                     Number of rules:
                     <ul>
                        <li>
                           Rules yielding PERMIT:
                           <xsl:value-of select="count(//xacml3:Rule[@Effect='Permit'])" />
                        </li>
                        <li>
                           Rules yielding DENY:
                           <xsl:value-of select="count(//xacml3:Rule[@Effect='Deny'])" />
                        </li>
                        <li>
                           Total:
                           <xsl:value-of select="count(//xacml3:Rule)" />
                        </li>
                     </ul>
                  </li>
               </ul>
            </div>

This example is of course valid for XACML 3.0 policies but can be easily adapted for XACML 2.0 policies and for that matter any other XML document. The key element here is

<xsl:value-of select="count(//xacml3:Rule[@Effect='Deny'])" />

We use the count function of XSLT as defined here and apply it to the pattern we are interested in, here the number of Rules, no matter their level of nesting, which contain an Effect attribute with the exact text value of ‘Deny’.

Visualizing XACML in an AJAX tree

Credits go to willCode4Beer whose tutorial I followed to get the AJAX example online. To get a similar tree, simply follow instructions here.

Before you continue, you will need to download some DOJO libraries. In particular, this example was built using the now antiquated Dojo 0.4.1 kitchen sink which is still fortunately downloadable from the DOJO archives. You will need to follow instructions on where to copy the JS files. Ultimately you should end up with a structure similar to the following:

|-- axiostrator.xml
|-- in.xml
|-- scripts
|   |-- dojo.js
|   `-- src
|       |-- AdapterRegistry.js
|       |-- Deferred.js
|       |-- DeferredList.js
|       |-- ... additional files skipped for brevity's sake
|-- style.css
`-- xout.html

You now need to add the JS definitions to use the DOJO tree widget. To do so, edit your XSLT file in order to include the following:

            <script type="text/javascript">
               var djConfig = { isDebug: true };
            </script>
            <script type="text/javascript" src="scripts/dojo.js">
               /* Load Dojo engine */
            </script>
            <script type="text/javascript">
               dojo.require("dojo.lang.*");
               dojo.require("dojo.widget.Dialog");
               dojo.require("dojo.widget.Tree");
               dojo.require("dojo.widget.TreeContextMenu"); 
            </script>

And that’s it. Now all that need be done is to add the relevant class information to ‘bind’ the HTML div elements to the actual JS that will render the tree:

            <div class="tree">
               <dl class="dojo-TreeContextMenu" id="treeContextMenu">
                  <dt class="dojo-TreeMenuItem" id="ctxMenuAdd" caption="View XACML" />
               </dl>
               <div class="dojo-Tree" menu="treeContextMenu">
                  <xsl:apply-templates />
               </div>
            </div>

The entire resources needed for this exercise can be downloaded here: