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