[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
Hi Erik,
Based on my email moments ago in reply to Daniel, I now see the task of
advancing the hierarchical profile as quite straight-forward, which is
to take my modified V4 and enhance accordingly w descriptive text
explaining how URIs are a possible implementation of the general
problem, which actually fits pretty cleanly with the URI discussion in
sections 2, 2.2, and 4.3 policy.
I will also attempt to clean up the algorithms to remove the ambiguity
of possibly including irrelevant hierarchical references (i.e. if a
parent of the current node belongs to a hierarchy that the current node
does not belong to, then there is no point including those hierarchical
references in the algorithm). I can ignore the "over-specification"
aspect by simply saying duplicates are reduced to a single copy, so as
not to get involved optimizing the algorithm.
My intent is to keep the hier profile on track, however, it is important
that it be generally recognized as of value to solving common
hierarchical conceptual problems, which I believe my enhancements
facilitate. Note: that I have proposed zero changes in functionality of
the profile, but simply been trying to bring its current content to a
more usable state.
Thanks,
Rich
Erik Rissanen wrote:
> All,
>
> 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,
> Erik
>
>
> 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
>
>
>
> ---------------------------------------------------------------------
> 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]