RE: [xacml] WI#9 Proposal: policies referring to hierarchical resources

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

On 7 April, Daniel Engovatov writes: RE: [xacml] WI#9 Proposal: policies referring to hierarchical resources
 > >3. Can we possibly be the first group to run up against this
 > >problem?  Why aren't there suitable XML schemas and functions
 > >already available in some other standard?  I have Google'd and
 > >asked, but have not found anything so far.
 > 
 > 
 > Definitely not the first, though I am also unaware on any relevant XML
 > schema's designed.
 > 
 > One problem with the proposed approach is that it assumes that structure
 > of the resource hierarchy is not only well defined, but also well known
 > when the policy is written.

No, it doesn't.  The structure of the resource hierarchy is
supplied as part of the Request in the 'resource-content'
Attribute.  The Policy merely knows key nodes that represent
roots of important subtrees that need to be protected.  If the
Policy doesn't know at least that much, then I don't think you
can write a Policy to protect the hierarchy.

 > I think a more flexible approach would be to address the hierarchical
 > policies using some well defined profile for resource attribute
 > inheritance.   That will not impose any particular rigid structure on
 > customer's resources.
 > 
 > An example of such approach would be to require the "resource-id"
 > attribute to be a bag that includes some resource specific value and
 > values of all "parent" resources.  Then using some matching and bag
 > operation one can target a rule to a variety of resource hierarchy
 > subsets.
 > 
 > That does not impose performance penalty by itself, as the "hierarchy"
 > can be effectively reconstructed during policy compilation at the PDP.
 > But that allows the policy author not to deal with a particular resource
 > structure before the policy is actually used.

Actually, I think my proposal is exactly your solution with just
one difference.  Instead of "require the 'resource-id' attribute
to be a bag that includes some resource specific value and values
of all 'parent' resources", the proposal does the following:

- The 'resource-id' in the Request is still reserved for the
  specific node in the hierarchy to which the Subject is
  requesting access.  [remember, this proposal is not the one for
  addressing a request for multiple nodes in a single request]

  Instead, this information is stored in the 'resource-content'
  attribute.  This is the same solution as that used for
  requesting access to multiple nodes in a single request, so it
  is consistent.

- Rather than a bag of resource-specific value and values of all
  'parent' resources, this information is stored in the hierarchy
  that is expressed in the 'resource-content' attribute.  I tried
  to point out that the 'hierarchy' information is only notional
  - an implementation does not have to translate the entire file
  system into an XML schema instance, but it allows the policy to
  act 'as if' such an instance existed.

  I think the hierarchical schema is an easier way to describe
  the 'parent' resources and values associated with them than a
  'bag'.  You would still have to work out a syntax for the
  resources in the bag and for how to associate values with those
  resources.

  And again, since we are already expecting the resource
  hierarchy to be described in the 'resource-content' Attribute
  for requests for multiple nodes, it makes sense to use the same
  concept for policies that protect multiple nodes.

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