[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Hierarhical resources.. part 0.1
On 11 May, Daniel Engovatov writes: RE: [xacml] Hierarhical resources.. part 0.1
> 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"] ?
It is perfectly legal to have multiple Request Attributes with
the same AttributeId.
Also, we have already decided to define
<Attribute >
<AttributeValue>val1</AttributeValue>
<AttributeValue>val2</AttributeValue>
<AttributeValue>val3</AttributeValue>
</Attribute>
as equivalent to:
<Attribute >
<AttributeValue>val1</AttributeValue>
</Attribute>
<Attribute >
<AttributeValue>val2</AttributeValue>
</Attribute>
<Attribute >
<AttributeValue>val3</AttributeValue>
</Attribute>
so, yes, that is an alternative way to specify the multiple
values for "resource-ancestor" and "resource-parent" Attributes.
>
>
> 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?
1) We do not have functions to operate on bags of bags, if that
is what you are asking
2) We already have syntax for sending "bags" in the request, if
you are just asking for an <AttributeDescriptor> or
<AttributeSelector> that evaluates to a "bag": they always
evaluate to a bag that contains one element for each Attribute
or nodeset node that matches. See above.
Polar can probably give you more reasons :-)
Anne
> -----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
>
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]