OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] XACML Profile for Hierarchical Resources, WD 8


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:Anne.Anderson@Sun.COM]
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:Anne.Anderson@Sun.COM]

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

 >

 >

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

 

 

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.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]