Re: [xacml] Hierarhical resources.. part 0.1

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

Daniel,

Thanks for the write-up.  I have been working on a revised draft
that uses your idea, and expect to issue it within a couple of
days.  Here is a brief summary.

RESOURCE-ANCESTORS: One important difference is that there can't
be a single "resource-ancestors" Attribute.  We do not allow
"bags of bags", and have no functions for operating on them.

However, it is possible to define a "resource-ancestor" Attribute
(and a "resource-parent" Attribute), and require there to be an
instance of this Attribute for each ancestor/parent.  A
ResourceAttributeDesignator that references the
"resource-ancestor" or "resource-parent" Attribute will then
return a bag with all the ancestors / parents.  I think this is
the result you want.

XML DOCUMENTS: I have proposed some changes to XML document
hierarchy handling, including use of the "resource-id" Attribute
with a new "xpath-expression" DataType rather than using the
"xpath" Attribute with a String DataType.  The reason is that the
<Result> elements will need to identity the node to which they
refer in a "ResourceId" XML attribute, and the only standard way
we have to specify these is with XPath expressions that evaluate
(only) to the node associated with the <Result>.  Someone
suggested we could not define an "xpath-expression" DataType
because there is no standard for XPath expressions.  But I think
we can specify it as being a "string to be evaluated as an XPath
expression", just as we have be saying in the specification for
Attributes having "#string" types "to be evaluated as XPath
expressions".

I am also suggesting we require use of the "resource-content"
Attribute with XML document hierarchies; it's notional anyway, so
can represent whatever document the XPath expression in
"resource-id" relates to.

ONE REPRESENTATION PER RESOURCE TYPE: I have proposed, unless
there is a profile for the given resource type that specifies
different handling, that XML document resources SHALL only be
handled using the XPath mechanisms, and non-XML document
resources SHALL only be handled using the resource-ancestor and
resource-parent mechanisms.  The reasons for this are:

a) Unless we have one representation for a given resource type,
   policies will not always apply to instances of the resource
   when they are intended to.

b) We do not have any standard syntax other than XPath for
   representing actual hierarchical structure (resource-ancestor
   and resource-parent lose all information about the structure
   of the hierarchy itself other than the "descendant" status of
   the requested resource).

c) XPath is powerful enough that I think it should be available
   for use with XML documents.  I think enterprises trying to
   write policies about the contents of XML documents will have
   XPath available.  On the other hand, it is hard to specify a
   standard representation of non-XML hierarchies in XML and it
   is computationally difficult to create those representations
   in such a way that XPath expressions can be correctly
   evaluated against them.

REQUESTS FOR MULTIPLE NODES: On the topic of requests for
multiple nodes in one Request, I think we all agree that the
<Result> elements must be equivalent to those obtained by
evaluating access to each node independently.  For this reason, I
don't think the "scope" Attribute or a "resource-id" Attribute
evaluating to more than one node should be visible to XACML
policies.  I suggest three syntaxes that a PEP could use for
requesting multiple nodes (XPath, scope, and your <Requests>
idea), but I don't think they should be part of what is presented
to the PDP for evaluation: the Context Handler should convert
them.  This may rule out some types of optimization, so I am
eager to hear of any objections (along with suggestions for
semantically consistent handling).

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