The eXtensible Access Control Markup Language – or XACML offers a standardized way to provide granular and scalable authorization solution across the enterprise application board by defining an elaborate and strict specification that applications’ authorisation policy must follow. On the other hand the model is extensible enough – as the name suggest – to offer the flexibility that is required by the heterogeneous nature of the enterprise application and use cases.
So the question is just how extensible is XACML? In this blog post we will elaborate a bit further on the designated extension point of the XACML standard and try to demystify the art of tailoring the model to fit any application specific need.
XACML extension points
The XACML Core Specification version 3.0 has a section named XACML extension points, which list all the points where the XACML model and schema can be extended with new semantic. The section is marked as non-normative, which means that the implementer is not obliged to support this feature to stay compatible with the standard; therefore support for these extensions might vary among different implementations. The aforementioned list is hereby presented:
- SubjectCategory (deprecated XACML 2.0 stuff which should have been removed)
The specification offers no more guidance on the why and how questions of these extension points other than making a reference to the corresponding sections that defined these elements. Let us dig deeper and try to break them into different groups according to how they influence the semantic and flow of the policy evaluation.
Extending with new data
These extension points can be used to add data with new semantic to the model.
The XACML specification has a section on Category identity, which list all normative ids that all XACML implementation must support and applications can utilize. These include also some not-so-popular categories such as
urn:oasis:names:tc:xacml:1.0:subject-category:codebase for XACML 2.0 compatibility purpose.
While the standard has tried to generalized the domain of authorization attribute in 4 general categories namely access-subject, resource, action and environment and all application should really try to stick with that, there is sometimes a valid need to add some domain-specific expressiveness to the model by using a different way of classifying attributes.
It is worth noting that Attribute Category offers an out-of-the-box way of dividing the authorization space into different dimensions. There is nothing wrong with putting all attributes in the same category and forget all about the concept. However such single-dimension space forces the policy modeller to work on a flat structure and, as a result, makes the authorization process much harder to be understood from a high level perspective.
The attributes are like currency in the XACML world. The more you have the richer your policy can be in terms of expressiveness. It just natural that every application will define their set of attributes that can later be used to implement their authorization policies.
The set of standard attributes defined by XACML is aimed to be generic. For instance the standard subject-id in the access-subject category can certainly be used to represent just any subject-id attribute provided by the specific application. Nonetheless each organisation and application has their own concept of user identity so it is often the more common case that each identity will be defined as a separate attribute such as employee-id, ldap-id, active-directory-id to better model the real operation scenario.
XACML provides good support for all the as many common primitive types as a policy author might need. Generally speaking requirement that can be met by defining new data types can be met also by a combination of extending XACML functions and creating proper attribute finders. Nevertheless if your application attributes makes extensive use of a certain data format defining new data type will result in a cleaner model.
One thing to keep in mind is that new XACML data type requires defining certain new corresponding functions. For instance a new type called my-datatype will required the definition of the function named
An example of a useful custom data type that can be defined is the datatype to represent geographic coordinates. Such data type can have the format of [longitude; latitude] and support several functions to different aspect of geographic location.
Although not strictly qualified as data in the XACML world, the status code does convey certain information that can affect the behavior of the calling application. Appendix B Section 8 in the specification defines four status codes and their semantics, which need to be supported by any XACML implementation, and which any application can expect to appear in an evaluation result. One valid use case where a custom status code defined by the user can be supported is for an attribute finder to return status codes that are specific to the type of error happened.
AdviceId and ObligationId
These two are not extensions in the strictest sense since the standard does not defined any out-of-the-box Advice or Obligation for implementor to support. The semantic of these are completely in the application space and it is the users’ responsibility to define it within the policy modeling process and at the enforcement point.
Extending with new operation
MatchId and FunctionId
MatchId and FunctionId fall under these category as they provide a way to add new ways to transform and evaluate data in XACML. The use might need to do this in the context of extending with a new XACML data type or in the case of adding a new operation that operate on the old primitive types.
If we continue with our example of the attribute type called geographic-coordinate in the previous section one can make use of a new function to identify whether a certain coordinate belongs to a certain region, which is useful for modelling location-based policy.
Extending with new evaluation flow
PolicyCombiningAlgId and RuleCombiningAlgId
The evaluation flow can be extended by defining new combining algorithms, which are identified by the PolicyCombiningAlgId and RuleCombiningAlgId elements. Combining algorithm is a special algorithm that dictate the flow of evaluation given a set of rule or a set of policy. The need for extending this flow varies with the use cases complexity. Most use cases only require a Access-Control-List kind of behavior while there might be a few way of modeling that might require more sophisticated flow chart.
An example of a custom combining algorithm, which is now being worked on to make it part of the standard itself is the on-permit-apply-second policy combining algorithm. Interested readers are encouraged to look to the working draft to get an in-depth understanding of a working use case. There is also a great blog post that provide detail treatment on this topic.
So far we can safely assert that XACML is highly extensible and there is a piece that fits every needs. However everything comes at a price and care should be taken if one intends to take advantage of such flexibility. In my opinion these extension option should be put in action only in case all else have failed. Otherwise one risk creating a model that is tied to a specific implementation of XACML.