MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Comments on xacml-profile-hierarchical-resources draft
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]