Re: [xacml-comment] Some observations

[Anne Anderson <Anne.Anderson@Sun.COM>]

John,

Thanks again for your comments.  It is always helpful to get
feedback from people who are applying XACML.

On 23 June, John Howard writes: [xacml-comment] Some observations
 > 1.  For RBAC there is a need to define policySet that are only accesible 
 > through a policySetIdReference, it would be useful if a policySet could 
 > be defined as either public or private.  public policySets would always 
 > be evaluated, private policySets would only be evaluated if included as 
 > a reference.

This does not require spec changes, right?  It is just a paradigm
for usage, right?

 > The next two comments arise from our experience in trying to graphically 
 > represent an XACML policy.
 > 
 > 2.  As any thought been given to defining function classes.  For re-use 
 > it would be useful to be able to define a function class as a set of 
 > logic and a number of parameters.  e.g.  calculateAge would take a date 
 > of birth as a parameter and return the age in years.  This condition 
 > could then be used to calculate Bart's DOB, or the Doctor's DOB for 
 > example.  This is both good from a re-use point of view, but it is very 
 > benefical when graphically trying to represent XACML as a condition can 
 > then be modeled as a decision tree.  With the decision tree consisting 
 > of the function classes.  e.g.
 > 
 > Is Under 18 ------- CalculateAge ------- dob
 >        |
 >        |------------- current Date
 > 
 > dob and current Date are attributes.  Is Under 18 and Calculate Age are 
 > functions.

Since XACML functions are extensible, you can always do this by
defining a new "calculateAge" function as an extension to your
own implementation.

Daniel Engovatov, in the XACML TC, has expressed interest in
trying to define a more general model for describing functions.
Perhaps you could work with him to develop a specific proposal.

 > 3.  The other addition that would be welcome is that of attribute 
 > aliasing.  What we are finding is that the person who defines the model 
 > is not necessary the same person that will connect the policy to the 
 > real world.  So a modeller would want to deal with abstract attributes, 
 > but the deployer would want to deal with real world attributes.  e.g. 
 > LoanValue may be a XPath into the input document, Role may come from an 
 > external attribute server, but the modeller doesn't need to know this 
 > information and it would be good from a graphical representation of 
 > XACML if this could be hidden.  Yes, we could keep a seperate meta-data 
 > file for a policy, but we feel there is a benefit for having all the 
 > information in the policy.

Interesting idea.  We had a work item called "Location
Information" - an element in a policy that would provide hints to
the Context Handler about where to find Attributes and how to map
them.  This work item fell off our work list due to lack of time
to develop it.

Seth Proctor has implemented a meta-data file that describes
which Attribute Finder Modules need to be configured as part of
Sun's open source XACML Implementation at
http://sunxacml.sourceforge.net.  That does a bit of what you are
suggesting, although it is not in the policy itself.  Seth felt
it would be difficult to describe all the necessary Attribute
mapping information in a practicable policy element.  If you want
to develop a concrete proposal and submit it to the XACML TC, I'm
sure we would be willing to consider it.  It is definitely too
late for XACML 2.0, but it might be appropriate for a profile or
for a subsequent release, if there are any.

Thanks for your suggestions!

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692