MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Section 7.13 Hierarchical resources
Attached is a substantial rewrite of Section 7.13 "Hierarchical
Resources" in light of our discussions and conclusions on WI#9
(policy predicates covering multiple nodes) and WI#42 (requests
for multiple nodes).
Here is a summary of the differences from the current version.
1. It makes clear the two main aspects of hierarchical resources:
requests that ask for access to a hierarchical resource, and
policies that protect a hierarchical resource. It contains
one sub-section for each of these aspects.
2. It requires ALL requests for access to a hierarchical
resource, even if the request is for a single node, to supply
the "resource-id", "scope" and "resource-content" Attributes.
Supplying a "scope" Attribute is the way a request indicates
that it is requesting a hierarchical resource. It is valid to
include a "resource-content" Attribute without a "scope"
Attribute, but not vice versa. The "resource-id" specifies
either the individual node being requested, or the root of the
sub-tree being requested.
Requests for even a single node have to supply the
"resource-content" because the policy may be expressed in
terms of some ancestor or descendant of the requested node.
Without a view of the full hierarchy, the PDP has no way of
knowing whether the requested node falls into one of those
categories.
3. There is no longer a default value for the "scope" Attribute.
Unless there is an explicit value, the policy does not know
that the resource-id refers to a node in a hierarchy.
4. If there is a "scope" Attribute, but no "resource-content"
Attribute, then a single <Result> of
<StatusCode>="processing-error" is mandated.
This is because "scope" is now tied to the "resource-content"
Attribute and has no meaning apart from it.
5. A default XML representation is supplied for hierarchical
resources that are not themselves XML documents: the identity
of each node in the hierarchical resource instance is the name
of an element in the XML representation.
I had rejected this approach (suggested by Michiharu earlier)
because I thought it required a new schema to be defined for
each instance of a hierarchical document. I now believe this
is not a problem. XPath defines processing of XML documents
for which there is no schema.
6. Nodes in hierarchical resources are identified using XPath 2.0
expressions.
Now that node identities correspond to XML element names,
XPath expressions can be used effectively for all types of
hierarchical resources.
7. If there is not a separate <Result> for each requested node,
then each <Result> applies to its associated node and to all
that node's descendants, except for those descendants having
their own <Result> or a closer ancestor having a <Result>. A
<Result> of "Permit" means access to all the nodes to which
the <Result> applies is permitted. A <Result> of "Deny" means
access to at least one node to which the <Result> applies is
denied.
This is part of an effort to supply clear semantics for
hierarchical resource requests and responses.
8. I no longer try to provide functions for specifying ancestors
of a given node, or for specifying attributes associated with
ancestors.
We just are not clear enough on how we should model the UFS
"read/write requires execute on all ancestors" semantic. This
is the only use case so far.
9. There is one new DataType specified for use with hierarchical
resources: http://www.w3.org/TR/xpath20. Values with this
data type refer to the node resulting from the specified XPath
2.0 expression.
10. There are four new functions specified for use with
hierarchical resources:
a. xpath-node-match: matches two values of type
"http://www.w3.org/TR/xpath20";, returning "True" only if the
two values result in the same node in the
"resource-content" hierarchy.
b. "requested-nodes": returns a bag of
"http://www.w3.org/TR/xpath20"; containing all requested
nodes from the "resource-content" hierarchy.
c. "xpath-node-and-descendants": returns a bag of
"http://www.w3.org/TR/xpath20"; values corresponding to the
node in its argument and all descendants of that node.
d. "xpath-descendants": same as above except returns only
descendants of the node specified in the argument.
Using the higher-order bag functions, these functions allow
matches against some or all requested nodes and/or against
some or all nodes in a given sub-tree.
Rationale: Once I realized that both the request and the
policy might be specifying (different) subtrees in the
"resource", I decided handling the subtrees as bags of values
was simplest. This may have been what Daniel was getting at -
if so, my apologies for not understanding the value sooner.
11. COMMENT: If we do not supply functions that apply to all
ancestors of a given node, then a "resource-content" needs to
contain only the path to the node or nodes being requested
and can stop there. If we attempt to specify policies in
terms of ancestors, then all descendants of the requested
node or nodes must be included, since one of them might be
the base of an ancestor path.
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
Section 7.13 Hierarchical resources
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]