[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]