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.
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.
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.
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.
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.
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?
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?
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.
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).
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
|