XACML Policy Editors - Domain driven or language driven

The Authorization process is extremely cumbersome and prone to errors. Typically it is rules based. Decisions based on combination of rules can lead to errors or holes. Because of errors, if the access check returns in a "denial", then the damage is minimal. Someone can verify why that particular access check got turned down.  On the contrary, if the errors lead to a successful unauthorized access, then you know the answer. :)

One of the challenges associated with configuring security is not contempt towards the field of security but the perception of complexity. Administrators/architects/developers are turned down by the number of possible combination associated in configuring ACLs/Rules.

In the Java EE world, web.xml acts as the bedrock of container driven security for web applications.  Long ago, I wrote an article on this that highlighted the permutations and combinations available to admins/devs. Ok, I am a big supporter of container based security because the opposite (custom security) is prone to errors and unmaintainable over the long run.

Coming back to configuring rules,  probably 10% of devs/architects/admins are fully versed in the XACML language and clearly understand the language. So for them a pure XACML policy editor makes sense.  The rest of the crowd just wants to configure their access control system using plain language as follows:

• This web application can be accessed by an user in the group "employee".
• This part of the web application is restricted to managers alone.
• This part of the web application is accessible under normal business hours.

Now the domain based editor for the web applications needs to have UI elements that are simple to understand. The person configuring the system will be able to look at the requirements and check/select the appropriate boxes.

While I am not denying the usefulness of a full fledged XACML policy editor, I am seriously not in agreement that they are the norm. If XACML is to see ubiquitous adoption, there is a need for configurable domain based editors. The infrastructure for access control can be driven by XACML policies and evaluation, but the policy configuration has to be driven by simple domain based editors.

References to Read:

• XACML Design Considerations and Pointers
• Travis Spencer problems with XACML and solutions
• Discussing XACML with Travis