Hi Rich
Thanks for your continued attention
to this. As you suggest I think a more specific example is
needed.
So to clarify further, I'll attempt
to make the scenario a little more concrete.
The resource hierarchy in question
is
/a/b/c/d
The request coming in from the PEP is
for resource "d". The request context from the PEP does not specify the
position of "d" in the hierarchy, only the resource identifier "d".
Two policies exist, written using the
ancestor scheme:
permit-descendents-of-b: -
Resource attribute - ancestors: bag{b} - Rule effect is Permit
deny-descendents-of-c: - Resource
attribute - ancestors: bag{c} - Rule effect is Deny
(Thus making the policies independent
of the actual hierarchy; the semantics of the
policies are by intent that the first applies to descendents of "b" and the
second to descendents of "c" irrespective of their hierarchical relative
positions)
I was envisoning (numbers refer
to Chapter 3, Figure 1 in the
spec):
1) When the request comes in to the
context handler (3), it does an attribute query (6), and adds the
attributes: - path scheme resource-id: file:///a/b/c/d (PIP dynamically determines
current hierarchy) - ancestor scheme attributes: -- ancestors:
bag{a,b,c} -- ancestors-or-self: bag(a,b,c,d} -- parent: c -- self:
d
These
resource attributes are then present in the request context passed to the
PDP.
2) The PDP is able to evaluate which policies match, by comparing the
ancestor scheme attributes from the request context with the resources specified
in the policies through the ancestor
scheme (the path scheme resource-id from the request context is not required for
this)
3) The hierarchical-lowest-wins
policy combining algorithm is able to determine the precedence of the
policies by inspecting the path scheme
resource-id from the request context, which specifies the
hierarchy
4) The overall response is "Deny", as
deny-descendents-of-c is lower in the hierarchy than
permit-descendents-of-b
5) If the hierarchy
were then restructured to be
/a/c/b/d, the decision would then be "Permit" as now it can be
determined (by the combining algorithm)
that policy permit-descendents-of-b is lower in the hierarchy and
therefore takes precedence (in this case the path
scheme resource-id would be file:///a/c/b/d)
I think in principle this is not
significantly different to what you were suggesting, but in your case the
hierarchical path would be determined
when the PDP evaluates the policies as
the presence of the custom hierarchy attribute in the policies would trigger an attribute
request. In my scenario the hierarchy is already present in the request
context passed by the context handler to the
PDP.
If the
usage of the path scheme resource-id isn't appropriate to the above, then
maybe a custom dynamic attribute could be substituted in the above
description.
I hope this clarifies my thinking on
this.
As a completely different
approach: Would it be acceptable for the implementation of the
hierarchical-lowest-wins policy combining algorithm to have some mechanism to
dynamically be able to determine the hierarchy directly? Thus avoiding the
need for any path scheme attributes entirely; with the precedence being
determined internal to the algorithm through this dynamic determination of the
hierarchy?
Thanks again
Steve
Hi
Steve,
Responses inline.
Rich
Steve
Bayliss wrote:
Hi
Rich
So
the objective here is to ensure that the (potentially dynamic) hierarchical
information gets through to the PDP so that hierarchical policy combining
algorithms can use this information. Yes and
no. Yes to the first part: i.e. if you have a dynamic hierarchy, then you need
a mechanism to let the PDP know the current state in order to apply the
ancestors method. i.e. if you are comparing the ancestors of the requested
resource with ancestors of nodes in a hierarchy where Policy has been
applied, and the hierarchy has changed, then the ancestor associated with node
where the Policy has been applied may have changed, then the Policy,
itself, needs to be able to get the ancestors that are associated with the
current state of the hierarchy.
No to the second part because the
policy combining algorithms just combine results of policy evaluation, and
would seem to be relatively far removed from the dynamics that were
introduced by the attribute finder to enable each policy to be evaluated
with dynamic information. i.e. I see no connection between the attribute
finder mechanism and the policy combining algorithms, they are involved at
different steps in a well-defined sequence of processing steps defined by the
XACML processing rules, see ch 7 and possibly the combining algorithms in
the appendix.
To
clarify, would the policy still be written using the hierarchical
ancestor/parent attributes? In one of your
earlier emails, you indicated you thought the ancestor scheme might be
useful for performance reasons. As a result, my responses have been to try
to apply the ancestor scheme to the use cases you have been describing. So,
yes, I am envisioning that all your policies that we are discussing are
written using ancestor techniques, and not relying on the node names at all
to inherently represent hierarchical position.
You say that the policy would look for the new "descendents-of-a"
attribute - so does this mean that the policy also has to reference this
"descendents-of-a" attribute to trigger the MissingAttribute
behaviour - if so, how? By specifying it in the
Resource section of the policy? That seems
like a reasonable place to put it. It needs to be defined with
MustBePresent="true" in order to guarantee missing attribute processing to
be invoked. Or, in the case of SunXacml, this will trigger the context
handler to invoke attribute finders to try to find the attribute somewhere
else, and, if found, to add it to the RequestContext to allow the
policy evaluation to continue with the attribute now being present.
As
an alternative approach, would the following seem
reasonable:
-
the context handler is written to both provide the resource-id hierarchical
URI path attribute and the hierarchical ancestor/parent attributes for the
requested resource One can construct a
"resource-id hierarchical URI path attribute", however, this might be
stretching the concept of URI a bit, as well as resource-id, as I think these
are generally thought to be of more static character. However, as a
snapshot at a point in time of a dynamic hierarchy, it might not be
unreasonable. I am sure there are people who could argue both positions at
length. :)
-
the policy is written in terms of resource ancestor/parent attributes (for
this use case specifying a single "ancestors: bag{'b'}") (and standard
policy matching can therefore match the policy resource specification
against the request context - using the hierarchical ancestor/parent
attributes) I am not sure I understand this.
If the policy is written in terms of ancestor/parent attributes, then this
sounds like a static representation of the hierarchy. i.e. any explicit list
of ancestors is by defn static, and if the hierarchy is dynamic then the
static list may become obsolete at any time.
-
the PDP has the hierarchical structure (from the resource-id in the request
context), and can use this to determine hierarchical precedence when
combining policies I am not following this
either. I agree that the RequestContext is providing the
current hierarchical structure for the requested node, but I don't see how
the policies themselves can provide anything to compare current
hierarchical structure to. At least not without the dynamic mechanism I
suggested above and prev emails.
I think to resolve this one would need
to lay out a specific example of both approaches and see what is being
compared to what.
Rich
Thanks
Steve
Hi Steve,
I think that, in general,
when we talk about "restructuring the hierarchy", that we are, in fact,
creating a "new hierarchy", at least in the sense that any
existing representation of that hierarchy has become obsolete and needs
to be updated.
In particular, if a Policy, such as the ones we have
been discussing, have static Attributes containing their list of
ancestors, etc. then those static Attributes are no longer
valid.
Therefore, if we want a Policy to be able to "keep up" with
external changes that are applied to the hierarchy, then some dynamic
mechanism needs to be implemented in order to give the Policy access to
the updated representation of the hierarchy.
One way to approach
this would be to define a dynamic Attribute with AttributeId
= "descendants-of-a", that the Policy would look for in the
RequestContext. Since, in general, this Attribute will not be supplied
by the PEP, then the Attribute will be detected as missing. If the
Attribute is declared MustBePresent, then this will trigger a
MissingAttribute condition for Indeterminate, which is described in Ch 7
of the XACML core spec 2.0.
Without getting into detail,
implementations such as SunXacml when encountering these conditions,
the ContextHandler invokes any configured AttributeFinders, which use
the RequestContext as context, and have the AttributeId of the Attribute
that is missing, and then the AttributeFinder can do what it needs to
find the missing attributes, which in this case, would presumably be to
locate the current representation of the hierarchy, calculate or read
the current values of ancestors etc., and return the new attributes to
the RequestContext.
The above technique should address the dynamic
requirements that appear to be necessary to solve the problem you
described, at least, wrt to my interpretation of that problem
description.
Thanks,
Rich
Steve Bayliss wrote:
Hi Rich
I can see how this would work where policies
include the full set of ancestor/parent attributes in their resource
specification; thanks for the use cases also. I think for the two
policies for "descendents of 'a'" and "descendents of 'b'" these in fact
also apply to "a" and "b" as well as their descendents (as it is
ancestors-or-self) - however I don't see any issue here, as
in the general case, if two policies "X" and
"Y" are being evaluated it will always be possible to see which is
"higher" (closer to root) in the hierarchy - as the lower policy will
include the higher policy as an ancestor - so I'm pretty sure something
workable could be implemented.
However if one wanted to encode polices such
that the policies themselves were not dependent on their own position in
the hierarchy, then this method wouldn't work I think. The
use-case here is where one wants to specify that a policy applies to
"all decendents of x" irrespective of where "x" is in the hierarchy -
this was the situation we did touch on earlier where one wants to allow
for restructuring of the hierarchy.
One way to solve this would be for the
hierarchical policy combining algorithm to have the ability to
query the hierarchy structure directly - would that be "appropriate"
within the XACML architecture?
I think it is best to leave multiple
hierarchies for now - first one would need a good example of a situation
where one could describe what one actually wanted to happen, and I'm
struggling with that - so I would tend to use the
hierarchical-lowest-wins algorithm for a specific hierarchy; and if
there were multiple hierarchies then combine these using the standard
combining algorithms for now.
Regards
Steve
Hi
Steve,
This is first chance I've had to look at this. I
basically agree with the way you have described the problem. It
sounds like you are saying:
- since both "/a/b/c/d" and "/b/a/c/d" produce the same set of
attributes
in the request context, that these two cases are
indistinguishable I think that is true that the requests are
indistinguishable, but maybe not the policies.
First, this
is no longer a single hierarchy problem: "/a/b/c/d" is one
hierarchy, where "a" is the root node, and "/b/a/c/d" is another
hierarchy, where "b" is the root node. I don't think this would be
allowed in the DAG, because /a/b and /b/a would create a loop which
is forbidden, so it would have to be a forest. However, let's leave
that aspect aside for now.
If we look at the policies, btw,
Anne did a preliminary document on some use cases, which may help a
bit. See attachment to this email: http://lists.oasis-open.org/archives/xacml/200406/msg00033.html Doc
is here: http://lists.oasis-open.org/archives/xacml/200406/pdf00003.pdf
In
that doc, check section 4.2 which shows an example policy using
ancestors.
In any event, let's consider how we'd write a Policy
that specified "descendants of 'a'". What we could do is collect
the attributes for "a", namely, in the case "/a/b/c/d", the
attributes are:
- self: "a"
- parent: null
- ancestors: null
- ancestors-or-self: "a"
Similarly for "b"
- self: "b"
- parent: "a"
- ancestors: "a"
- ancestors-or-self" "a","b"
For the node in the request,
we have:
- self: "d"
- parent: "c"
- ancestors: "a","b","c"
- ancestors-or-self: "a","b","c","d"
In XACML 2.0 there is
a set function in section A.3.11 called:
urn:oasis:names:tc:xacml:1.0:function:type-intersection where
"type" can be any XACML datatype
this function returns
a bag that contains the set of nodes common to both bags that are
input.
So, for Policy descendants-of-a we could compare the
ancestors-or-self bags of the request node and the policy node,
which would produce a bag: {"a"}. For Policy descendants-of-b the
intersection would produce a bag: {"a","b"}.
Now there is also
a function:
urn:oasis:names:tc:xacml:1.0:function:type-bag-size
this
function returns an integer.
Possibly, one could then write a
policy-combining algorithm that would include this integer in the
combining, where the greater integer implies the "lower"
policy, which would then take precedence?
For the "2nd
hierarchy" you'd have 2 similar policies. However, I am not sure
what kind of precedence could be meaningfully created by whether
the node was higher in hierarchy 1 than it was in hierarchy 2. So,
let's leave that discussion aside as well for now until we reach
agreement on the single hierarchy.
Thanks, Rich
Steve Bayliss wrote:
Hi Rich
Thanks, I think my understanding of how
this can work is nearly there.
There's a point I'd like to clarify to make
sure I haven't misunderstood something.
For clarification, this is using the
ancestor/parent scheme but not using the full path
identifiers for the ancestors/parents (I can see if the full
path identifiers are used then there is no
ambiguity):
If my assumption is correct then the given set
of parent/ancestor attributes could also result if the hierarchy was
/b/a/c/d - so if policies were present that specied "all descendents
of b" and "all descendents of a" then it would not be possible to
determine which was the "lower" policy and therefore which takes
precedence? I'm not sure I
follow the logic: in the case given descendants of "a" are "c"
and "d", and descendants of "b" are "a", "c",
"d".
The scenario
here is as follows:
i) The
request from the PEP is for resource "d"
ii) The
context handler builds the set of parent/ancestor
attributes
iii) There
are policies specifying 1) descendents of "a", 2) descendents of
"b", 3) descendents of "c)
iv) The
policy combining algorithm is "lowest policy
wins"
v) the
policy engine needs to determine the order of precedence of these
policies in order to combine the policies according to the combining
algorithm
So, if the
hierarchy was /a/b/c/d, then in (ii) this would result in the
context handler building the following attributes for the resource
"d"
ancestors:
bag{a,b,c}
parent:
c
ancestors or
self: bag{a,b,c,d}
If the hierarchy
was in fact /b/a/c/d, then the context handler would
build:
ancestors:
bag{a,b,c}
parent:
c
ancestors or
self: bag{a,b,c,d}
So, the same
attributes in both cases, so I believe the engine won't be able to
determine the hierarchy of "a" and "b" and therefore the
precedence of policies 1 and 2.
This comes back
to my assumption that the policy engine is working on the set of
resource attributes provided by the context handler (or can request
these resource attributes via an attribute
query).
Does this make
sense?
Steve
Hi Steve,
I looked over your comments earlier and
think we are converging, but now I will try to respond to your
points inline.
Thanks, Rich
Steve Bayliss wrote:
Hi
Rich
Many thanks for this. I can see that I maybe need
to add some clarity in terms of identifiers, nodes and
hierarchies to avoid us discussing at cross purposes. So I'll try and do that first,
then further comment inline to your
responses.
And for further
clarification I'll leave aside any more comments on multiple
hierarchies and assume a single rooted hierarchy for this
example.
The nodes in the example
have identifiers a, b, c, d - these identifiers are unique
within the scope of the
system.
The
expression
/a/b/c/d
is meant to state that
these resources a, b, c, d are organised in a hierarchy, so that
b is the child of a, c the child of b etc - this "path" is not a
node id per se; but a URI containing this path could be
generated as part of the hierarchical "path" URI scheme, as a
"resource-id".
So a resource-id (using
this scheme) of eg file:///a/b/c/d refers to the node d
(and also gives information about its ancestors and their
relationships within the
hierarchy).
I think this is the
assumption you've made
below. I agree. So, both "d", and "file:///a/b/c/d" identify the same
node, since "d", by itself is unique, and the other also shows
where "d" is in the "hiearchy" in which these nodes have been
assigned. For concreteness, if a,b,c,d were some sort of
physical device, then a,b,c,d might be their unique serial
numbers, which identifies each device, but the devices
themselves have no inherent relation to each other. The
hierarchical relation is a property that is added later. This
has been generally covered in earlier emails, so nothing really
new, just indicating how the identity of a node "may" also
include its position in the hierarchy, but this is not required,
as there are other "identities" that may represent the node
that are independent of any hierarchy.
Further comments
inline.
Steve
Hi Steve,
You raise some
interesting questions. I am finding that it is necessary to
qualify my answers significantly, because the problem
statements appear, at least to me, somewhat ambiguous, and
rather than try to answer all possible interpretations of
the problem, I opt to select one definitive interpretation and
maybe only mention the others for reference. I think this
particular problem, the hierarchical profile,
is particularly prone to this difficulty, because there is
so much inherent flexibility in hierarchical interpretation
and it can be applied in many different ways. So, bear with
me as I try to provide useful answers
inline.
Thanks, Rich
Steve Bayliss
wrote:
Hi Rich
This 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.
In 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. That's pretty clear, sounds like a
reasonable problem to be trying to solve: define
policies on hierarchical members (nodes) that override
policies of ancestor nodes that apply to all descendant
nodes.
So a made-up example would be a single
hierarchy:
/a/b/c/d
Ok, this can be
considered to be the URI " '/' + pathname" part of a
specific node-id. Or possibly what you are saying is that
this is the node-id of a hierarchy with a single node,
namely the one specified.
I will assume we are talking
about a single-root, single-parent hierarchy, where
the root node is "a" and the "made-up example" refers to a
specific node within this hierarchy. (Maybe this seems like
hair-splitting, but I have found unless all the details are
explicitly nailed down that the discussion quickly diverges
with each of the people in the discussion working from a
different set of assumptions, which, imo, ends up being a
waste of everyone's time because effectively no one
really understands what the others are saying. Don't mean
to soapbox, but as this email progresses I think you will
see a substantial number of potential divergence points.)
I
think we're in
agreement here, and do appreciate the point you're making about
the potential distinction.
ok
Policy 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
/a/.*) Agreed.
Policy 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
.*/b/.*)
Agreed with
following qualification: I assume that Policy 2 could also be
stated as "/a/b/*" instead of ".*/b/.*". Not sure why you
chose the latter.
The reason for this
distinction is that the policy is to apply to descendents of b,
rather than descendents of b when b is a child of a. A use
case for this may be reorganisation of the
hierarchy so that b is no longer a child of
a.
I think I get your point. Starting with the
collection a,b,c,d, if we are interested in the descendants of
"b", then that is not determined until someone puts together the
hierarchy. However, once the hierarchy has been assigned, i.e.
at any given point in time, then the list of descendants can
be determined. Also, at some later discrete time, the hierarchy
could have been rearranged and the list of descendants will be
different, in general, from the list at the previous
time.
A
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. I think all that can be said here is a
request for "/a/b/c/d" should result in
- a Permit from Policy 1 and
- a Deny from Policy 2.
The ambiguity of
saying "d" as opposed to "/a/b/c/d" comes from the initial
problem statement, where I assumed there could be multiple
nodes in the hierarchy. If you also had a node
named "/a/b/d" and then stated a request for "d", I am not
sure if want all nodes with node-name "d" or if you really
want the particular "/a/b/c/d".
Hopefully the clarification
with respect to nodes and identifiers resolves this
ambiguity. The user is requesting resource d,
that results in a resource-id of file://a/b/c/d using the hierarchical
resource profile path URI scheme.
Agree. The fact that you said
"these
identifiers are unique within the scope of the
system" means there will
only be one "d", and, as above, at any point in time it may show
up at different points in the hierarchy, depending on whether
the hierarchy has been re-arranged.
The 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. This sounds like a worthy
objective, and one could possibly use the
existing policy-combining algorithms to achieve it or maybe
not. As you indicate ahead, you are leaving that TBD for
now. Possibly a new combining algorithm would be in order,
which is interesting, but seems possibly as a separate
discussion issue.
(I am leaving aside the question of what algorithm
should be used to combine policies across multiple
hierarchies!)
I think I agree
based on my previous comment, but now you have introduced a
phrase "combine policies across multiple hierarchies". I agree
multiple hierarchies is an interesting discussion area, but
I thought the example was for a "single hierarchy" as
stated above, which I will continue to assume.
Agreed. This is a separate discussion, let's focus
on a single hierarchy.
Yes, if the rules for a single
hierarchy (single root, single parent) can get nailed
down unambiguously, at least for some problem domain, then more
complex problems can be systematically introduced and analyzed
on that foundation.
The 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 latter
case. Again, if we are talking about a single
hierarchy, as in the problem statement above, I am not sure
why you are making this statement., because in the particular
case of a single root, single parent hierarchy, there is,
in fact, no information loss. For example, in the case
given:
- parent of d is c
- ancestors of d are a, b, c
- ancestor or self of d are a, b, c, d
From this
collection of AttributeValues, the policy engine with access
to the node hierarchy can determine the URI by looking at
the parent nodes of c and b, so the information is
not really "lost" in this case. i.e. one can unambiguously
state that a policy applied to the descendants of "a" is
intended to apply to "d".
I'm still not clear on
this - particularly the phrase "the policy engine with access to
the node hierarchy". I'm making the assumption that the
policy engine has access to the node hierarchy by having been
given these hierarchical attributes (either directly through the
context handler, or through a request for those
attributes). Maybe this assumption is not
correct? Right, in general, this is a big assumption
to make. There are a number of possibilities, each of which
seems to be dependent on
situation-specific characteristics.
- One case is the URI scheme. If a URI is passed in then it
inherently
contains all the parent and ancestor information.
But to use the ancestor scheme, one has to have a way to
parse the URI to produce the list of ancestors. The Policy
could declare an attribute for the list, and if it is not
there, then maybe an attribute finder could be invoked
which would pull the URI from the RequestContext and parse it
and return the parsed components as the value of this
"missing attribute". Note: this only works because all the
info is already provided.
- Case 2: might be that some list of ancestors is passed in
plus the resource-id.
The question might arise, how do we
know this list is accurate? Presumably, it must have come
from the hierarchy itself, or some authoritative
representation of the hierarchy. For example, the PEP could
"go to the authority" and request the list of ancestors for a
specific resource-id.
- Case 3: no URI, no list provided: again we could do a
missing attribute,
however, in this case, the attribute
finder would need to go find the authority and get the list
and return it.
- Case 4: the navigation case you suggested earlier: somehow
the appl is
keeping track of the navigation path, and when
the PEP is invoked, either the node list or the parseable
path can be available to the PEP to do what it chooses.
Bottom
line: it is easy to "talk about" a list of ancestors, but it may
not be obvious how this list is obtained, and depending on
what's involved, it may or may not influence a possible choice
between the URI scheme vs the ancestor scheme.
If my
assumption is correct then the given set of parent/ancestor
attributes could also result if the hierarchy was /b/a/c/d - so
if policies were present that specied "all descendents of b" and
"all descendents of a" then it would not be possible to
determine which was the "lower" policy and therefore which takes
precedence? I'm not sure I follow the logic:
in the case given descendants of "a" are "c" and "d", and
descendants of "b" are "a", "c", "d".
So, "a" is lower,
since its list is a subset "b"'s list.
So, it seems
to me that with a single root single parent hierarchy, no info
is lost whether you use the URI or the ancestor scheme. I think
the issue only arises when multiple hierarchies are combined in
a DAG.
In XACML 2.0, this was the only choice one was
presented with, at least as I read the specs, i.e. you could
choose the DAG or the URI scheme. Upon detailed analysis of the
DAG, it became well understood that information was lost. Then
there was subsequent discussion whether that mattered or
not.
The XACML 3.0 spec attempts to resolve this issue by
providing both a representation where the info is lost for
applications where that is ok, and a representation (forest)
where information is retained (i.e. where a node has a list of
parents, and each parent is "tagged" as to which
single-rooted, single-parent hierarchy it belongs
to).
The algorithm provides for both including a mix of a
forest and multiple DAGs, if I remember right.
It is when you get to
"hierarchies" with multiple roots, as in the case of a DAG,
that such information as the "descendants of a" becomes
uncertain.
Again, this is a separate discussion area,
that diverges from the original problem
statement.
So focussing now on a single hierarchy
example
/a/b/c/d
What I had
assumed:
A request for "d" would result in
the following path URI (as resource-id attribute),
eg:
Yes, I agree.
Except what do you mean "would result"? Possibly you are
referring to the navigation client that is collecting
specific data as it goes, which has collected a,b,c on
route to d, and can reconstruct the URI based on this.
I'm assuming here that the context handler, with
access to the full hierarchy information, would construct a
hierarchical URI resource-id file:///a/b/c/d,
when the incoming request for d. So that's the case
using the hierarchical resource-id URI, rather than using
parent/ancestor attributes.
I agree, the context handler is the place
where a lot of these questions can be answered in a
straight-forward manner. The tricky part, imo, is that the CH
itself, is an ambiguity wrt the spec, and since a lot of the
assumptions one needs to make about the hierarchical profile
depend on the characteristics of the specific CH. This does not
mean, policies cannot be written, but w/o knowing something
about the CH, it is difficult to say whether one specific
strategy is superior to the other.
And the
following ancestor/parent attribute
values
parent-id=bag{c}
ancestor-id=bag{a,b,c} Agree.
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?)
Right, based on the
attributes alone, without access to the hierarchy, one can
probably not determine whether Policy 1 or Policy 2 takes
precedence.
Agreed, this is what I meant by loss of information about
the full hierarchy when using parent/ancestor attributes as
opposed to a resource-id URI with a path specifying the
hierarcy. Again the key phrase is "without access to the
hierarchy", which relates to my earlier
assumption.
However, one could probably say
the following:
- Policy 1 applies because using some algorithm, one can
presumably determine that
the bag{a,b,c} "matches" the
path "/a/.*".
- If Policy 2 were stated as "/a/b/.*" then that would
also "match" bag{a,b,c}, then
maybe one could infer that
Policy 2 took precedence because matching a and b is more
nodes than just matching a, so that might imply "deeper in
hierarchy".
Agreed.
(Personally, imo, this begs the question
"Why would anyone want to do things this way?", but that is
also a divergence and a digression, which could be discussed
separately. Note: I recognize that there are social
networking and semantic web use cases where this type of
processing might be useful, but I am not sure whether applying
policy for access control is a workable use case, but
again, that's another discussion.)
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
parent-id=bag{/a/b/c}
ancestor-id=bag{/a,/a/b,/a/b/c}
Yes, this is my
preferred way of looking at this problem. If you have
known hierarchical paths, then I see no reason not to use
those as resource-id's which enables one to use the URI
mechanisms. However, there may be cases where the URI
presents too much overhead of processing, and maybe ancestors
perform better, but "who knows", to me that is a
performance optimization based on a specific hierarchy with
known characteristics.
I can
see what you are saying here - that if there are known
hierarchical paths then these values can be used as
parent/ancestor values. As you state it is a "who knows",
but it "feels" to me that this is doing the job of using the URI
mechanism. Although the advantage I see in using
parent/ancestor attributes in this way is that it avoids needing
to match based on regex. Specifically if one was using a
PolicyFinderModule (in the Sun XACML implementation) then
indexing policies (for discovery by the PolicyFinderModule)
based on these parent/ancestor values in the policies would be
easier than indexing based on some decomposition of regex values
of resource-ids (unless one explicitly limited the allowable
range of regex to simple wildcard
matches).
I think in some sense this is getting to the
heart of the matter. imo, if there is a fixed hierarchy,
typically where governance is done over subtrees, then the regex
approach is probably desirable. For example in a file system
where all the files for one department are within a specific
subtree, then one could simply specify the path to that subtree
and feel confident that the controls being applied were what's
needed. In this case, I think representing this path as a
collection of ancestors pretty much obscures what the policy is
doing, so while it might work technically, it would seem to have
little practical value.
In the navigation case, where the
list of ancestors is a function of how you got to the node,
i.e. you are effectively defining your own hierarchy on the fly,
then there is no way to know in advance what paths need to be
protected, since there can be any number of paths to a specific
node. I think this implicitly places you in the multiple
hierarchy problem space, and if you don't care what particular
path, but do care about the ancestors, then a DAG might be the
right model, in which case one would probably look to the
ancestor method as being strategically advantageous.
The
intent of the XACML 3.0 profile is to allow designers to freely
choose the scheme to apply to different aspects of their
problem domain. I suspect the notion of "resource-type" would
play a significant role in the sense that a specific
resource-type might be best represented by a URI, or a DAG, or
a forest (which is a superset of the DAG and URI schemes). It
is also conceivable, I expect, that even a single
resource-type might have aspects of its use in an organization
that would suggest that it have independent representations
including any or all of the 3 schemes.
Hopefully this
discussion can help development of a structural framework for
analyzing specific problem domains, and that it can provide
structure for partitioning a complex problem into a more
manageable small set of relatively simpler
problems.
Rich
So in this case the structure is
not lost (and I see the equivalence to the path URI
method). Agree.
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
XML).
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 approach,
particularly
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. Right, this statement was
included to alert users of the nature of the "ancestor" or DAG
method, which is described in more detail in sections 1.1
and 1.1.1 of the 3.0 profile.
The specific aspect that
needs to be preserved is the specific parent and specific
hierarchy if one is to retain "chain of control"
information.
For
example if the CEO of a company applied a policy to all
employees, it is possible that such a policy could be
overridden by someone in the mailroom who was captain of
the company bowling team of which the CEO was a
member.
This has to do with the "tranistive" property
of hierarchical relations, discussion of which can be
found in semantic web references. With single root single
parent hierarchies this problem can be avoided, and as
explained at the end of section 1.1.1, retaining the
hierarchical identity produces a superset of the DAG, which
also does not have the cycling problems of DAGs.
None of this was apparent, in the XACML 2.0 version
of the hierarchical profile, which is the reason for much
of the added detail of the 3.0 version, which
still preserves all the functional capabilities of 2.0,
but just distinguishes the cases.
4.1 The 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
method] Right, this is included as
well to alert users of the choices inherent in the approach
that is used.
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.
Yes, if you use URIs as the
node-names you are effectively retain the information, but
in a redundant manner.
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
lost. This is a special case of the
ancestor method, which allows you to capitalize on the URI
properties from the node names. But it is not a "general
solution" because it is dependent on a particular
node-naming strategy. Furthermore, in order to use the
retained info, one must "crack" the node-names which
is outside the specified scope of the ancestor
method.
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 approaches.
The point of the comment in
4.1 is not to recommend using URIs as node-names in the
ancestor method, it is to point out that if one wanted to use
the ancestor method, and also if one became "concerned"
about the specific paths to the nodes, then this would be a
"way out" of the problem. However, once one realized
that the path information was of significant value to a
particular use case, then one would probably want to
consider re-evaluating the original strategy of using the
ancestor method.
Again, this is an area the could
become a whole discussion topic all by itself.
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
path. Agree. There is a lot of
flexibility inherent in the Hierarchical Profile because it
covers anything that has mathematical hierarchical
properties. The original spec focussed on the more general
multi-root, multi-parent case, which proved to be
problematic for chain of control use cases, in particular,
because the "chain of control" was tossed out in the
ancestor method, and one was left with only a fairly brittle
URI method. The purpose of this spec is to unify all these
use cases under one broad umbrella, where the specifics of
each subcase can be identified by specific properties
of the hierarchy or hierarchies in the application arena
that need to be considered.
The algorithm in 3.3.1 is
intended to formalize this unification and show how
all these methods can logically and peacefully coexist in a
fairly straight-forward framework for representing the
problem space.
Hi Steve,
Generally, I think
your question needs to get more specific, because of
the inherent flexibility of the URI/hierarchical
mechanism, imo, one needs to understand what one is
trying to achieve in order to meaningfully define an
optimum strategy. I will take an initiial shot w responses
in line.
Thanks, Rich
Steve Bayliss
wrote:
Hi Rich
Many thanks for this, this greatly clarifies my
understanding.
To 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
through. Agree. The important thing
is the path itself, not which module navigated the
path.
One further quesion (at this
stage!):
Would it be possible
to
1) in the Request Context, use the hierarchical
URI profile; and at the same
time
2) in policies use the parent/ancestor attribute
profile? Personally, I do not see a
significant distinction between the "URI profile" and
the "parent/ancestor attribute profile", which I see as
effectively being functionally 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.
For
example, if you start with a collection of resources, and
each has a unique identifier, 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 necessary to define the
"relation" and how the "relation" is established
between the members. Once this relation is defined,
then it makes sense to start considering how policies
are applied to the collection.
Let's assume you
organize them in a single rooted hierarchy such that each
member has a single parent and all members have some
parent. Now you have the equivalent of a file
directory, where each file has a name and it is also a
member of a directory in a hierarchy of
directories.
Given this scenario, then what is your
question 1 and 2? I would assume I would pass the
dir-path/filename as the resource-id. The list of
ancestors is nothing more than a succession of
truncated dir-paths. So is the question whether to
pass "/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 the difference?
Is the parsing
of "/a/b/filename" vs "/a/b/.*" more expensive than doing
bag operations of ancestors? I honestly have no idea.
It may depend on the implementation of the engine. It
may depend on how large the collections are that are being
processed. 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 choice.
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
parentage"). The comments above should
address, but not necessarily fully answer the "much
easier" question you are thinking about.
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. Again, depending on what
you are trying to accomplish, the importance of which
hierarchy a node's parent belongs 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 original hierarchy by a
single column in the n+1 columns of n hierarchies
and 1 resource-id as in the algorithm. And as indicated
in the 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 to the table and increase the DAG width to
m+1.
Regards
Steve
Hi Steve,
I
find your explanation much easier to understand now.
It sounds like:
- there is one underlying "physical" resource,
"c", that can be obtained either
- 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
I think the following Policy elements placed in
a Target would make the Policy applicable to any
resource prefixed with "file:///a/b"
<ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string"
>file:///a/b/.*</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string" />
</ResourceMatch>
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.
Thanks, Rich
Steve
Bayliss wrote:
Hi
Rich
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
"resources-in-path-context".
In both scenarios there is
a resource c that is present in two
hierarchies:
/a/b/c
/x/y/c
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.
Scenario
1:
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
a->b->c? The first (and only)
ResourceMatch element above I think is what such a
Policy would need to contain to match the "/a/b/c"
path.
(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.) That is much more
clear now, thanks.
The application's PEP would
be able to supply the browsing path in the request
context. Agree, the general
assumption is that the PEP is able to collect
information about the request and transform that
information to an appropriate set of attributes.
(If additional attributes are required they can be
obtained via the ContextHandler or by using the
MissingAttributesDetail technique.)
Is this something that the
Hierarchical Resource Profile is suited to?
I believe so. It
appears to me to be a perfect fit.
Or should this "navigation
path" should be a separate attribute outside of
those specified in the Hierarchical Resource
Profile? I don't think it is
necessary for an additional "navigation path"
attribute. I think the navigation path makes for a
perfectly good resource-id.
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. The only distinction I
can think of right now is that a "navigation path" in
the sense of tracing everything 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 resource-id value.
Am I missing
something here?
Scenario
2:
The user browses to the
resource c. It is irrelevant from a policy
perspective of how they navigated to the
resource. Presumably, within
this particular example there are only the two paths
available. In any event, even if there were more
paths, the profile should work just as
well.
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". This sounds like it
could be done with an "AND" of the two ResourceMatch
elements (one for "/a.*", and the other for "/x.*")
within a single Resource element.
It seems that this is
suited to the Hierarchical Resource
Profile. Agree, but also think
scenario 1 is just as applicable.
It would be the
responsibility of the Context Handler to provide two
hierarchical resource-id
attributes. The algorithm in HRP
XACML 3.0 section 3.3.1 shows how resource-ids can be
constructed given a list 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.
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. I agree the "ancestor
scheme" can be used here. Personally, I think the URI
scheme is sufficient for 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.
Further
comments:
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.
Yes, that is correct, and it is
allowed as specified in XACML 2.0 section 6.3 lines
2947-2954, 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 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.
Agree.
- Instead resource-parent,
resource-ancestor and resource-ancestor-or-self
attributes are used to represent this
information
Yes, although, this probably is
only relevant to DAGs, and is superfluous for any
number of single parent hierarchies.
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. Yes, I think we are in
agreement, assuming my comments are consistent with
what your statements are intended to
mean.
Rich
Thanks
Steve
Hi
Steve,
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 bit.
Thanks,
Rich
Steve Bayliss wrote:
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.
I am having
trouble parsing the following paragraph. I will
deal with each segment in sequence:
My question is if the Hierarchical
Resource Profile deals (is intented to deal
with) with resources-in-path-context.
The sentence above
appears to be asking the
question:
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?
That is, if a resource belongs to
multiple hierarchies/has multiple
parents/ancestors, can a policy be written for
this resource-in-path-context.
The answer to the
first part of the question is "Yes, a policy can
be written for it.". 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.
(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). I do not
understand the above statement at all. The first
phrase appears to use the term policy
redundantly:
"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:
- a resource being accessed because it is a
member of (a specific collection?)
- a resource being accessed in the context of
being a member of (a specific collection?)
Is this the point, that the above two
bullets are distinct in some
manner?
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 Ok, assuming the
above URI pathname portions plus leading "/" are
provided as resource-ids (where multiple
resource-ids 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:
- 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.
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.
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 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.
And two different policies, one
specifying (as URI regex match) /a/b/.* and the
other /x/y/.* would both
match? There is no
requirement for two Policies, as opposed to say
two Rules, but yes, it is likely that both the
regex's you propose would appear.
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? It is ok to
specify only one path in the request, but it
depends on the Policy structure whether that
would be accepted or not. i.e. does the Policy
state:
- ( /a/b/.* AND
/x/y/.* ), or
- ( /a/b/.* OR
/x/y/.* )
That is, because a full resource-id is
already present then the engine shouldn't go
away and build the
paths. Sorry, I am not
sure what you are trying to say here. There is no
requirement on the engine to use any specific
method for processing the above
scenario.
And is it conceivable that both forms
could exist
together? I assume so,
however, it sounds like you may have a concern
that for some reason both forms should
not co-exist. Is that a concern?
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) I'm afraid you are
going to have to be more specific here about what
information is being processed. 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?
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 Correct, but see
comment above. It depends if Policy requires
resource to be member of both hierarchies or
only one hierarchy.
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). Again, I am not
sure what the term "resource-in-path-context"
precisely means or the alternate phrase: "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.
Thanks
Steve
|