Scaling XACML Architecture Deployment

XACML, which stands for eXtensible Access Control Markup Language, exists to solve the problem of authorization (AuthZ) with focus on extensibility, granularity and scalability. From a first glance at the standard specification it appears to do all the magic with a seemingly over-simplified reference model; at least it was my impression when I first learnt about it. However the simplicity of the model is the key that makes XACML easy to adopt and gives the flexibility to the implementor to scale it up to meet any requirement. This post will discuss the various options available to scale a XACML deployment.

Axiomatics Policy Server 5 architecture will be used as example for the different approached discussed in this post.

XACML Architecture

The reference data-flow model can be found in the XACML standard itself, which serves as an authoritative source for description of what any implementation must follow to comply with the standard. The following diagram provides a more easy-to-read version of the XACML reference model, which could be used as the diagrammatic representation of the model, as discussed in this blog post.


Readers who find themselves wondering what PDP stands for or why there is a hand on a PEP are urged to go through the narrative introduction on the XACML architecture in this blog post XACML Reference Architecture.

Embedded PDP

This is the most straightforward deployment scenario if you are coming from a developer’s standpoint, with a need to fully control what and how things are done. Looking forward to extend your home-brew authorization service with granular, attribute-based capability? Just pick up an XACML implementation library and build your own fancy authorization scenario.

There are quite a few implementations out there that you can choose from; some of which are open-source as well. It is true that Sun’s XACML is a bit out-of-breath for now yet it is still the base on which many other implementations are built.

The following is the Axiomatics embedded PDP engine architecture, which provides an easy-to-use interface to integrate the power of XACML into any Java-based system.

This approach provides the flexibility to tightly couple the PEP and the PDP and minimize architecture change. This approach may work when the number of applications is small and there is little value in providing a unified externalised authorization service across the board. However, as the organizational need for authorization grows, a fundamental change in the authorization architecture becomes necessary to cope with growing maintenance cost in the heterogeneous environment.

The bottom line is: while this approach does brings ABAC capability, and together with it granularity, to your authorization scenario, it is not very scalable and certainly not extensible when considering enterprise authorization as a service architecture.

PDP as a managed component

The first step to provides scalability to your XACML authorization service, which provides policy-based authorization service to any application that requires, is to make the Policy Decision Point (PDP) a managed component in your enterprise architecture. Note that details of how the PDP is managed is out-of-scope at this point, or rather this level of integration only focus on exposing the PDP authorization service to all enterprise applications.

In this example the PDP management interface is accessible through Axiomatics Service Manager (ASM) component, which provides a web-based user interface to control the PDP service. Enterprise applications can request service from the PDP through well-defined interface such as SOAP or, if necessary, custom interface that can be plugged in to the PDP component.

Scalable management of AuthZ service

The more heterogeneous the system becomes, the more expensive it is to manage all possible AuthZ scenarios required by each application. In the environment where the application is limited and their nature do not exhibit big difference, it is sufficient to have isolated component managing different application domain and configuration management being done using any out-of-band method. However fast-growing and/or dynamic enterprise environment often requires a centralised approach where all policies are centrally managed and monitored.

This is an open space in the reference model where the implementor is left to decide how to scale the architecture to meet real-life requirement. One such example depicted below is the Axiomatics Service Manager component in APS where all PDP configuration are grouped into different domain and managed centrally. Such a setup not only provides configuration management but can also potentially serve as the provider interface for many other services such as monitoring, auditing and attribute indexing.


It is important to note that this architecture differs from the previous one where the PDP and the ASM is coupled together in the same runtime environment to provide maximal functionality with limited scalability. While it is a subtle change from a technical setup point of view, the latter emphasizes the importance of an unified design where the authorization scenario for all enterprise applications are considered together and properly translated into XACML policies, which can then be centrally managed, provisioned and enforced across all domains.

Setup for High Availability (HA)

With all pieces falling together, it is time to look at how we can cope with high volume of authorization requests and, at the same time, provide high availability (HA) service. On the high-level, an HA setup should consider a number of things:

  • Service transparency: This refers to the fact that the HA setup should be transparent to any application that consumes the service.
  • Consistency: This requires that the evaluation returned by the PDP stay consistent with the policy. In other word, there is a one-to-one mapping in policy changing and the change of evaluation result on the client side

The following is an example of Axiomatics Policy Server (APS) deployment scenario that utilise WebSphere clustering to provide HA capability.

This particular implementation assume two things:

  1. On the configuration management side, the replicated instances stays visible to the management component, which is the Axiomatics Service Manager in this case. This gives explicit control and monitoring capability to the user to ensure the consistency of the policy imposed on the domain and its nodes
  2. On the service side, a Web server is used as the load balancer to provide transparency to the PDP service. It is recommended that sticky session behavior is utilized to ensure consistency


The question of how to deploy the XACML architecture model in a scalable way is such an open topic that there is no definite right or wrong scenario that one can just easily pick and choose. The silver lining to take from this is that there is, in most cases, a particular setting that will emerge suitable after all capacity planning is considered. It is hoped that the sample scenarios presented in this blog post have provided a starting point to anyone who are interested in bringing XACML model into real-life deployment.

Related Articles

Meeting today’s dynamic authorization and access challenges: The Axiomatics story | Dynamically Speaking
Dynamically Speaking
For more than 15 years, Axiomatics has worked with companies worldwide to define and deliver solutions to the most complex authorization and access challenge. In...
Getting started with Zero Trust using dynamic authorization | Dynamically Speaking
Dynamically Speaking
Zero Trust. It’s everywhere. It’s a methodology that’s been around for years, and we are now seeing a significant uptick in the number of enterprises...
The case for dynamic authorization in banking and finance
Attribute Based Access Control (ABAC)
More than other organizations, banks, and financial institutions face the highest levels of scrutiny when it comes to how they protect critical assets and sensitive...