OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml-users] Clarification of Hierarchical Resource Profile

Title: 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.
So a made-up example would be a single hierarchy:
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
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
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
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.
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 25 January 2011 07:08
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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.


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">
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 20 January 2011 22:10
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Clarification of Hierarchical Resource Profile

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"
      DataType="http://www.w3.org/2001/XMLSchema#string" /> 
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.


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:
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.
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.

003c01cbb88f$8f8c1eb0$0301010a@asusp4t533 type="cite">
-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: 20 January 2011 04:23
To: Steve Bayliss
Cc: xacml-users@lists.oasis-open.org
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.


Steve Bayliss wrote:
001e01cbb7f7$85a884d0$0301010a@asusp4t533 type="cite">
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)
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">

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]