OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml-users] Clarification of Hierarchical Resource Profile

Title: Message
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
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:
- Resource attribute - ancestors: bag{b}
- Rule effect is Permit
- 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
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 19 February 2011 04:46
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

Hi Steve,

Responses inline.


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.


-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 15 February 2011 16:31
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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.


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.
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 15 February 2011 07:29
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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

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:
Doc is here:

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:
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:
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.


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?
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 10 February 2011 04:10
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

Hi Steve,

I looked over your comments earlier and think we are converging,
but now I will try to respond to your points inline.


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
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.
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 30 January 2011 23:03
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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.


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:
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.
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/.*)
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
(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
  • 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
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
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".   
 (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
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.


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 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

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.
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 25 January 2011 07:08
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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.


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.
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 20 January 2011 22:10
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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"
      DataType="http://www.w3.org/2001/XMLSchema#string" /> 
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:
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:
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.
  • 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.

-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 20 January 2011 04:23
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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.


Steve Bayliss wrote:
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)
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]