When used correctly, XACML is a powerful tool to manage access and authorization, however, it has its challenges. Fortunately, solutions have been found and new methodologies have been described that can overcome XACML issues to allow you to fully utilize the standard.
The Extensible Access Control Markup Language (XACML) is an OASIS standard which is currently in version 3.0. XACML is an attribute based policy language that was designed to help with interoperability in authorization across applications. Below, three common XACML issues have been highlighted along with recommendations of how to go about overcoming them.
XACML is based on the fundamental idea of a ‘PolicySet’. This is basically a type of container that holds access control policies/rules or points to other remote policies. This fundamental XACML object is written using XML. XML is syntactically sensitive. At the very least you need an XML editor, to prevent the nightmare of syntax errors. If you are not au fait with writing, at the very least, scripts, then you will struggle, even when using a more traditional XML editor. You can imagine if you have multiple policies, that are interdependent, the development of your XACML PolicySet could become onerous.
Ideally, you don’t want to write XACML policies in order to use XACML.
When creating rules and policies within XACML, the best and quickest way to get the job done is by using a graphical interface. A specialized user interface for XACML policy creation will allow you to create XACML policies without having to write complex XML code. If the UI is graph-based, you can visibly define the relationship between digital IDs and your resources. The UI acts like a ‘whiteboard’ giving you an instant view of your options and policies so you can make more informed decisions, changes, and updates, quickly and easily.
XACML policies have the potential to be far-reaching. Understanding ‘who and what’ will be influenced by those policies can be problematic, especially if you are working with multiple policies across myriad targets. It can be easy to make mistakes unless the authorization rules applied are checked before implementation.
Always check your XACML policy before deployment using a sandbox environment. Sandboxes replicate your production environment to a degree allowing you to test out the system before production. Your sandbox will let you see the outcome of your policy settings so you can adjust them as required. Using a graphical UI as in challenge #1 above, allows updates and changes to be made quickly before then retesting in the sandbox.
XACML solutions are often believed to have performance issues associated with policy evaluation process and policy set structure. This is usually attributed to the following main reasons:
Real-time policy evaluation: Evaluation of the XACML policy is done in real time by the PDP as it interrogates the PIP. This means the policies have to be fetched and evaluated per request, this has the potential to create a system load issue at runtime causing longer response times.
Approving each access request: XACML protocol dictates that each access request to a resource is evaluated. This results in many back-and-forth between the PEP and the PDP, which potentially results in an overall delay.
Policy matching and attribute retrieval: XACML relies on often complex policy structures and the timely retrieval of attributes (that policies rely on). Every access to a resource needs to be matched and evaluated to give the application/PEP a response for every access request. This flow can create response time delays.
Using XACML can seem daunting if you look at the challenges. But using advanced technologies like a graph-based solutions and a sandbox to test out your policies, makes the process much smoother and your data and resources more secure.