Simon, thank you for this proposal. I think the problem
statement was not sufficiently clear, and thus the solution is
addressing only part of the problem.
Below is a more clear (I hope) statement of the problem. A
subsequent e-mail will address solutions.
The problem
===========
There are two sides to the "Hierarchical Resource" problem: the
Policy side, and the Request side. Each side lacks functionality
needed to use hierarchical resources effectively in policies.
1. On the <Policy> side, a Policy Administrator may want to
specify a node in a resource hierarchy and say that a certain
collection of Subjects can perform certain actions on the node
itself, other actions on the node's immediate "children", and
still other actions on the node and all its descendants,
without having to spell out a predicate for each separate node
in the resource hierarchy.
Example:
A policy administrator has a policy that any employee may
"read" any file on the "file:/hr.sun.com" system, but that
only employees with the "Human Resource Administrator" role
can write to files on that system.
In a Request, an employee who is not a "Human Resource
Administrator" requests permission to "write" to the
"file:/hr.sun.com/bonus_info/bonus_receivers.txt" file.
PROBLEM: Except for XML document resources, XACML 1.0 provides
no standard functionality to support this type of <Policy>.
There is no standard DataType or FunctionId that allows such a
comparison. For example, there is nothing like:
<Apply FunctionId="ufs-node-descendant-or-equal">
<ResourceAttributeDesignator
AttributeId="resource-id"
DataType="ufs-node"/>
<AttributeValue
DataType="ufs-node">file:/hr.sun.com</AttributeValue>
The exception is "xpath-node-match": if the <Policy> specifies
that access is permitted to any node in an XML document that
matches the XPath expression in the <AttributeValue> for an
Apply of FunctionId="xpath-node-match", then a <Request> that
requests access to a specific node matched by that expression
can be granted access.
2. On the <Request> side, a Subject may want to ask for
access to an entire hierarchy of resources in a single
Request, without having to submit separate XACML 1.0 Requests
for each node in the hierarchy. The corresponding Response
can grant access to certain nodes in the hierarchy, but not to
others.
Example 1:
In a Request, an employee who is not a "Human Resource
Administrator" requests permission to "copy" the
"file:/hr.sun.com/" directory. The Response may indicate
that the employee can copy all immediate children of the
"file:/hr.sun.com/" directory, but not other descendants.
As a result, the PEP may return a copy of the directory that
contains "file:/hr.sun.com/bonus_info/" and
"file:/hr.sun.com/salary_info/", but not
"file:/hr.sun.com/bonus_info/bonus_receivers.txt" or
"file:/hr.sun.com/salary_info/salary_levels.txt".
Example 2:
A medical patient may request a copy of her patient record
from a hospital. The hospital may give her a copy that
omits the nodes containing internal hospital administrative
codes.
There IS explicit functionality described in the XACML 1.0
specification for the necessary <Request> and <Response> for
Example 1:
- Section "7.8. Hierarchical Resources"
- Section "6.9. Element <Response>"
- Section "6.10. Element <Result>"
- Appendix "B.6. Resource Attributes"
The functionality is provided by allowing a Request to include
a special AttributeId of a Resource called its
"resource:scope". The value of the "scope" Attribute can be
"Immediate", "Children", or "Descendants". In conjunction
with such a Request, the corresponding Response may include
multiple <Result> elements, each describing whether access to
a named sub-node is permitted or denied.
PROBLEM 1: For resources that can not be described via XPath
expressions, there is no way to describe Policies that can
"match" Requests using a scope of "Children" or "Descendants".
There is no way to express Example 1 in XACML using standard
FunctionIds and DataTypes. There is no way to describe what
type of hierarchy is represented by a Resource, and no syntax
for expressing matches against portions of the hierarchy.
PROBLEM 2: Even where "xpath-node-match" is used, there is no
description of how that Function interacts with a Request
containing a "resource:scope" attribute. For example, must
any <Apply> of FunctionId "xpath-node-match" reject any
argument that can match more than one node if the Resource
contains a "scope" attribute indicating "Immediate"?
--
Anne H. Anderson Email:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
