OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 9. Policies referring to hierarchical resources


I believe this proposal summarizes the status of this item based
on discussions at the XACML F2F on 21 Oct 2003.  We split off
requests referring to multiple elements in a hierarchy as a new
Work Item #42, so I changed the work item name to make this more
clear.  I have removed hierarchical subjects and hierarchical
actions from the description, since no one has introduced a
requirement for them and the proposed solution does not work with
them.  If a requirement for hierarchical subjects, actions,
environment, issuers :-) is introduced, it should be a new Work
Item.

9. Policies referring to hierarchical resources

   How to express policies that apply to a hierarchy of
   resources.  E.g. "Frank can read any file under directory
   /X/Y".

   TYPE: New functionality
   STATUS: Open issues.  Related: #25,42.
   CHAMPION: Simon Godik

MOTIVATING USE-CASE AND REQUIREMENT

   Many resources, such as files in a file system, are
   hierarchical.  A policy needs to be able to control access to

   o all descendents of a particular node in a hierarchy:
     "Anne can read any file under directory /home/aha"
   o all immediate children of a particular node in a hierarchy:
     "Frank can read any file that is an immediate child of
      directory /home/aha"
   o a particular node in a hierarchy:
     "Frank can see that directory /home/aha exists"

   XACML does not currently have syntax or semantics for
   expressing such policies except where the hierarchy is an XML
   document.

SUMMARY OF OPEN ISSUES

   1) XACML's set of XPath functions is very limited.  They will
      work if the mapping makes the element names match the nodes
      in the file system, but not if the mapping makes the
      element values match.
   2) If element names must match, then a different mapping
      schema is required for every file system instance.  This
      seems VERY unworkable.  It would be much better if a
      standard mapping schema could be developed for any UFS file
      system.
   3) The XPath "*" syntax handles entire subtrees, but does
      XPath have a syntax for indicating "immediate children"?

PROPOSED SOLUTION <# if more than one>

   In order to compose policies and submit authorization decision
   requests concerning elements of hierarchical resources, there
   must be a mapping between the elements of the hierachical
   resource and an XML document that describes those elements.
   For example, the following file system directory tree
      /
      /aha/
      /aha/home/
      /aha/home/docs/
      /aha/home/docs/status.txt
      /aha/home/docs/plans.txt
      /frank/


   might be mapped to the following XML document representation
   (many mappings are possible):

      <root>
         <aha>
            <home>
              <docs>
                <status.txt/>
                <plans.txt/>
              </docs>
            </home>
          </aha>
          <frank/>
      </root>

   POLICIES

   The policy writer must be aware of this mapping, and must
   write policies using XPath expressions on this XML document
   representation.  For example, to express "Anne can perform any
   action on directories and files in the subtree below
   /home/aha", the following Rule could be used with the
   representation above:

   <Rule Effect="Permit">
     <Condition FunctionId="and">
      <Apply FunctionId="string-equal">
        <SubjectAttributeDesignator DataType="string" AttributeId="subject-id"/>
        <AttributeValue DataType="string">Anne</AttributeValue>
      </Apply>
      <Apply FunctionId="xpath-node-match">
        <AttributeSelector DataType="string" AttributeId="xpath"/>
        <AttributeValue
   DataType="string">/Resource/ResourceContent/root/home/aha/*</AttributeValue>
      </Apply>
    </Rule>

   REQUESTS

   Requests to access an element of a hierarchical resource must
   include the XML representation of the hierarchical resource
   itself in the <ResourceContent> element, just as is currently
   done for accesses to elements of an XML document.  For
   example, to express: "Can Frank read
   /home/aha/docs/Status.txt", the following Request would be
   submitted:

   <Request>
     <Subject>
       <Attribute DataType="string" AttributeId="subject-id">
         <AttributeValue DataType="string">Frank</AttributeValue>
       </Attribute>
     </Subject>
     <Resource>
       <Attribute DataType="string" AttributeId="xpath">
         <AttributeValue
DataType="xpath">ResourceContent/root/home/aha/docs/Status.txt</AttributeValue>
       </Attribute>
       <ResourceContent>
         <root>
            <aha>
               <home>
                 <docs>
                   <status.txt/>
                   <plans.txt/>
                 </docs>
               </home>
             </aha>
             <frank/>
         </root>
       </ResourceContent>
     </Resource>
     <Action>
       <Attribute DataType="string" AttributeId="action-id">
         <AttributeValue DataType="string">read</AttributeValue>
       </Attribute>
     </Action>
   </Request>

   GENERAL

   1) The mapping might be done by the PEP or by the Context
      Handler (Context Handler would have to have access to the
      underlying file system to do this).  The actual creation of
      the mapped resource need never be done: the Context Handler
      can simply access the underlying file system according to
      its interpretation of the XPath expressions used in the
      policy and in the request.
   2) If the policy writer and the mapper want to ensure that
      they are referring to the same mapping schema in describing
      the resource, the Request could include an additional
      Resource Attribute "resource-schema" with the value
      representing the schema used in constructing the request.
      The policy writer could include a condition like
      resource-schema = "ufs1", where "ufs1" is the identity of
      the schema assumed by the resource writer.

DETAILED SOLUTION

  [Actual text and schema changes or additions, referencing line
   numbers in the XACML 1.1 PDF Specification, required to
   express this solution in the 2.0 specification.

   This may be in the form of edits to the source XACML 1.1
   Specification, attached to the e-mail containing the
   Proposal.

   Don't bother with this until the SUMMARY indicates there are
   no issues that remain to be resolved, and there is consensus
   on one PROPOSED SOLUTION above.]

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]