xacml-users message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Clarification of Hierarchical Resource Profile
- From: "Steve Bayliss" <stephen.bayliss@acuityunlimited.net>
- To: <xacml-users@lists.oasis-open.org>
- Date: Wed, 19 Jan 2011 16:40:01 -0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]