Thoughts on an XACML Editor tool

["Hal Lockhart" <hlockhar@bea.com>]

This is something I wrote in a private message a while ago. I thought I should share it with the TC.

 

Hal

 

I completely agree that a good XACML editor should not be XML oriented. Some people have talked about something that attempts to capture high level business concepts and turn them in to XACML policies. I think this is too hard or too specific to a particular application or IT environment. Maybe this will be possible some day, but it is not the approach I would advocate.

 

What I have in mind is more like an IDE which uses graphical metaphors to allow users to construct policies which are then generated in XML. Like an IDE I can imagine that you might want to allow the user to look at the policies in different formats in different windows. Clearly the tool should be able to import other schemas in addition the XACML schemas. For example, attribute schemas would allow the tool to prompt the user for type of attribute and various elements defined for that particular attribute. These could be used to populate drop down menus. Importing data schemas would be useful when the user wants to create policies which reference Resource content. Of course, XACML defined constructs like subject types should be available in drop downs.

 

The editor should make it easy to set up Target matches which correspond to the policy indexing scheme in use.

 

Rule conditions could perhaps be presented in more that one way. Perhaps an arithmetic expression approach would appeal to some people, with symbols like & |  == < > and so forth. Functions could be identified by an initial character followed by the function name and operands in parentheses. A possible model would be the format that Excel or other spreadsheets used for expressions.

 

Overloading operators for different data types would simplify the learning curve. My preference would be to use prefix notation as that corresponds to XACML syntax, but perhaps infix notation with parentheses would seem more natural to most people.

 

Other people might prefer an English language or graphical symbol approach for representing expressions. Perhaps this would be a good place to allow extensibility so developers can experiment with different approaches.

 

Obviously there are a lot of utility features which would be useful, such as following Rule references and displaying the rule, allowing cutting , pasting and saving parts of rules and policies, integration with a what-if-tool, an easy way to combine policies into a policy set, etc.