An example would be
Allow delete any file in directory, but not the directory itself
GRANT(delete, "/a/b" = resource-ancestors)
//remembering that "=" is equivalent to "in-bag"
for target matching operations
For the case when you are allow to delete directory as well(/a/b in
this case) that would be:
GRANT(delete, "/a/b" = resource-ancestors-or-self)
In general, when hierarchy has non-heterogeneous resources, ancestors,
distinct from ancestors-or-self would be useful to have.
The reason I suggested defining ancestors-or-self using the type-union
function definition is to avoid duplicating the "self" in cases when
the ancestors are defined to include the "self".
As far as "parent", I think they are not generally needed, as
for system requiring one level deep inheritance that can be handled with an
appropriate definition of what "ancestor" is. So I would also
think that "parent-or-self" is redundant.
Daniel;
-----Original Message-----
From: Anne Anderson [mailto:]
Sent: Wednesday, September 15, 2004 8:24 AM
To: XACML TC
Subject: RE: [xacml] XACML Profile for Hierarchical Resources, WD 8
Can anyone supply a use case for where a policy will be based on
the ancestors of a node, but not the node itself? I would rather
not add a new AttributeId, but if there are no use cases for
"ancestors not including self", then I would be happy to
change
"resource-ancestor" to "resource-ancestor-or-self".
And do we need a "resource-parent-or-self"? I can't
think of a
use case. So is leaving "resource-parent" without
including
"self" OK?
On 14 September, Daniel Engovatov writes: RE: [xacml] XACML Profile for
Hierarchical Resources, WD 8
> 1.
> For the non XML hierarchy, we either need to add to the
definition of
> the resource-ancestor, that it does include the resource-id
of the
> resource itself. It is important for the use
case of policies
> applicable to a resource itself and all its children: so you
do not need
> to write two rules.
>
> OR (probably preferably, as it fits along with XQuery/XPath
axes
> definitions): add definition for
> urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self
>
> "For each ancestor of the node specified in the
"resource-id" attribute
> or attributes, and for each normative representation of that
ancestor
> node, an <Attribute> element with AttributeId
> "urn:oasis::names:tc:xacml:2.0:resource:resource-ancestor-or-self".
>
> The <AttributeValue> of this <Attribute> SHALL
be the result of applying
> urn:oasis:names:tc:xacml:1.0:function:type-union function to
the
> contents of
> "resource-id" and "resource-ancestor"
attributes, where the "type" is
> selected according to the used datatype of those
attributes."
>
> 2.
> We need to mention in the definition of
"resource-ancestor", that it can
> not be guaranteed to be computed by recursively combining
> "resource-parent" values. Parent of a parent
is not necessarily defined
> as an ancestor in our case (this is to avoid circular
reference and
> other problems). That may seem odd, but we should not
impose
> unnecessary requirements on the structure.
I'll have to admit I don't understand this. Exactly why can't
you define "resource-ancestor" by recursively combining
"resource-parent"? Why does that introduce circular
references?
Can you give a concrete example?
Anne
> Daniel;
>
> -----Original Message-----
> From: Anne Anderson [mailto:]
> Sent: Tuesday, September 14, 2004 10:29 AM
> To: XACML TC
> Subject: [xacml] XACML Profile for Hierarchical Resources,
WD 8
>
> Colleagues,
>
> I have entered a new draft of the Profile for Hierarchical
> Resources into the repository. The link on our TC web
page now
> points to it.
>
> The changes since the previous draft are:
>
> In response to Michiharu's comment in
>
http://lists.oasis-open.org/archives/xacml/200409/msg00002.html
>
> - Add clarifying paragraph to the introduction explaining
that a
> hierarchical resource may be "represented" as an
XML document
> even if it physically is not an XML document; likewise, an
XML
> document resource may be "represented" as a
non-XML hierarchy.
>
> - Change all instances of "XML document resource"
to "a resource
> represented as an XML document" (the exact wording
varies
> depending on the context)
>
> I also re-inserted the definition of xpath-expression
DataType,
> since it is no longer in the XACML core spec.
>
> Anne
> --
> Anne H.
Anderson
Email:
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311 Tel:
781/442-0928
> Burlington,
MA 01803-0902
USA Fax:
781/442-1692
>
>
> 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_workgro
> up.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:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington,
MA 01803-0902
USA Fax:
781/442-1692
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.
