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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent


Personally I have never found the profile difficult to understand and 
the intent of it has been clear to me. I can agree that it's not 
described in a stringent manner, but I don't think it's too bad either. 
I also worry that if we make it too "correct", it will become hard to 
understand because it could get very verbose.

In any case, I would not like to wait for a rewrite of this profile 
before we proceed to CD with the core & friends. I haven't checked my 
notes, the issues list, mailing archives, etc, but I think as we stand 
now, we are pretty much ready with the core, delegation and the old 
profiles. I don't think the deficiencies in the hierarchical profile are 
important enough to hold back the rest right now.

So, I would propose that we either "ship" the current hierarchical 
profile together with the core, hopefully soon, or drop it all together 
from the package.

Best regards,

Rich.Levinson wrote:
> Hi All,
> I am choosing this point (in the email threads) to continue discussion 
> of the issues with the Hierarchical profile as I think it contains the 
> best context to start from.
> As indicated in the last couple of TC meetings, the update I proposed:
> http://lists.oasis-open.org/archives/xacml/200901/msg00079.html
> only goes part-way to addressing the problems I have found in the 
> Hierarchical profile specification. The update only includes 
> effectively a glossary with definitions of the terms that are 
> currently used in the spec that make the rest of the spec 
> comprehensible (at least from my perspective), and based on that 
> glossary, the spec includes a few clarifying edits, which are 
> primarily intended to make the statements in the spec consistent in 
> terms of the definitions in the glossary.
> Primarily, the glossary simply defines "hierarchy" and "DAG" (Directed 
> Acyclic Graph), where DAG is a collection of hierarchies that are 
> mapped onto a flat collection of resources, where any resource can be 
> a member of multiple hierarchies within the DAG.
> Based on this starting point and Erik's suggestion as to how the 
> concepts might be applied in the real world, I did further 
> investigation and have come to some additional preliminary conclusions 
> on which I think the next step to address this spec should be based.
>    1. The most significant conclusion I have reached is that the
>       primary "problem" with the non-xml resources (section 3.2) is
>       that the details here are solving a much more complicated
>       problem than is necessary for most common use cases, which is
>       that the resources are identified with URIs as described in
>       section 2.2 and 4.3.
>       In particular, this "more complicated problem" is one where the
>       resource-id, itself, is not sufficient to describe the hierarchy
>       of which it is a member. An example might be resources
>       identified by serial number (a flat namespace), as opposed to
>       resources identified by URI, which is an inherently hierarchical
>       namespace (http://www.ietf.org/rfc/rfc2396.txt).
>       With a hierarchical namespace there is no need to collect parent
>       and ancestor nodes since they are already built in to the URI
>       itself. In fact, there is an example document that I "found",
>       that was produced as an artifact of the XACML 2.0 development
>       effort, that appears to have gotten lost from the active XACML
>       collection:
>       http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf
>       that demonstrates this quite clearly: section 4.2 shows policies
>       based on resource-ancestor and resource-parent attributes, and
>       section 4.3 shows the same policies based on matching anyURI.
>       i.e. if the resources are identified by URI there is no need to
>       use resource-parent and resource-ancestor attributes either in
>       the RequestContext or in the Policies.
>       Based on this situation, my proposal is to enhance the existing
>       Hierarchical spec using the URI representation in section 3.2
>       and indicating that this approach can be used instead of
>       resource-parent and ancestor when the hierarchies are
>       represented by nodes with URI resource-ids.
>    2. A 2nd significant problem I believe I have found is that the
>       algorithms defined in section 3.2 are incorrect in some
>       significant ways, which I believe should be addressed (I will
>       give an example below).
>       My proposal here is to simply fix the algorithms.
>    3. A 3rd significant problem I believe I have found is that there
>       are important concepts that are either left out or not given
>       sufficient emphasis in the spec, which, imo, cause conceptual
>       ambiguities that make it effectively impossible to say what
>       problem the specification is actually addressing.
>       In particular, there is no explicit definition of "normative
>       identity", which is a key term used in the algorithms defined in
>       section 3.2.
>       My proposal here is to assert that the normative identity may
>       use either the recommended representation of URI described in
>       section 2.2, or a functionally equivalent representation, such
>       as can be constructed using resource-parent and
>       resource-ancestor node collections.
>       In particular, there is insufficient development of the concept
>       of "consistent representations for identities" as mentioned in
>       section 1, lines 68-72, section 2, lines 175-178, section 3,
>       lines 227-229. While the point is made that such consistent
>       representations are necessary, the essential fact that in a DAG
>       that a single node can have multiple normative identities AND
>       that those identities each belong to a separate distinct
>       hierarchy within the DAG is not established. The result is that
>       it is conceptually ambiguous that when a node is said to have
>       multiple parents, the essential fact is that the node must then
>       have multiple normative identities, each of which is traceable
>       to one and only one parent (or self, if the current node happens
>       to be the top of one of the hierarchies within the DAG).
>       My proposal here is to adjust the text to emphasize these
>       notions accordingly.
> One final note: I appreciate the significant effort that went into the 
> development of the Hierarchical specification. A review of the emails 
> from April 2004 -> September 2004 will show anyone interested that a 
> lot of work went into the development of this specification. My own 
> interpretation of the problems I have had with this spec is that it 
> was a relatively small, but considered to be important, part of XACML 
> 2.0 and that while the ideas collected in this spec are generally 
> properly targeted, it appears there was simply not sufficient time 
> available for the TC to consolidate the findings of their studies of 
> the hierarchy problem and to structurally sort the results into 
> separable pieces that would have made the results easier to understand 
> and apply.
> This effort is intended to build on the existing spec and emphasize 
> aspects of it that currently are not, and to correct any problems that 
> may be found in the process.
> As indicated above, I will give an example of what I consider to be an 
> "error" in the algorithms of section 3.2:
>     In section 3.2 the descriptions appear to be lterally
>     "over-specified": for example, consider lines 324-327:
>         " For each immediate parent of the node specified in the
>         “resource-id” attribute or attributes, and for each normative
>         representation of that parent node, an <Attribute> element
>         with AttributeId
>         “urn:oasis::names:tc:xacml:2.0:resource:resource-parent”. "
>     This statement is indicating that the node "specified in the
>     'resource-id' attribute or attributes" can have multiple parents
>     and that each of those parents themselves can have multiple
>     normative representations.
>     I claim that the quoted statement is incorrect because while the
>     given node can have multiple parents, because the current node may
>     belong to multiple hierarchies, there should be no concern for
>     hierarchies that the parent belongs to that the current node does
>     not belong to.
>     The following example will show why this is doubly and actually
>     triply specified and also why it is essential that the changes
>     described in 1-3 above are needed.
>     Consider 3 hierarchies:
>         * /a1/b1/c1
>         * /a2/b2/c2
>         * /a3/b3/c3
>     Let's say that a1, a2, and a3 are distinct roots and represent 3
>     separate nodes (or resources) in the overall collection.
>     However, let us also say that b1 is a node that belongs to all 3
>     hierarchies and that, in fact, /a1/b1, /a2/b2, and /a3/b3 all
>     represent normative identities of the same node.
>     Now let us further assume that c1 and c2 represent the same
>     physical node, but that c3 is a different node.
>     Let's also assume that these physical nodes have serial numbers
>     r*, which serve as alternate unique identifiers of the nodes. We
>     can then see the relation as follows:
>         * Let r1, r2, r3 be serial numbers of the 3 separate root nodes.
>         * Let r4 be the serial number of the b1,b2,b3 node.
>         * Let r5 be the serial number of the c1,c2 node.
>         * Let r6 be the serial number of the c3 node.
>     The logical and physical resources and hierarchies can now be
>     represented together as follows:
>         * /a1(r1)/b1(r4)/c1(r5)
>         * /a2(r2)/b2(r4)/c2(r5)
>         * /a3(r3)/b3(r4)/c3(r6)
>     From the above, it is clear that if we are requesting access to,
>     say node /a1/b1/c1, then to apply the rules quoted above for
>     parents, we would need to first include:
>         * /a1(r1)/b1(r4)/c1(r5)
>         * /a2(r2)/b2(r4)/c2(r5)
>     where the 2 parents of c1(r5) are
>         * /a1/b1
>         * /a2/b2
>     i.e. c1, which is r5, which is then also c2, effectively has these
>     2 parents.
>     However, the rule then requires us to collect all the normative
>     identities of each of the parents.
>     First of all in this case the parent rule requires us to collect
>     the normative identities of r4 twice, once in its a1/b1
>     incarnation at which point it also picks up a2/b2, and once in its
>     a2/b2 incarnation, where it picks up a1/b1 again. Therefore it is
>     already "over-specified" because it requires collecting these
>     identities twice resulting in 4 instead of 2 "normative parent
>     identities".
>     Furthermore, the algorithm also requires us to pick up /a3/b3,
>     which is another "normative identity" of this parent node, which
>     means we will have 3 copies of each normative identity of the
>     "parents" of c1 for a total of 9 "normative parent identities",
>     which are, of course triply redundant.
>     In fact, we really only need /a1/b1 and /a2/b2 since r5 does not
>     belong to the /a3/b3 hierarchy.
>     Therefore this algorithm needs at least 2 corrections:
>        1. Correct it so that it only includes one copy of each
>           normative identity of each parent.
>        2. Correct it so that it does not include normative identities
>           of the parent which are part of hierarchies to which it does
>           not belong, since policies on those hierarchies can have no
>           bearing on this node because the normative representations
>           within those hierarchies cannot refer to this node because
>           it does not have a normative representation in those
>           hierarchies to which it does not belong.
> Comments and suggestions are welcome. I will wait for feedback on 
> emails and discussion at the next TC meeting before proceeding with 
> the recommended changes.
> Thanks,
> Rich
> Rich.Levinson wrote:
>> -------- Original Message --------
>> Subject: 	Re: [xacml] Issue: Hierarchical profile appears ambiguous 
>> and inconsistent
>> Date: 	Thu, 15 Jan 2009 11:37:10 -0500
>> From: 	Rich.Levinson <rich.levinson@oracle.com>
>> To: 	Erik Rissanen <erik@axiomatics.com>
>> CC: 	Daniel Engovatov <daniel@streamdynamics.com>, xacml 
>> <xacml@lists.oasis-open.org>
>> References: 	<496EDDA0.4070707@oracle.com> 
>> <1448A6CC-1532-40B4-BFC0-DC9D0413097E@streamdynamics.com> 
>> <496F4B67.1040700@oracle.com> <496F4DC8.4030200@axiomatics.com>
>> Hi Erik,
>> Thanks for this feedback. Unfortunately I did not have time to 
>> process this email before today's meeting, but now that I have, it 
>> addresses one of my major concerns which was the motivational 
>> context. i.e. by seeing the actual example you provided, I can see 
>> that a Policy can now base decisions knowing that some node happens 
>> to be an ancestor of the requested node.
>> In addition, for your example, I think it would be instructive to 
>> show when a node belongs to two or more hierarchies, that the 
>> collection of attributes should probably have a mechanism to indicate 
>> which hierarchy a node belongs to. For example, if C had an alias C', 
>> and parent B' and ancestors A'->D' where, while (C = C'), that in 
>> general (B != B') and (A != A') and obviously D' has no relation to 
>> the unprimed nodes at all. We would then have a request:
>> <Resource>
>> resource-id = C
>> parent-id = B
>> self-or-ancestor = C
>> self-or-ancestor = B
>> self-or-ancestor = A
>> resource-id = C'
>> parent-id = B'
>> self-or-ancestor = C'
>> self-or-ancestor = B'
>> self-or-ancestor = A'
>> self-or-ancestor = D'
>> </Resource>
>> It would seem to me that there needs to be a mechanism whereby one 
>> would be able to tell the primed from unprimed attributes. Possibly 
>> using Issuer
>> In any event, it is useful information to have this additional 
>> context for understanding the current spec.
>> As agreed at the meeting, I will try to find some cycles to say what 
>> I think needs to be done to make the spec easier to understand, which 
>> is possibly just including the above information (i.e. your email 
>> extended to multiple hierarchies with some example policy concepts, 
>> also such as you provided).
>> Also, I think, as I mentioned at the end of the meeting that "scope" 
>> may also have a meaningful role to include in this profile as well. 
>> i.e. one can easily see that if policies are defined whereby certain 
>> conditions apply when a resource-id node is within scope (as defined 
>> by multi-resource spec) of some other node, that some if that ""other 
>> node" happens to be a parent or ancestor of the resource-id node, 
>> then those "certain conditions" would apply to the current 
>> resource-id being requested.
>> Thanks,
>> Rich
>> Erik Rissanen wrote:
>>> Rich.Levinson wrote:
>>>> I am trying to understand what policies are supposed to do with the 
>>>> definitions in the spec. i.e. it is the spec that says in section 
>>>> 3.2 that all the parent and ancestor nodes need to be assembled in 
>>>> the request context. What "policy evaluation" are you referring to? 
>>>> Are you saying what I indicated in original email that a policy 
>>>> does not need to know anything about hierarchies that the 
>>>> resource-id node does not belong to?
>>> Hi Rich,
>>> I don't understand all the questions you have, but here's the basic 
>>> approach of the profile in a simple example.
>>> Assume the following simple hierarchy:
>>> A <- B <- C
>>> If someone requests access to C, the request will contain these 
>>> attributes. this is from the top of my head, so it might be slightly 
>>> inaccurate and I might have forgotten some of the attributes, but 
>>> hopefully you get the idea.
>>> <Resource>
>>> resource-id = C
>>> parent-id = B
>>> self-or-ancestor = C
>>> self-or-ancestor = B
>>> self-or-ancestor = A
>>> </Resource>
>>> All these attributes are there so it is possible to write policies 
>>> which apply to parts of the hierarchy, not just individual nodes.
>>> For example:
>>> <Target>
>>> resource-id = C
>>> </Target>
>>> Matches only the resource C, nothing else.
>>> <Target>
>>> parent-id = B
>>> </Target>
>>> matches the immediate children of B. In the example this is C, but 
>>> if C had a sibling, it would also match.
>>> <Target>
>>> ancestor-or-self = B
>>> </Target>
>>> Matches B or any node below B. In this case also C.
>>> Best regards,
>>> Erik
>> -------- Original Message --------
>> Subject: 	[xacml] Issue: Hierarchical profile appears ambiguous and 
>> inconsistent
>> Date: 	Thu, 15 Jan 2009 01:54:24 -0500
>> From: 	Rich.Levinson <rich.levinson@oracle.com>
>> To: 	xacml <xacml@lists.oasis-open.org>
>> I am finding the Hierarchical profile ambiguous and inconsistent and 
>> therefore incomprehensible, which may, similarly to the 
>> Multi-Resource profile be because there are essential contextual 
>> paradigms missing from the specification.
>> For the Multi-Resource profile, the missing contextual paradigms 
>> included:
>> * It is necessary to pre-process the multi-resource request and
>> submit individual requests to the PDP, and then to package up the
>> responses into a single response.
>> * The PDP, itself, can only process Request elements that in 2.0
>> contain a single Resource element, single Action element, single
>> Environment element, and multiple Subject elements, but each
>> Subject element has to have a distinct SubjectCategory attribute,
>> and in 3.0 there can be multiple Attributes elements, but each has
>> to have a distinct Category attribute.
>> Once the above paradigms are established, the Multi-Resource profiles 
>> become comprehensible.
>> I suspect something similar is going on w the Hierarchical profile also.
>> Here is the background on the Hierarchical profile that I am trying 
>> to work thru (each bullet represents a potential issue to resolve or 
>> suggestion for improvement):
>> * There needs to be a definition of "hierarchy". In particular, a
>> "hierarchy" defn should state that the fundamental properties are
>> that there must be a single root node with no parent, and that
>> every other node in the hierarchy must have one and only one
>> parent, and can have zero, one, or more children.
>> * Section 3.2 is the biggest problem. To begin, the following needs
>> confirmation: it appears that the key structural sentence for 3.2
>> that explains what the four bullets that follow it are is lines
>> 314-315 (which is sandwiched between a negative statement on
>> ResourceContent and subsequent 3 sentence "note") that state:
>> o "The request context <Resource> element SHALL contain the
>> following elements and XML attributes."
>> * Each of the 4 bullets in section 3.2 contains the phrase "(for
>> each) normative representation (of some node ...)". I think this
>> is the core of the problem I am having understanding this spec.
>> What I think it means is that for a given collection of physical
>> resources, such as files in a file system, that in additional to
>> the conventional file identification by directory path, which
>> includes all the files in the file system, that other logical
>> hierarchies that can span part or all of this set of resources
>> also needs to be taken into account. And that the "normative
>> identity" of a specific "file" is within the context of a specific
>> hierarchy. i.e. each hierarchy that covers all or part of this set
>> of resources has its own "namespace" and within that namespace has
>> a scheme for hierarchically naming its members. As such, a given
>> physical resource can belong to any number of these hierarchies
>> simultaneously, and has one "normative representation" for each
>> hierarchy it belongs to. And presumably, the point is that each
>> hierarchy the resource belongs to may have its own restrictions to
>> apply to resource, so we have to identify all of them to get the
>> full picture.
>> * Given the above characterization of the multiple "hierarchies" a
>> given resource can belong to, it then appears that the four
>> bullets in section 3.2 state that in order to submit a request,
>> one has to somehow identify all the hierarchies the given node
>> belongs to, all the hierarchies the node's parent(s) and ancestors
>> to, and include an Attribute element for each.
>> * There appears to be some over-specification above and beyond what
>> is presumably intended (assuming the above characterizes what is
>> "presumably intended"). For example, since a node in a hierarchy
>> can have only one parent, and if a node belongs to multiple
>> hierarchies, then that node will have one and only one parent for
>> each hierarchy it belongs to, the following sentence (lines
>> 324-325) appears to doubly state this relationship:
>> o "For each immediate parent of the node specified in the
>> “resource-id” attribute or attributes, and for each
>> normative representation of that parent node ..."
>> i.e. the node specified in the resource-id can only have one
>> parent wrt the the node's normative representation with a
>> specific hierarchy. There seems to be no point to looking at
>> a parent node in any other context than the normative
>> context of the resource-id node. i.e. if a node only belongs
>> to one hierarchy, but its parent belongs to many, then the
>> other hierarchies the parent belongs to should have no
>> impact on the child since the child is not a member of those
>> hierarchies.
>> Assuming the above characterization is even close to correct, I am 
>> still wondering "why" all this information is being assembled and 
>> what the Policy is expected to do with it. i.e. what is the policy 
>> evaluation paradigm that is being represented here? I suspect that at 
>> most one would need to collect all the normative representations of 
>> only the resource-id node (i.e. identify all the hierarchies it 
>> belongs to), then for each hierarchy, one would evaluate the policies 
>> that apply to that hierarchy.
>> Thanks,
>> Rich
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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