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
|