Hierarhical resources.. part 0.1

["Daniel Engovatov" <dengovatov@bea.com>]

Not sure that this will satisfy the requirement of a “well written and clear proposal”, but I will try to improve it later this week.  This is a first stab at the first part of the proposal: defining the “ancestors” resource attribute.

 

This is a proposed change in the 1.1’s 7.8 section.  It is based of Anne’s text that she posted to the list.   The section dealing with specifying multiple resources within the context schema will require schema change.  This proposal is not contradictory to the XPath based one.  It probably should be merged, with XPath portion clearly indicating that it is optional and based on optionally supported XPath functionality.

 

XPath profile should be improved (I remember Michiharu proposed doing that) to clearly explain how “resource-id” and “ancestor” should be constructed and what is the meaning of <ResourceAttributeDesignator> when policy evaluation refers to sub resources constructed using the <resource content> XML document: I think we should state that they will refer to the specified attribute of the parent object.

 

P.S.  Did not look at 2.0 spec yet, but it looks like for 1.1   Section A.12, lines 3569 – 3572 contradicts an example on 3604-3611 : Attribute Value shall be the first attribute, and designator shall be the second attribute.

------------------------------------------------

 

 

7.13 Hierarchical resources

 

It is often the case that a resource is organized as a hierarchy (e.g. file system, XML document).  Such resources are called hierarchical resources.  XACML supports hierarchical resources in several ways.

1. An XACML request context MAY request access to one or more nodes in a sub-tree of a hierarchical resource.
2. An XACML policy may specify predicates that apply to a sub-tree of a hierarchical resource

 

 

7.13.1      Policy predicates applying to multiple nodes in a hierarchical resource.

 

If a hierarchy of resources is defined, for each resource request context SHALL specify an attribute

 

“urn:oasis:names:tc:xacml:2.0:resource:ancestors”

 

            Type of this attribute is bag[#anyURI].  This attribute SHALL contain inclusive list of the values of “resource-id” attributes for all ancestors of the resource.  It MAY and normally will include the “resource-id” value of the resource itself.

           

            This attribute MAY be used to construct a rule that is applicable to a sub-tree of hierarchical resources

 

            For example:

 

            <Rule Effect=”Grant”><Target><Resources><Resource>

                                                            <ResourceMatch Match-id=”urn:oasis:names:tc:xacml:2.0:function:string-equal”>

<AttributeValue DataType = “http://www.w3.org/2001/XMLSchema#anyURI”>/a/b</AttributeValue>

<ResourceAttributeDesignator AttributeId=”urn:oasis:names:tc:xacml:2.0:resource:ancestors”

DataType = “http://www.w3.org/2001/XMLSchema#anyURI”/>

                                                            </ResourceMatch></Resource></Target>

 

            This rule will be applicable to all resources that include resource with id “/a/b” in its ancestor resources.  Usually, it will also include the “/a/b” resource itself.

 

7.13.2.1

                        {Here the profile on how to define a child Resource using an XPath expression pointing into <ResourceContent> goes.   It includes the profile on how to construct “resource-id”, “ancestors” attributes and what is the meaning of <ResourceAttributeDesignator> }