thanks for this, this greatly clarifies my understanding.
clarify one thing, "Scenario 1" may not be two user applications - it could be a
single user application which presents a number of different "browsing paths" to
resources. But I don't think that changes anything, so long as the
application's PEP constructs the browsing path the user navigated
further quesion (at this stage!):
it be possible to
the Request Context, use the hierarchical URI profile; and at the same
policies use the parent/ancestor attribute profile?
thinking here that from a perspective of indexing/finding policies, this would
be much easier to do based on parent/ancestor attributes rather than for
instance decomposing a resource-id regular expresssion (which may specify a
range of possibilities, such as a path /a/b/.*, specifying "all resources under
b when b is under a", and ".*/b/.*" specifying "all resources under b
irrespective of b's parentage").
However it may be useful to still include the resource-id in the request
as this specifies the complete ancestor lineage, which could be useful for
instance in a custom policy combining algorithm which had some rules about
policy precedence based on the position in the hierarchy - for example child
policies have a precedence over parent policies.
I find your explanation much easier to understand now. It sounds
I think the following Policy elements placed in a Target would make
- there is one underlying "physical" resource, "c", that can be obtained
- 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
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 convenience.
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
both scenarios there is a resource c that is present in two
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
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
contain to match the "/a/b/c" path.
That is much more clear
(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.)
the general assumption is that the PEP is able to collect information about
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 ContextHandler or
by using the MissingAttributesDetail technique.)
I believe so. It appears to me to be a
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
should this "navigation path" should be a separate attribute outside of
those specified in the Hierarchical Resource
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
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
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 resource-id value.
Am I missing
Presumably, within this particular
example there are only the two paths available. In any event, even if
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
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.
seems that this is suited to the Hierarchical Resource
algorithm in HRP XACML 3.0 section 3.3.1 shows how resource-ids can be
constructed given a list
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
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.
context handler can use this map to create all the resource-ids needed for the
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
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.
DAGs, I think the URI would not work very well, if at all since there are no
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 correct, and it is allowed as specified in XACML 2.0 section 6.3 lines
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 = "...resource-id" generally
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
- 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.
hope this goes someway to clarify the questions I was attempting to pose in
my original post.
are intended to mean.
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
ball down the field a bit.
Steve Bayliss wrote:
I am having
trouble parsing the following paragraph. I will deal with each segment in
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.
sentence above appears to be asking the
is if the Hierarchical Resource Profile deals (is intented to deal with)
Does the HRP deal with
If that is the question, then what
does the term "resources-in-path-context" mean? For example,
Policy deals with information in the RequestContext. Is this what you are
answer to the first part of the question is "Yes, a policy can be written
That 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
(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
"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 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
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
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
- 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.
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
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.
is ok to specify only one path in the request, but it depends on the
Policy structure whether that would
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
- ( /a/b/.* AND
/x/y/.* ), or
- ( /a/b/.* OR
Sorry, I am
not sure what you are trying to say here. There is no requirement on the
engine to use any
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
I assume so, however, it sounds
like you may have a concern that for some reason both forms should
And is it
conceivable that both forms could exist
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
resource object-id = "c"
engine builds all applicable paths to "c" - ie two separate resources
with their own resource-id (so both above policies
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
engine 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 alternate phrase:
on this appreciated. My reading so far of the specs suggests that
the Hierarchical Resource Profile isn't intended for
"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
for defined "scopes" of nodes within a hierarchy.