Re: [xacml] first proposal for hierarchial resources

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

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: 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