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