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.
So a
made-up example would be a single hierarchy:
/a/b/c/d
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/.*)
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/.*)
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.
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.
(I am
leaving aside the question of what algorithm should be used to combine policies
across multiple hierarchies!)
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.
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:
And the
following ancestor/parent attribute values
parent-id=bag{c}
ancestor-id=bag{a,b,c}
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?)
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}
So in this case the structure is not lost (and I see
the equivalence to the path URI method).
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.
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]
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. 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.
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.
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.
Regards
Steve
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
|