Re: [xacml] Comments on xacml-profile-hierarchical-resources draft

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

Thank you very much for the comments.  We are in general
agreement, and I think it would be good for the Hierarchical
Resources Profile to be more clear on specifying how to identify
the scheme being used.

I do have some questions and comments, however.  They are
inserted in-line below.

On 14 July, Michiharu Kudoh writes: [xacml] Comments on xacml-profile-hierarchical-resources draft
 > The following is my comment on the draft document of hierarchical resource
 > profile.
 > 
 > 1) Separation of scheme from actual target resource
 > 
 > The hierarchical resource profile basically consists of two parts, policy
 > for XML nodes and policy for for non-XML nodes. I think more explanation
 > would be needed to clarify the problem domain of hierarchical resources.
 > 
 > XACML v2 is aiming to provide two ways of writing a policy for hierarchical
 > resource but it does not necessarily mean that the target resource should
 > be XML document or non-XML document. I think that a policy writer can write
 > a policy for non-XML hierarchical resource (e.g. directory access) using
 > access-to-XML-node scheme (case A). It is also true that s/he can write a
 > policy for XML resource (like medical record formatted in XML) using
 > access-to-non-XML-node scheme case B).
 > 
 > In case A, the target directory hierarchy is converted into XML data which
 > is inserted into <ResrouceContent>, and the access request is converted
 > into XPath expression. In case B, access to XML document is represented as
 > a simple path like /record/patient and the policy would be described using
 > regular expression (or URI-match function) if the requested resource-id
 > matches against the policy.
 > 
 > So what I want to say here is that the two schemes XACML hierarchical
 > profile provides can be used regardless of the type of the ACTUAL target
 > resource. The following figure represents my intention.
 > 
 > Actual target         Actual target
 > resource is XML    resource is not XML
 > (eg XML med rec)        (eg directory)
 >                 |  \             / |
 >                 |      \    /      |
 >                 |       /   \      |
 >                 |  /            \  |
 > XACML XML             XACML non-XML
 > based scheme           based scheme
 > 
 > XACML 1.0 scheme corresponds to the vertical line on the left. XACML 2.0
 > now provides four ways as the above figure dipicts. How to map the actual
 > target into request context and how to write a policy is outside of the
 > scope of XACML. I think this means that XACML provides a flexible way to
 > use XACML but two kinds of the semantics are defined.
 > 

I think there are actually six cases for hierarchical resources
to consider ("anyUri-match" is whatever we end up defining for
matching URIs):

1. An XML document treated as a set of nodes, where each node is a
   resource,

   Request:
   - The <ResourceContent> MUST contain the entire XML document.
   - The "resource-id" Attribute is an XPath expression that
     selects all desired nodes out of <ResourceContent>.  Results
     are identical to those obtained if a separate Request for
     each desired node was submitted.
   - The "document-id" Attribute is a URI/URL that names the
     document contained in <ResourceContent>
   - May use "scope" Attribute.
   Policy:
   - Uses xpath-node-match to express policy based on which nodes
     are requested
   - Uses anyUri-match/equal to target policy to correct set of
     XML document(s)
   - May use an <AttributeSelector> with an XPath expression
     pointing into <ResourceContent> to express policy based on
     values of nodes in the XML document as a whole.
   - May use ":resource-ancestor" and ":resource-parent"
     Attributes to target policy to correct set of nodes.

   Note: we do not currently define a way to express policy based
   on the value of the requested node.  I have not seen a use
   case that requires this, so have not defined it.

2. An XML document treated as a single resource, but where
   constraints MAY depend on the values of specific nodes in the
   resource,

   Request:
   - The <ResourceContent> MAY contain the entire XML document.
   - The "resource-id" Attribute is a URI that names the document
     requested.  If <ResourceContent> is present, then it MUST
     contain this document.  The "resource-id" Attribute in this
     case contains exactly what the "document-id" Attribute
     contains in case#1.
   Policy:
   - Uses anyUri-match/equal to target the policy to correct set
     of XML document(s).
   - May use an <AttributeSelector> with an XPath expression
     pointing into <ResourceContent> to express policy based on
     values of nodes in the XML document as a whole.  If
     <ResourceContent> is not present, then this will cause the
     policy to be "Not Applicable" or "Indeterminate", depending
     on where the <AttributeSelector> is used.

   The current Hierachical Resources Profile does not support
   this case.  If we do support it, then every policy that
   protects and XML document will need to express two sets of
   contraints on the document, one to cover requests for the
   document as a whole and the other to cover requests for
   individual nodes in the document.  Policy Authorities and PEPs
   would have to agree on how a given XML document is to be
   treated.

3. A node subtree of an XML document treated as a single resource,
   again where constraints may depend on the values of specific
   nodes in the resource,

   Example: <ResourceContent>
              <A>
                <B>
                  ...
                </B>
                <B>
                  ...
                </B>
              </A>
            </ResourceContent>

   where user wants access to all of the second <B> element as a
   single resource.

   We do not support this.  Is this OK with you?

   If user wants any sub-tree in an XML document, the user must
   request each node in the sub-tree as a separate request as in
   Case 1.  The Multiple Resources Profile defines three ways of
   making such requests without having to actually submit a
   separate Request from the PEP for each:

    - Multiple <Resource> elements in the Request,
    - A "resource-id" Attribute with DataType "xpath-expression"
      where the value is the single node at the root of the
      requested sub-tree and the "scope" Attribute describes the
      set of requested nodes,
    - A "resource-id" Attribute with DataType "xpath-expression"
      where the value is an XPath expression that selects all the
      desired nodes.  A "scope" Attribute must not be present if
      the XPath expression in the "resource-id" Attribute selects
      more than one node.
                
