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:
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
Message
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.)
006001cbbe2f$102631b0$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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$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".
006001cbbe2f$102631b0$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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
(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.
006001cbbe2f$102631b0$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".
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
And the following
ancestor/parent attribute values
parent-id=bag{c}
ancestor-id=bag{a,b,c}
Agree.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
However, one could probably say the following:
- Policy 1 applies because using some algorithm, one can presumably
determine that
the bag{a,b,c} "matches" the path "/a/.*".
- If Policy 2 were stated as "/a/b/.*" then that would also "match"
bag{a,b,c}, then
maybe one could infer that Policy 2 took precedence because matching a
and b
is more nodes than just matching a, so that might imply "deeper in
hierarchy".
(Personally, imo, this begs the question "Why would anyone want to do
things this way?",
but that is also a divergence and a digression, which could be
discussed separately.
Note: I recognize that there are social networking and semantic web use
cases where
this type of processing might be useful, but I am not sure whether
applying policy
for access control is a workable use case, but again, that's another
discussion.)
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
So in this
case the structure is not lost (and I see the equivalence to the path
URI method).
Agree.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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.
006001cbbe2f$102631b0$0301010a@asusp4t533"
type="cite">
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:
000c01cbbba4$5b3ff560$0301010a@asusp4t533"
type="cite">
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.
000c01cbbba4$5b3ff560$0301010a@asusp4t533"
type="cite">
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.
000c01cbbba4$5b3ff560$0301010a@asusp4t533"
type="cite">
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.
000c01cbbba4$5b3ff560$0301010a@asusp4t533"
type="cite">
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.
000c01cbbba4$5b3ff560$0301010a@asusp4t533"
type="cite">
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:
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
(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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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.)
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
Is this something that the Hierarchical
Resource Profile is suited to?
I believe so. It appears to me to be a perfect fit.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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?
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
It seems that this is suited to the
Hierarchical Resource Profile.
Agree, but also think scenario 1 is just as applicable.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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".
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
- 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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
- 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.
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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
003c01cbb88f$8f8c1eb0$0301010a@asusp4t533"
type="cite">
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:
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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:
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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?
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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.
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
(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?
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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.
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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.
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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.
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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/.* )
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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.
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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?
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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?
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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.
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
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.
001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">
Thanks
Steve
|