To Axiomatics prospects and customers, standardization, or standards compliance, is of great importance and often one of the deciding factors in choosing Axiomatics over “homegrown” or vendor proprietary products.
A standards-based product will, among other things, allow the customer to source software from multiple, standard-compliant vendors and to reduce the business risk or “vendor lock-in.” When it comes to Attribute Based Access Control (ABAC), the only applicable standard is eXtensible Access Control Markup Language (XACML). This is the standard to which an organization should require compliance when looking at solutions for Externalized Access Management (the term that Gartner now uses) / fine-grained access control / Attribute Based Access Control.
As with any standard, there are different versions -or generations of it, and one should always look at, require, and use the “latest and greatest.” In the case of XACML, the latest version is 3.0, but it just so happens that a lot of vendors will still bid on RFPs based on dated support for version 2.0. Consequently, this blog serves to highlight the main features of XACML 3.0 as to better equip an organization in requesting vendor standards-compliance. If you need any of these features, and if you want a more future proof implementation, demand XACML 3.0 support!
Differences between XACML 3.0 and XACML 2.0
Note: this is not an exhaustive list of XACML 3.0 features, but a select set of key differences over the older XACML 2.0 standard.
Obligations are, simply put, orders returned with the access control decision (Permit/Deny access) with an additional (or several additional) order(s) to do something before implementing the decision. A simple example, supported in XACML 2.0, would be “write to logfile” (on access Deny for example).
With XACML 3.0, the Obligation is much more dynamic. It might say: “write to logfile [requesting user] tried to perform the action [attempted action] on resource [name of object]” where the words within brackets would contain the attributes applicable to that specific access request. In addition, XACML 3.0 introduced the concept of Advice to the standard: an instruction similar to the Obligation that might be ignored by the application enforcing the decision from the PDP.
Most if not all Axiomatics customers make use of Obligations and Advice today and the use cases range from “break-the-glass” (log elevated privilege, and/or render UI controls on access denied to enable request of elevated privilege) to simply providing user feedback.
Support for additional profiles
Implementing a profile is one of the means by which a XACML implementation can be extended (eXtensible). XACML 3.0 introduced profiles for Export Control (EC) regulations, Intellectual Property (IP) controls, standardizing attribute schemes, and more, for example allowing organizations with different XACML implementations to collaborate more easily. With XACML 3.0, the existing SAML profile was also enhanced.
Improved multiple decision schemes
The XACML 2.0 Multiple Resource Request was renamed Multiple Decision Profile (MDP) and enhanced. The MDP profile lets a requestor, typically the Policy Enforcement Point (PEP) ask several questions in a sort of batch mode, to which the Policy Decision Point (PDP) returns one answer containing multiple decisions. As such, the Multiple Decision Profile provides performance benefits as the communications overhead is reduced.
Note that a more scalable and performant solution is Axiomatics own “profile” Axiomatics Reverse Query (ARQ) which addresses similar use cases as the MDP, but which can implement access control even when the objects to be checked against are not fully known by the requestor.
New combining algorithms
There were new string functions too, but I think more importantly (at my discretion, yes?) there were changes to combining algorithms. “Permit-unless-deny” and its opposite “Deny-unless-permit” were introduced. These algorithms are fairly popular with customers today in dealing with some use cases.
With XACML 3.0 some existing combining algorithms were also enhanced.
XACML 3.0 brought a few performance improvements over the previous version (the next few paragraphs will be very specific):
Change matching priority in Target element
In XACML 2.0, the evaluation result of ‘Indeterminate’ had priority over ‘Not Applicable’ in target evaluation. This meant that if a match was found which was ‘Not Applicable,’ the PDP had to continue evaluating the rest of the target to find if anything might be ‘Indeterminate’. This was wasteful in cases where you’d already know that the target does not match because of a ‘Not Applicable’ result. With XACML 3.0 this priority changed, making evaluation both faster and more logically sound.
Separate Xpath based functionality and <AttributeDesignator>
With XACML 3.0 there is no longer a need to maintain XML representation of request attributes, and reconstructing XML for individual requests in multiple decision processing is no longer required.
JSON / REST support
Using JSON formatted access requests and a REST-like interface, also a feature of XACML 3.0, makes for an implementation that is independent of vendor SDK’s to manage the integration into a protected application. It also means, given the lightweight format for JSON, that the implementation is more performant. Lastly, the JSON format is more human readable compared to XML.
In XACML 3.0, JSON / REST is supported alongside with XML / SOAP: the Axiomatics PDP will have both a SOAP and a REST interface.
Note that support for JSON / REST was added a few years into the XACML 3.0 standard’s existence. Hence, make sure your vendor is current in their XACML 3.0 implementation; ask that they support XACML 3.0 with JSON / REST!
Stuck on XACML 2.0?
If you have an implementation based on XACML 2.0 and you are looking to migrate that to XACML 3.0, or if you are looking at XACML 3.0, but there are components within your infrastructure that are 2.0-compliant only, then Axiomatics is here to help: call your account manager today.
The “Question of the Week” – an ongoing feature that will tackle technical and usage questions. We’ll have input from our sales engineers and customer relations teams. If you have a question to consider, please send it to firstname.lastname@example.org.