I find your explanation much easier to understand now. It sounds like:
I think the following Policy elements placed in a Target would make the
- there is one underlying "physical" resource, "c", that can be
- by application "A" by navigating via /a/b/c
- or by application "X" by navigating via /x/y/c
- basically "A" presents user with /a/b/c,
and "X" presents user with /x/y/c
where /a/b and /x/y are "steps" the user takes thru the appls
applicable to any resource prefixed with "file:///a/b"
A similar match statement could be prepared with "file:///x/y/.*" to
match any request
prefixed with "file:///x/y".
These match statements can be combined within a Resource statement to
create an "AND",
or combined within 2 separate Resource statements to create an "OR".
Also, I have added a prefix "file://" in order to make these proper
URIs, but will not
use it below. The point is while the example does not use full URI
syntax, there is no
reason why it can't, and we will just assume it is shortened for
I think the rest of my comments can now go in line.
Steve Bayliss wrote:
The first (and only) ResourceMatch element above I think is what such a
Policy would need
Many 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
In both scenarios there is a resource c
that is present in two hierarchies:
And in 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 c.
The user browses starting at "x", and
locates the resource under the hierarchy /x/y/c
Is it 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
to contain to match the "/a/b/c" path.
That is much more clear now, thanks.
(This is what I was attempting to express
with "resource-path-in-context", the context being the route a user
took to locate the resource.)
Agree, the general assumption is that the PEP is able to collect
information about the
The application's PEP would be able to
supply the browsing path in the request context.
request and transform that information to an appropriate set of
(If additional attributes are required they can be obtained via the
by using the MissingAttributesDetail technique.)
I believe so. It appears to me to be a perfect fit.
Is this something that the Hierarchical
Resource Profile is suited to?
I don't think it is necessary for an additional "navigation path"
attribute. I think the navigation
Or should this "navigation path" should be
a separate attribute outside of those specified in the Hierarchical
path makes for a perfectly good resource-id.
The only distinction I can think of right now is that a "navigation
path" in the sense of tracing everything the user
I can 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.
has been doing may have redundant info. However if the "navigation
path" removes backsteps, then I think it
is effectively equivalent to the URI path, which is a legitimate
Am I missing something here?
Presumably, within this particular example there are only the two paths
available. In any event, even if there
The user browses to the resource c. It is
irrelevant from a policy perspective of how they navigated to the
were more paths, the profile should work just as well.
This sounds like it could be done with an "AND" of the two
ResourceMatch elements (one for "/a.*",
Two 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 "c".
and the other for "/x.*") within a single Resource element.
Agree, but also think scenario 1 is just as applicable.
It seems that this is suited to the
Hierarchical Resource Profile.
The algorithm in HRP XACML 3.0 section 3.3.1 shows how resource-ids can
be constructed given a list
It would be the responsibility of the
Context Handler to provide two hierarchical resource-id attributes.
of unique resource identifiers (can be a simple integer starting from
zero and incremented for each resource
that is added to the collection). This "list" can be regarded as
"column 0" of the "resource map".
For each hierarchy applied to the collection an additional column is
created for the map. Within the column,
the resource identifier of the parent of the current resource is
assigned to create the hierarchy.
The context handler can use this map to create all the resource-ids
needed for the resource.
I agree the "ancestor scheme" can be used here. Personally, I think the
URI scheme is sufficient for
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.
the use cases I have considered to date. I think it is just a matter of
how the information is viewed
as to which approach is preferable.
With the DAGs, I think the URI would not work very well, if at all
since there are no definitive
unambiguous URIs that can be constructed. So, if resources are viewed
as DAG, then should
use ancestor approach. Same algorithm in 3.3.1 is applicable.
Yes, that is correct, and it is allowed as specified in XACML 2.0
section 6.3 lines 2947-2954,
To help my understanding of the difference
between the URI scheme and the "ancestor scheme":
- If 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 path.
and XACML 3.0 generally Attributes can contain multiple
AttributeValues. It probably would
be more correct to say something like "the Attribute with AttributeId =
can contain multiple AttributeValue elements with different values".
- If 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.
Yes, although, this probably is only relevant to DAGs, and is
superfluous for any number of single parent hierarchies.
- Instead resource-parent, resource-ancestor
and resource-ancestor-or-self attributes are used to represent this
Yes, I think we are in agreement, assuming my comments are consistent
with what your
The "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.
I hope this goes someway to clarify the
questions I was attempting to pose in my original post.
statements are intended to mean.
Not sure if I fully understand your questions, but will try to respond
my first few responses are attempting to understand your question, the
responses are probably closer to being in the answer space of your
I do not expect that this will fully answer your questions but
hopefully it will
move the ball down the field a bit.
Steve Bayliss wrote:
I am having trouble parsing the following paragraph. I will deal with
each segment in sequence:
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.
iinterested in the hierarchical path representations of non-XML nodes,
ie 2.0 spec lines 190 et seq.
The sentence above appears to be asking the question:
question is if the Hierarchical Resource Profile deals (is intented to
deal with) with resources-in-path-context.
Does the HRP deal with "resources-in-path-context"?
If that is the question, then what does the term
"resources-in-path-context" mean? For example,
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.".
is, if a resource belongs to multiple hierarchies/has multiple
parents/ancestors, can a policy be written for this
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 redundantly:
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
"policies (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,
will 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
- a resource being accessed because it is a member of (a
- a resource being accessed in the context of being a member
of (a specific collection?)
Ok, assuming the above URI pathname portions plus leading "/" are
provided as resource-ids (where multiple resource-ids
paths 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 paths.
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 XACML 3.0.
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.
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
two 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 would
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 /x/y/.* ), or
/a/b/.* OR /x/y/.* )
Sorry, I am not sure what you are trying to say here. There is no
requirement on the engine to use any
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
is it conceivable that both forms could exist together?
co-exist. Is that a concern?
I'm afraid you are going to have to be more specific here about what
information is being processed.
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
resource object-id = "c"
engine builds all applicable paths to "c" - ie two separate resources
with their own resource-id (so both above policies match)
My assumption 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 "/a/b/c"
engine does not build resource-id and only the first policy matches
of both hierarchies or only one hierarchy.
Again, I am not sure what the term "resource-in-path-context"
precisely means or the alternate phrase:
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).
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
for defined "scopes" of nodes within a hierarchy.