thanks for your response. I realise my questions are not clear, I was
struggling myself with how to phrase them, and my terminology is rather loose in
places. Perhaps the best approach is for me to step back and outline
two distinct scenarios; particularly to address what I was trying to
express with "resources-in-path-context".
both scenarios there is a resource c that is present in two
both scenarios, there is a user application that allows a user to browse through
the hierarchies to locate the resource. The user could browse by starting
at the top of either hierarchy (a or x) to locate the resource
user browses starting at "x", and locates the resource under the hierarchy
possible to write a policy that applies based on which hierarchy the user
navigated to locate the resource, ie a policy that applies to their browsing
path of /x/y/c, so that the policy would apply if they had browsed through
x->y->c but would not apply if they had browed to the resource through
is what I was attempting to express with "resource-path-in-context", the context
being the route a user took to locate the resource.)
application's PEP would be able to supply the browsing path in the request
this something that the Hierarchical Resource Profile is suited to? Or
should this "navigation path" should be a separate attribute outside of those
specified in the Hierarchical Resource Profile?
see how a policy could be written using a "navigation path" attribute, my
question is whether the scenario is relevant to/better implemented with the
Hierarchical Resource Profile, using the resource-id attribute to represent the
navigational path used by the user.
user browses to the resource c. It is irrelevant from a policy perspective
of how they navigated to the resource.
separate policies are to be written, one for all resources that are descendents
of "a", and another for all resources that are descendents of "x". Both
policies should be applied when the user requests resource
seems that this is suited to the Hierarchical Resource Profile. It would
be the responsibility of the Context Handler to provide two hierarchical
Policies could be then written using (URI regex match)
/a/.* and /b/.* (or indeed separate rules as you suggest). Alternatively
the "ancestor scheme" could be used as you suggest, in which case the Context
Handler would provide the resource-parent, resource-ancestor,
resource-ancestor-or-self attributes (and the policy would be written in terms
of these rather than a resource-id regex match.
To help my understanding of the difference between
the URI scheme and the "ancestor scheme":
the URI scheme is used, the resource-id attribute is a URI specifying the
hierarchical path to the resource. Multiple resource-id attributes would
be present if the resource is to be found under more than one
the "ancestor scheme" is used, the resource-id does not have to be a URI, and
does not have to contain any information about which hierarchies the resource
belongs to. Instead resource-parent, resource-ancestor and
resource-ancestor-or-self attributes are used to represent this
"relaxation" I thought I had identified for the resource-id in the URI scheme
was due to the 2.0 document stating (section 2.2) that "The identity of a
node in a hierarchcial resource ... SHALL be represented as a URI ...", whereas
the 3.0 document (again section 2.2) has "The identity of a node in a
hierarchical resource ... MAY be represented as a URI...". However on
re-reading the subsequent text in section 2.2 of the 3.0 spec, it now seems
clear to me that the resource-id must indeed be a URI.
this goes someway to clarify the questions I was attempting to pose in my
Sent: 20 January 2011
To: Steve Bayliss
Subject: Re: [xacml-users]
Clarification of Hierarchical Resource Profile
Not sure if I fully understand your questions, but will try to
respond inline. Note:
my first few responses are attempting to understand
your question, the later
responses are probably closer to being in the
answer space of your questions.
I do not expect that this will fully
answer your questions but hopefully it will
move the ball down the field a
Steve Bayliss wrote:
I am having
trouble parsing the following paragraph. I will deal with each segment in
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
in the hierarchical path representations of non-XML nodes, ie 2.0
spec lines 190 et seq.
above appears to be asking the question:
My question is
if the Hierarchical Resource Profile deals (is intented to deal with) with
HRP deal with "resources-in-path-context"?
If that is the question,
then what does the term "resources-in-path-context" mean? For
XACML Policy deals with information in the RequestContext. Is this
what you are referring to?
The answer to the first part of the question
is "Yes, a policy can be written for it.".
That is, if a
resource belongs to multiple hierarchies/has multiple parents/ancestors, can
a policy be written for this resource-in-path-context.
As above the term
"resource-in-path-context" is undefined, at least to me, so I do not
understand the last part of the question.
I do not understand the above
statement at all. The first phrase appears to use the term policy
(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
(dealing with resources when being accessed as part of a particular
collection) having a specific policy"The
remainder I find in more difficult to parse. My point here is not to criticize
your sentence structure, but to
try to understand what the point is you are
trying to make, and possibly by explaining why I find it confusing,
help to establish a terminology where the issues can be addressed. That being
said, the last phrase appears
to me to be saying:
There is some kind of distinction between:
Is this the point, that the above two
bullets are distinct in some manner?
- a resource being accessed because it is a member of (a specific
- a resource being accessed in the context of being a member of (a
Ok, assuming the above URI
pathname portions plus leading "/" are provided as resource-ids (where
for a resource "c" (ignoring the fact these aren't URIs, I gather this
restriction was relaxed in 3.0)
for the same resource are allowed as specified in
section 6.3), the two provided above seem like a reasonable pair of example
Note: I do not believe there was intentional "relaxation" in 3.0.
Note there are 2 non-XML node identification schemes in the HRP:
If the URI scheme is used the resource-id must be a URI.
If the ancestor scheme is used, then that is not a necessary condition.
- The URI scheme: section 2.2 (of both XACML 2.0 and 3.0)
- The "ancestor scheme": section 3.2 of XACML 2.0, and section 2.3 of
There is only
one resource, but it will have 2 resource-id's, so the answer to above is "no"
to the first part and "yes" to the 2nd part.
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?
There is no
requirement for two Policies, as opposed to say two Rules, but yes, it is
likely that both the regex's you
different policies, one specifying (as URI regex match) /a/b/.* and the
other /x/y/.* would both match?
propose would appear.
It is ok to specify only
one path in the request, but it depends on the Policy structure whether that
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?
be accepted or not. i.e. does the Policy state:
- ( /a/b/.* AND
- ( /a/b/.* OR
Sorry, I am not sure what you
are trying to say here. There is no requirement on the engine to use
That is, because
a full resource-id is already present then the engine shouldn't go away and
build the paths.
specific method for processing the above scenario.
I assume so, however, it sounds like
you may have a concern that for some reason both forms should not
And is it
conceivable that both forms could exist
Is that a concern?
I'm afraid you are going to have to be
more specific here about what information is being processed.
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
resource object-id = "c"
builds all applicable paths to "c" - ie two separate resources with their
own resource-id (so both above policies
is that all required info is in the request context. If all that is there is
"c" then how does one
derive full paths?
Correct, but see comment above. It
depends if Policy requires resource to be member
resource-in-path-context, specifying resource-id directly as
does not build resource-id and only the first policy
of both hierarchies or
only one hierarchy.
I am not sure what the term "resource-in-path-context" precisely means or the
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
"resource-accessed-as-member-of-collection", at least in
the context of the HRP. The HRP is intended
to represent single nodes in a
hierarchy, and to also consider using the Multiple Resource Profile
defined "scopes" of nodes within a hierarchy.