RE: [xacml] Hierarhical resources.. part 0.1

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

Dang, you may be right.   We bypassed this issue for constraints as we
had functions to make a bag of values.  As I was not working with
request schema I forgot about that.

But, couldn't you just specify multiple instances of the same attribute
in request context?  Attribute currently has exactly one attribute value
(which is a bad outage in my opinion - we need to be able to  bags) -
but is it prohibited to have multiple attribute with the same
attributeId?

In request:
<resource>
	<Attribute AttributeID = "foo" DataType = "string">
		<AttributeValue >bar</AttributeValue>
	</Attribute>
	<Attribute AttributeID = "foo" DataType = "string">
		<AttributeValue >spam</AttributeValue>
	</Attribute>
<resource>

Would not that define bag[string]   foo = ["bar", "spam"] ?


Of cause defining "bag" metadata along with datatype, and supplying
multiple
<AttributeValue>'s is much better.

Remind me - why do we not send bags in a request?




-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] 
Sent: Tuesday, May 11, 2004 12:36 PM
To: Daniel Engovatov
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] Hierarhical resources.. part 0.1

The problem is that you described a single attribute whose value
would be a bag containing one member for each ancestor of the
requested node:

  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.

Assume you are requesting access to node "file://host/aaa/bbb/ccc".
The ancestors are "file://host/aaa" and "file://host/aaa/bbb".

We have no syntax for expressing this in a single
<xacml-context:Attribute>.  Neither of the following work:

  <Attribute AttributeId="resource-ancestors" DataType="bag[anyURI]">
      <AttributeValue>
           file://host/aaa,
           file://host/aaa/bbb,
      </AttributeValue>
  </Attribute>

  <Attribute AttributeId="resource-ancestors" DataType="bag">
      <AttributeValue>
           <AttributeValue
DataType="anyURI">file://host/aaa</AttributeValue>
           <AttributeValue
DataType="anyURI">file://host/aaa/bbb</AttributeValue>
      </AttributeValue>
  </Attribute>

I.e. there is no DataType "bag[anyURI]":

Assume, however, that you defined some such datatype for
expressing "bag of anyURI".  The result of evaluating

  <ResourceAttributeDescriptor AttributeId="resource-ancestors"
                               DataType="bag[anyURI]" />

will not be a 2-element bag containing "file://host/aaa" and
"file://host/aaa/bbb", but instead will be a 1-element bag containing
a value that is a 2-element bag:

     <AttributeValue DataType="anyURI">file://host/aaa</AttributeValue>
     <AttributeValue
DataType="anyURI">file://host/aaa/bbb</AttributeValue>

which is a bag of bags.  This is not defined in XACML and we have
no functions that can deal with it.

But, if you specify this as:

  <Attribute AttributeId="resource-ancestor" DataType="anyURI">
      <AttributeValue>file://host/aaa</AttributeValue>
  </Attribute>
  <Attribute AttributeId="resource-ancestor" DataType="anyURI">
      <AttributeValue> file://host/aaa/bbb</AttributeValue>
  </Attribute>

Then evaluating 

  <ResourceAttributeDescriptor AttributeId="resource-ancestors"
                               DataType="anyURI"/>

returns a single bag containing two elements of type anyURI:

   file://host/aaa

and

   file://host/aaa/bbb

which is just what you want.

Anne

On 11 May, Daniel Engovatov writes: RE: [xacml] Hierarhical resources..
part 0.1
 > From: Daniel Engovatov <dengovatov@bea.com>
 > To: Anne.Anderson@Sun.COM
 > Cc: xacml@lists.oasis-open.org
 > Subject: RE: [xacml] Hierarhical resources.. part 0.1
 > Date: Tue, 11 May 2004 11:45:20 -0700
 > 
 > >RESOURCE-ANCESTORS: One important difference is that there can't
 > >be a single "resource-ancestors" Attribute.  We do not allow
 > >"bags of bags", and have no functions for operating on them.
 > 
 > 
 > Actually - that is the whole idea that "ancestors" is a single bag.
 > It is not a bag of bags.  It is a bag or URI - all ancestor resources
 > fully flattened out and unordered.   I think that is the least common
 > denominator
 > Structure to accommodate different hierarchical topologies and avoid
 > Reconstruction/circular connection problems.
 > 
 > It seems to me that it works just fine as I described - I do not
 > understand why would be want bag of bags?
 > 
 > 
 > 
 > >REQUESTS FOR MULTIPLE NODES: On the topic of requests for
 > >multiple nodes in one Request, I think we all agree that the
 > ><Result> elements must be equivalent to those obtained by
 > >evaluating access to each node independently.  For this reason, I
 > >don't think the "scope" Attribute or a "resource-id" Attribute
 > 
 > I agree.  
 > 

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