4. A non-XML resource expressed as an XML document and treated as
   a set of nodes, where each node is a resource,

   This requires a resource-specific Profile or other out-of-band
   agreement between the Policy Authority and the PEPs on how the
   resource will be mapped into XML.  It is handled in Requests
   and Policies exactly as in Case 1.

5. A non-XML resource with nodes identified using hierarchical
   URIs.

   Request:
   - <ResourceContent> is NOT present.
   - The "resource-id" Attribute is a URI that names the
     requested resource and that reflects its hierarchical
     structure.
   - May use "scope" attribute.
   Policy:
   - Uses anyUri-match/equal to target the policy to correct set
     of resource nodes.
   - May use ":resource-parent" or ":resource-ancestor"
     Attributes with "anyURI-is-in" function to target the policy
     to the correct set of resource nodes.

   Except for resources such as files, where a mapping of files
   and directories to URLs is already defined, this method
   requires a resource-specific Profile or other out-of-band
   agreement between Policy Authorities and PEPs on how the
   resource's nodes will be expressed as URIs.

6. A non-XML resource treated as a hierarchy using a structure the
   ContextHandler knows, and where ":resource-parent" or
   ":resource-ancestor" Attributes are used in the policy.

   Request:
   - <ResourceContent> is NOT present.
   - The "resource-id" Attribute is some value that names the
     requested resource.
   - May use "scope" Attribute.
   Policy:
   - Uses "*-is-in" or other match functions using "resource-id",
     "resource-ancestor", and "resource-parent" Attributes to
     target the policy to the correct set of resource nodes.

 > 2) Procedure to identify the scheme
 > 
 > Since XACML supports two schemes (XML and non-XML), we need to give a
 > comprehensive procedure how to validate the request context. The following
 > is  such a procedure. Please correct me if I am wrong.
 > 
 > 1. If a request context includes the resource-id which data type is
 > xpath-expression, then the context must include at least one
 > <ResourceContent> per <Resource> which may or may not have the scope
 > attribute. It means that this request is XML-based hierarchical resource
 > access. In this case, policy is written using xpath-node-match function.

Agreed.

The current Multiple Resources profile says the Request MAY use
"scope" in this case, so long as the resource-id XPath expression
selects only a single node.  Is this OK with you?

The current Hierarchical Resources says the Request MAY use
"resource-ancestor" and "resource-parent" Attributes in this
case.  Is this OK with you?

 > 2. If a request context includes the resource-id which data type is NOT
 > xpath-expression, then the request is non-XML-based hierarchical resource
 > access. It must not include <ResourceContent>. It may or may not have the
 > scope attribute. In this case, policy is written using regexp-string-match
 > function (or corresponding URI-match function) or string-equal on
 > resource-parent etc.

This is what the current Hierarchical Resources Profile tries to
say.

Seth pointed out, however, that some users want to access XML
documents as whole resources, and not as individual nodes.  But
the policy might still depend on the value of a node inside the
document.  For example, the policy might be:

  "Michiharu can read resource-id
  "http://www.example.com/patient-records/A"; if
  "//Resource/ResourceContent/A/B/C/text()" == "Michiharu".

This is case#2 above.  In this case, even though the resource is
not requested as a set of nodes in <ResourceContent>,
<ResourceContent> must still be present so that
<AttributeSelector> predicates can use the values of nodes in the
resource.

Do we want to support this case, or do we say that any XML
document must always be requested as individual nodes?  This
avoids the need for any resource-specific agreement between
Policy Authority and PEP, but it makes requesting entire
documents expensive!

Anne

 > Best
 > Michiharu
 > 
 > 
 > 
 >                                                                                                                                  
 >                       Anne.Anderson@Sun                                                                                          
 >                       .com                     To:       xacml@lists.oasis-open.org                                              
 >                                                cc:                                                                               
 >                       2004/06/04 02:06         Subject:  [xacml] Groups - xacml-profile-hierarchical-resources-1.0-draft-04.pdf  
 >                                                 uploaded                                                                         
 >                                                                                                                                  
 >                                                                                                                                  
 >                                                                                                                                  
 > 
 > 
 > 
 > The document xacml-profile-hierarchical-resources-1.0-draft-04.pdf has been
 > submitted by Anne Anderson (Anne.Anderson@Sun.com) to the OASIS eXtensible
 > Access Control Markup Language TC document repository.
 > 
 > Document Description:
 > A profile for the handling of hierarchical resources using XACML.
 > 
 > Download Document:
 > http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/7050/xacml-profile-hierarchical-resources-1.0-draft-04.pdf
 > 
 > 
 > View Document Details:
 > http://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=7050
 > 
 > 
 > 
 > PLEASE NOTE:  If the above links do not work for you, your email
 > application
 > may be breaking the link into two pieces.  You may be able to copy and
 > paste
 > the entire link address into the address field of your web browser.
 > 
 > 
 > 
 > To unsubscribe from this mailing list (and be removed from the roster of
 > the OASIS TC), go to
 > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
 > .
 > 
 > 
 > 
 > 
 > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
 > 

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