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.
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:
