Clarification of Hierarchical Resource Profile

["Steve Bayliss" <stephen.bayliss@acuityunlimited.net>]

Title: Message

Hi

 

I'm seeking to clarify my understanding / the intent of the Hierarchical Resource Profile.  Primarily XACML 2.0, but I understand that 3.0 mainly refines and adds clarity, so anything from 3.0 that's relevant in this respect I am interested in.

 

I'm iinterested in the hierarchical path representations of non-XML nodes, ie 2.0 spec lines 190 et seq.

 

My question is if the Hierarchical Resource Profile deals (is intented to deal with) with resources-in-path-context.  That is, if a resource belongs to multiple hierarchies/has multiple parents/ancestors, can a policy be written for this resource-in-path-context.  (to put it another way, policies dealing with resources when being accessed as part of a particular collection having a specific policy, rather than a resource being accessed, and because it is a member of - rather than being accessed in the context of being a member of - having a specific policy).

 

Example paths for a resource "c" (ignoring the fact these aren't URIs, I gather this restriction was relaxed in 3.0)

/a/b/c

/x/y/c

 

According to the spec, a request for resource c should result in two separate resources in the request context, a resource-id with value /a/b/c and a resource-id with value /x/y/z - is that correct?

 

And two different policies, one specifying (as URI regex match) /a/b/.* and the other /x/y/.* would both match?

 

Is it also permissible for the incoming request to the PEP to specify the full path, for instance to state that resource c is being accessed in the context of collection b which is a member of collection a?  Thus only the first policy would match?

 

That is, because a full resource-id is already present then the engine shouldn't go away and build the paths.

 

And is it conceivable that both forms could exist together?

 

For instance, if there was a resource attribute of object-ID, and it is defined that resource-id is formed of the full path to object-ID then we could have

 

Request one:

specifies resource object-id = "c"

result: engine builds all applicable paths to "c" - ie two separate resources with their own resource-id (so both above policies match)

 

Request two:

specifies resource-in-path-context, specifying resource-id directly as "/a/b/c"

result: engine does not build resource-id and only the first policy matches

 

Any guidance on this appreciated.  My reading so far of the specs suggests that the Hierarchical Resource Profile isn't intended for resource-in-path-context (or resource-accessed-as-member-of-collection).

 

Thanks

Steve