is most useful, so thank you for your insight. It's prompted me to read
through both the 2.0 and 3.0 HRP specs again in some detail.
terms of being more specific, a use-case I am thinking of is a hierarchy where
policies are applied at different levels in the hierarchy, with the lower-level
policies overriding higher-level ones.
made-up example would be a single hierarchy:
1 states "allow read access to Subjects with an attribute value of 'public' to
all descendents of 'a'" (so a policy resource-id regex of
2 states "deny read access to Subjects with an attribute value of 'public' and
an IP address of 'x.x.x.x' to all descendents of 'b' (ie regex
request for "d" from a Subject 'public' with IP address "x.x.x.x" should result
in a "deny" based on Policy 2 overriding Policy 1.
PDP implements a "lowest policy wins" algorithm. Using the path URI resource-id
profile means the PDP has the full information, on a request for 'd', to
determine that (1) both Policy 1 and Policy 2 apply and (2) Policy 2 takes
precedence (the deny overrides the allow) as it is at a lower level in the
context of that particular hierarchy.
leaving aside the question of what algorithm should be used to combine policies
across multiple hierarchies!)
distinction I was assuming existed between the URI path and the parent/ancestor
attributes was the loss of some information of structure of the hierarchy in the
focussing now on a single hierarchy example
What I had assumed:
A request for "d" would result in the following path
URI (as resource-id attribute), eg:
following ancestor/parent attribute values
Thus if using
the ancestor/parent attribute method, the PDP doesn't have the information
to determine which of the two policies takes precedence (both a and b are
ancestors, but it's not expressed that a is an ancestor of b). (That's not
to say it couldn't go elsewhere to gain information on the hierarchical
structure of the resources and therefore the policy precedence - perhaps that
should be the approach rather than determining the hierarchy from the request
context resource-id attributes?)
What I think you are suggesting is that the
parent-id and ancestor-id values are values that themselves express their own
position in the hierarchy, ie
So in this case the structure is not lost (and I see
the equivalence to the path URI method).
I need to go through the pseudo-code algorithm in some
more detail, particularly to understand what the "output" would look like in
terms of part of a XACML request context (ie the resulting
There are parts of the 3.0 spec that do seem to suggest
that the parent/ancestor method could convey less information than the path URI
2.3: In this approach, considerable
information is discarded. It is not possible to determine how many hierarchies
there are or which ancestors are in which hierarchies or the relative position
of ancestors other than immediate parents.
representations of the identities of these parents, ancestors, or self will not
necessarily indicate the path from the root of the hierarchy to the respective
parent, ancestor, or self unless the representation recommended in Section 3.2:
Nodes in a resource that is not an XML document is used. [ie the path URI
From 4.1 it would seem that
the values used for the ancestor/parent attribute values could in fact
be resource-id values that use the path URI method. So no information
is lost. However this seems to be at odds with the assertion in 2.3
(although noting that the attribute values "... may be identified using
identifiers of any XACML datatype ..."; so there is nothing to preclude usage of
path URIs for these... in which case no information is
So overall I am left a little
confused as to the intent of the specification in this respect. Using path
URIs for ancestor and parent attribute values seems like a merging of the two
Though I guess the datatypes
of the ancestor and parent attributes don't have to be path URIs in terms of the
spec, but could be some other datatype that expresses the hierarchical
Generally, I think your question needs to get more specific,
of the inherent flexibility of the URI/hierarchical mechanism, imo,
needs to understand what one is trying to achieve in order to
define an optimum strategy. I will take an initiial shot w
responses in line.
Steve Bayliss wrote:
Agree. The important thing is the
path itself, not which module navigated the path.
Many thanks for this, this greatly clarifies my
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
Personally, I do not see a
significant distinction between the "URI profile" and the
One further quesion (at this stage!):
Would it be possible to
in the Request Context, use the hierarchical URI profile; and at the same
in policies use the parent/ancestor attribute
attribute profile", which I see as effectively being
equivalent, with the distinction that the URI is a special
case of the parent/ancestor attribute,
where the special case is that the
URI has a defined syntax.
So, depending on how one approaches the
problem, or specifically how one goes about
"naming" the resources, steps 1
and 2 as you describe may not be significantly distinct.
if you start with a collection of resources, and each has a unique
such as a serial number, or a social security number, there is
only a "1-level" hierarchy,
the collection, itself, is the parent and each
individual resource is a child of that parent,
with no inherent relation to
any of the other members of the collection.
The next step is maybe you
want to "structure" the membership of the collection in
some manner so that
the members have relations to each other. At this point it is
define the "relation" and how the "relation" is established between
members. Once this relation is defined, then it makes sense to start
how policies are applied to the collection.
you organize them in a single rooted hierarchy such that each member
single parent and all members have some parent. Now you have the
of a file directory, where each file has a name and it is also a
member of a directory
in a hierarchy of directories.
scenario, then what is your question 1 and 2? I would assume I would
the dir-path/filename as the resource-id. The list of ancestors is nothing
than a succession of truncated dir-paths. So is the question whether
"/a/b/filename" as resource-id, vs "/filename" as resource-id plus
"/a/b" and "/a"
as ancestor attributes? Since the latter can be derived
from the former, what is
Is the parsing of
"/a/b/filename" vs "/a/b/.*" more expensive than doing bag operations
ancestors? I honestly have no idea. It may depend on the implementation
the engine. It may depend on how large the collections are that are
I would look to the engine supplier to provide guidance on
how to use these capabilities,
and possibly suggest situations where one or
the other would be optimum.
Personally, I think this is a level of
detail that policy designers should not be concerned
about unless there is
some macro characteristic that they can relate to which will guide
The comments above should
address, but not necessarily fully answer the "much easier" question you are
I'm 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
Again, depending on what you are
trying to accomplish, the importance of which hierarchy a node's parent
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
to may or may not be important. As the algorithm in XACML 3.0
shows, one actually has to go out of one's way
to effectively remove the
specific hierarchy identifier of each parent, at least, if you represent the
by a single column in the n+1 columns of n
hierarchies and 1 resource-id as in the algorithm. And as indicated in
algorithm, if you start with a DAG, then you must have m columns, where m is
the max number of parents any
single member of the DAG has, and if a new
parent is added to an m-parent node, then just add a new column
table and increase the DAG width to m+1.
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 Policy
- 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
where /a/b and /x/y are "steps" the user takes thru the
applicable to any resource prefixed with "file:///a/b"
A similar match statement could be prepared with "file:///x/y/.*" to match any
prefixed with "file:///x/y".
These match statements
can be combined within a Resource statement to create an "AND",
combined within 2 separate Resource statements to create an
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
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
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
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
transform that information to an appropriate set of attributes.
additional attributes are required they can be obtained via the
by using the MissingAttributesDetail technique.)
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
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.
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
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
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
the other for "/x.*") within a single Resource element.
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
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,
identifier of the parent of the current resource is assigned to create the
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
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
be more correct to say something like "the Attribute with
AttributeId = "...resource-id" generally
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
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
I hope this goes someway to clarify the
questions I was attempting to pose in my original
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
move the ball down the field a bit.
Steve Bayliss wrote:
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
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 referring to?
answer to the first part of the question is "Yes, a policy can be
written for it.".
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
I do not
understand the above statement at all. The first phrase appears to use
the term policy redundantly:
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).
"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
will help to establish a terminology where the issues
can be addressed. That being said, the last phrase appears
to me to
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
- 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
- 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.
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
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
propose would appear.
It is ok to specify only one
path in the request, but it depends on the Policy structure whether
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
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
because a full resource-id is already present then the engine
shouldn't go away and build the
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
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
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
specifies resource object-id = "c"
engine builds all applicable paths to "c" - ie two separate
resources with their own resource-id (so both above policies
My assumption is that all required info is in the
request context. If all that is there is "c" then how does
derive full paths?
Correct, but see comment
above. It depends if Policy requires resource to be member
specifies resource-in-path-context, specifying resource-id
directly as "/a/b/c"
engine does not build resource-id and only the first policy
hierarchies or only one hierarchy.
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
least in the context of the HRP. The HRP is intended
single nodes in a hierarchy, and to also consider using the Multiple
for defined "scopes" of nodes within a