Title: Message
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?
(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.)
The
application's PEP would be able to supply the browsing path in the request
context.
Is
this something that the Hierarchical Resource Profile is suited to? Or
should this "navigation path" should be a separate attribute outside of those
specified in the Hierarchical Resource Profile?
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.
Scenario 2:
The
user browses to the resource c. It is irrelevant from a policy perspective
of how they navigated to the resource.
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".
It
seems that this is suited to the Hierarchical Resource Profile. It would
be the responsibility of the Context Handler to provide two hierarchical
resource-id attributes.
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.
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.
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. Instead resource-parent, resource-ancestor and
resource-ancestor-or-self attributes are used to represent this
information
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.
Thanks
Steve
-----Original Message-----
From:
Rich.Levinson [mailto:]
Sent: 20 January 2011
04:23
To: Steve Bayliss
Cc:
Subject: Re: [xacml-users]
Clarification of Hierarchical Resource Profile
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:
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
