Hierarhical resources.. part 0.1

MHonArc v2.5.0b2 -->
















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Hierarhical resources.. part 0.1




From: "Daniel Engovatov" <>
To: <>
Date: Mon, 10 May 2004 16:59:59 -0700














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.


 An XACML request context MAY request access to one or
     more nodes in a sub-tree of a hierarchical resource.
 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> }

 

 











Follow-Ups:

Re: [xacml] Hierarhical resources.. part 0.1
From: Anne Anderson <>








[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]