Google Site Search

Google
 

Tuesday, October 12, 2010

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:

2 comments:

Wobbleyheadedbob said...

I'm a Product Manager looking as a likely XACML candidate to fulfilling our access management the problem and I have to say, this problem alone seems to be the 1 stopping block. Our policy management UI needs to be part and parcel of the application and capable of being utilised by end users. I have yet to find a case-study or example solution where XACML policy admin has been done in this way.

As a non-dev I can see why XACML has flown under the radar for so long. Without support for this kind of use case I'm not sure we can implement a XACML solution.

Anil Saldhana said...

Axiomatics has released an eclipse plugin called ALFA. I have not tried it yet.

http://www.axiomatics.com/axiomatics-alfa-plugin-for-eclipse.html

Can you email me at anil at apache dot org about your usecases so I can guide? XACML is a very useful specification.