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.
To
clarify, would the policy still be written using the hierarchical
ancestor/parent attributes?
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?
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
- 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)
- 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
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:
000801cbcd28$30132ca0$0301010a@asusp4t533 type="cite">
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:
003401cbc8fa$4d5ef8c0$0301010a@asusp4t533
type="cite">
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:
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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.
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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.
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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.
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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.
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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.
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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.
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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.
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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
006401cbc83a$d3a25280$0301010a@asusp4t533
type="cite">
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
|