Re: [xacml] Issue 40: <ResourceContent> element

[Anne Anderson <Anne.Anderson@sun.com>]

The intent was to support requests to access multiple resources under 
the same "situation" - i.e. a particular subject wants to perform an 
action on multiple resources (could be multiple resources from a 
hierarchy, for example).  This grew out of our "scope" attribute that 
allowed one to treat a hierarchical resource as a tree of individual 
resources.

That said, here are some options:

1) Multiple individual requests: Support bundling multiple individual 
requests into a single package.  This means having to repeat all the 
subject, action, and environment Attribute groups in each request.

2) Multiple arbitrary individual Attribute groups: Generalize the 
existing model so that one can have multiple subject, resource, action, 
and environment Attribute groups, where the PDP evaluates each possible 
combination as a separate request.  We would have to create an element 
to group subject Attribute groups that belong to the same situation (i.e 
different SubjectCategory values that are associated with a single request).

3) As is: only multiple resource Attribute groups are allowed, as this 
seems to be the most common case.  If you want multiple requests for 
subjects, actions, or environments, you have to make separate requests.

I have not seen many use cases for anything other than 3).

Regards,
Anne

Daniel Engovatov wrote:

> Would not it be more natural to change the multiple resource profile to
> include multiple requests, rather then multiple instances of the same
> resource category?
> 
> For example if you want to represent your "resource" with two categories
> - for example "static-resource-attributes" and
> "dynamic-resource-attributes", coming from different paths, you would
> have to choose which one would contain your "content".  Also, for most
> attribute categories, content is an evil construct, that goes against
> the whole idea of representing evidence in the context as a bag of named
> attributes, rather then an opaque XML "any" object.
> 
> So, maybe we should go and create a top level <Requests> element, that
> contains multiple requests, to use in the multiple resources profile?
> 
> Daniel.
> 
> -----Original Message-----
> From: Erik Rissanen [mailto:mirty@sics.se] 
> Sent: Friday, February 02, 2007 6:17 AM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] Issue 40: <ResourceContent> element
> 
> All,
> 
> I've been editing the 3.0 core and I have found a small problem with the
> proposal Daniel made for the ResourceContent element. See issue 40 on
> the issues list.
> 
> If I understand the proposal correctly, the <ResourceContent> element
> which used to be in the <Resource> element of the request context is
> replaced with a number of <Content> elements directly in the <Request>
> element.
> 
> This is not quite backwards compatible with 2.0 and the multiple
> resources profile. The multiple resources profile allows multiple
> <Resource> elements, which may contain <ResourceContent> elements:
> 
> <Request>
> ...
> <Resource>
> ...
> <ResourceContent>...</ResourceContent>
> </Resource>
> <Resource>
> ...
> <ResourceContent>...</ResourceContent>
> </Resource>
> ...
> </Request>
> 
> If we follow the current proposal, this becomes:
> 
> <Request>
> ...
> <Attributes Category="...:resource>
> ...
> </Resource>
> <Attributes Category="...:resource>
> ...
> </Resource>
> ...
> <Content>...</Content>
> <Content>...</Content>
> </Request>
> 
> and the connections to the specific resources are lost. Instead I
> suggest that we place the <Content> element inside the <Attributes>
> element:
> 
> <Request>
> ...
> <Attributes Category="...:resource>
> ...
> <Content>...</Content>
> </Resource>
> <Attributes Category="...:resource>
> ...
> <Content>...</Content>
> </Resource>
> ...
> </Request>
> 
> In this case it is simpler to provide backwards compatibility.
> 
> BTW, talking about backwards compatibility of attribute selectors,
> translating 2.0 policies into 3.0 means rewriting the xpath expressions
> in attribute selectors since the <Resource> element is now called
> <Attributes>. Are there any concerns about this? For simple expressions
> it is obvious how to do it, but what about in general?
> 
> Another minor issue is that the schema which Daniel wrote earlier does
> not allow anyAttribute on the Content element, which the old one did.
> This could be a problem with backwards compatibility, so I suggest we
> allow that.
> 
> Finally, I think the examples in the 2.0 spec are wrong. On page 31,
> line a217 the xpath expression looks like
> "//xacml-context:Resource/...."
> while it on page 34, line a290 looks like "//md:record/...". As far as I
> can tell, the latter is wrong. Right?
> 
> 
> Best regards,
> Erik
> 
> 
> 
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.

-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA