[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 Rich, I don't think I understand what you mean. The commenter's resources are not disjoint. They are a DAG. Therefore he wants to use the "ancestor scheme" without URIs. Regards, Erik Rich.Levinson wrote: > Hi Erik, > > The commenter states the problem he is trying to solve as: > > * "I have a rule that says "permit if resource has ancestor 'path'"." > > It is only after he follows the erroneous directions in section 3.2 > that he runs into trouble, whereas if he used the suggestion in my > previous email the problem would already be solved and we would have > no issue. > > I have done further research into this and I think that I can now say > unambiguously that section the bulleted algorithms in section 3.2 are > simply wrong, because they are based on an erroneous premise. > > The erroneous premise is that it is assumed that a forest is the same > as a DAG. In fact, they are not the same. In particular, a forest is > generally defined as a *disjoint set of trees*. The important word in > this phrase is "disjoint". There are many reasons why this problem > must be modeled as a disjoint set, several of which have been covered > in previous emails. > > The algorithms in section 3.2 are specifically not disjoint, which is > why they are in error. This error is simply corrected by a minor > modification to ensure disjointness. > > At this point I would like to raise this to a formal issue, which I > would categorize as a recommendation to correct a SEVERE ERROR in the > Hierarchical Profile Specification. > > We have already seen evidence as reported by this commenter that the > errors in this specification are leading users to do wrong and > irrelevant work, and we now have specific formal definitions of the > terms that express exactly what the error is and how it can be corrected. > > Thanks, > Rich > > > > > Erik Rissanen wrote: >> Hi Rich, >> >> My understanding is that the commenter does not want to use URIs at >> all. Instead he wants to do it like this: >> >> resource-id=r1 >> resource-ancestor=path >> resource-ancestor=to >> resource-ancestor=one >> resource-ancestor=another >> >> URI matching wouldn't help him. >> >> Regards, >> Erik >> >> >> Rich.Levinson wrote: >>> Hi Erik, >>> >>> With regard to your 2nd point on the comments/users list, it appears >>> to me that because the Hierarchical spec has the problems that I >>> have described in earlier emails, that the user has posed his >>> question in such a way that instead of advising the commenter on >>> what appears to me to be a simple obvious way to solve his problem, >>> you instead have been drawn into considering the user's suggestion >>> that we change the specs from the current explicit description in >>> section 2.2 to one that appears to me would significantly undermine >>> the intent of the current section 2.2. >>> >>> Now that we have hammered away at the hierarchical profile for >>> several emails, and if people have been reading the details, we can >>> now take another look at the question the commenter raised, which I >>> had previously said we should revisit in the context of my proposal >>> (item 3 here: >>> http://lists.oasis-open.org/archives/xacml/200902/msg00004.html). >>> >>> The commenter's question is here: >>> http://lists.oasis-open.org/archives/xacml-comment/200901/msg00003.html >>> >>> Your reply to him, where you said you would bring the issue to the >>> TC, is here: >>> http://lists.oasis-open.org/archives/xacml/200901/msg00056.html >>> >>> This example shows exactly why I believe it is NECESSARY to add the >>> clarifying text that I have been talking about to section 3.2. >>> >>> It appears to me that this user has been clearly misled by the spec >>> to attempt to do what seems to me to be a wasteful and pointless >>> exercise of parsing URIs and then trying to make sense of the >>> collection of artifacts that he has produced. It appears to me that >>> this is totally unnecessary, and I would suggest that it has been a >>> waste of his time for being led down this path by the >>> specifications, which is the point I have repeatedly been making >>> that the specs are insufficient in section 3.2 in this regard . >>> >>> I am concerned that instead of addressing this type of problem with >>> the capabilities currently in the spec, that we are being drawn down >>> a path, which will effectively dismantle the perfectly good >>> functionality that is in the spec by removing the URI capability as >>> it currently exists. >>> >>> I think this user should be told that since his nodes are currently >>> identified by URIs that are in the form called for in section 2.2 >>> that he does not need to worry about collecting ancestors etc. and >>> all he needs to do is apply the XACML 2.0 anyURI-regexp-match as >>> described in section A.3.13 of the core spec and his problem is solved. >>> >>> As described in section 4.3 of the example doc in the archive >>> (http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf), >>> this function is simply specified as: >>> <Apply FunctionId="&anyURI-regexp-match;"> >>> <AttributeValue DataType="&string;" >>> >http://example.com/path/*</AttributeValue> >>> <Apply FunctionId="&string-one-and-only;"> >>> <ResourceAttributeDesignator AttributeId="&resource-id;" >>> DataType="&string;"> >>> </Apply> >>> </Apply> >>> >>> This is the kind of guidance I am recommending that we add to >>> section 3.2 of the Hierarchical Profile. >>> >>> As I understand your email, an alternative suggestion to address >>> this user situation is to recommend that the user parse his URIs >>> into components, and that we change the spec to alter the currently >>> defined URI capability (to no longer be a URI capability, with all >>> the inherent capabilities of a URI) in order that the customer be >>> able to do this? >>> >>> Let me further point out that I don't think there is any need to >>> change the spec, because it already says in section 2 that governs >>> 2.2 that: >>> >>> "The following sections describe RECOMMENDED representations for >>> nodes in hierarchical resources. Alternative representations of >>> nodes in a given resource are permitted so long as all Policy >>> Administration Points and all Policy Enforcement Points that deal >>> with that resource have contracted to use the alternative >>> representation." >>> >>> Therefore, if for some reason we advise against using what appears >>> to me to be an obvious standard capability described above with >>> anyURI-regexp-match, and would like users instead to parse their >>> URIs into components so that they can supply the components as a >>> collection of ancestors, I believe we are still able to do this >>> because the statement above appears to explicitly allows for nonURI >>> representations, in which case we would not have to do anything to >>> section 2.2. >>> >>> However, to be perfectly honest, I still see no advantage to >>> applying the bulleted capability procedure of section 3.2 to nodes >>> that are already identified by URIs. >>> >>> Comments welcome. I would really like to understand if there is a >>> legitimate reason for not using the URIs as is and replacing them by >>> collections of components. >>> >>> Thanks, Rich >>> >>> >>> >>> >>> >>> Erik Rissanen wrote: >>>> All, >>>> >>>> I've been in a rush today, so I haven't followed every detail in >>>> the discussion, but basically, here is how it appears to me: >>>> >>>> * The profile, as it stands today, does specify the limited URI >>>> scheme which Rich describes. It says in section 2.2 that: >>>> >>>> --8<-- >>>> The <pathname> portion of the URI SHALL be of the form >>>> >>>> <root name> [ “/” <node name> ]* >>>> >>>> The sequence of <root name> and <node name> values SHALL correspond >>>> to the individual hierarchical component names of ancestors of the >>>> represented node along the path from a <root> node to the >>>> represented node. >>>> --8<-- >>>> >>>> So it in fact says that the identifiers must consists of paths with >>>> the names of the ancestors. >>>> >>>> * If I understand Daniel correctly, he says that each node should >>>> be allowed to have a name which is entirely independent of the >>>> other nodes in the hierarchy. Relations between the nodes are >>>> maintained in a manner not specified by XACML and are expressed in >>>> XACML Requests and policies in the form of the attributes >>>> resource-parent, resource-ancestor, etc. I think that the more >>>> general approach advocated by Daniel would be the correct way to >>>> go, so I agree with him (and Seth I believe. :-)) >>>> >>>> * I also think as suggested on the XACML comments/users list that >>>> the data type of the node identifier should not be limited to URIs >>>> only. >>>> >>>> But I would prefer to leave major changes to the hierarchical >>>> profile out of the first batch of CD documents. >>>> >>>> Best regards, >>>> Erik >>>> >>>> >>>> Rich.Levinson wrote: >>>>> Hi Daniel and TC, >>>>> >>>>> Hopefully, those who have followed the details of these emails >>>>> recognize that each step in the sequence has advanced the >>>>> discussion in a consistent manner and as a result we have done a >>>>> fairly thorough job of mapping out the problem space that is under >>>>> discussion. In any event I believe my comments in this email >>>>> continue to advance the discussion in a worthwhile manner, and I >>>>> think will describe the complete problem space as well as give a >>>>> clear description of the options available, all of which offer >>>>> full functionality. >>>>> >>>>> In the current phase, if I am not mistaken, it is a >>>>> straight-forward matter to apply definitions to the distinct >>>>> categories of problems and simply observe that we have two sets of >>>>> tools which are equally effective at solving each category of >>>>> problem, where >>>>> >>>>> * one set of tools (let's call it the "ancestor method") is most >>>>> effective when one is dealing with resources where it is not >>>>> possible or desirable to apply URIs as normative identifiers >>>>> * a second set of tools (let's call it the "URI method") which is >>>>> available when one is dealing with resources where URIs can be >>>>> applied as normative identifiers, and the designers want to >>>>> take >>>>> advantage of the powerful features inherent in URI objects, esp >>>>> when applied to hierarchical problems. >>>>> >>>>> Let me address Daniel's points below, then try to summarize the >>>>> present state of the discussion: >>>>> >>>>> Daniel Engovatov wrote: >>>>>> >>>>>> On Feb 18, 2009, at 3:05 PM, Rich.Levinson wrote: >>>>>> >>>>>>> Daniel, Seth, Erik, and TC, >>>>>>> >>>>>>> If we stick to the generally accepted definition that an object >>>>>>> in a hierarchy can have at most one parent, then a URI solves >>>>>>> the problem without having to look beyond the URI itself >>>>>> >>>>>> It is NOT a generally accepted definition and we did not stick to >>>>>> it on purpose. >>>>>> >>>>> Whether it is generally accepted or not is probably not important >>>>> here, however, it is consistent with the structure of XML >>>>> documents, such that when we are talking about a "single >>>>> hierarchy" of nonXML resources that if we assert that this implies >>>>> a structural relationship equivalent to the structural >>>>> relationship of the nodes of a well-formed XML document, which is >>>>> that each element can have at most one parent, and the top element >>>>> or node has zero parents. >>>>> >>>>> This gives us a crisp unambiguous definition of the term >>>>> "hierarchy" which can be applied both to the XML and nonXML >>>>> resources, and it totally avoids trying to determine whether it is >>>>> an "accepted" definition or not, since that property is no longer >>>>> relevant. >>>>> >>>>> The point of this definition is to give us a conceptual framework >>>>> within which to evaluate the two primary use cases of the DAG, >>>>> which as will be explained are also clear and unambiguous >>>>> well-defined use cases. >>>>>> >>>>>>> However, if we allow the hierarchies to break down and lose >>>>>>> their inherent hierarchical properties, then more complicated >>>>>>> approaches, such as going outside the initial request context to >>>>>>> get more nodes, although still solvable w URIs as demo'd below, >>>>>>> are needed. >>>>>>> >>>>>> >>>>>> It is NOT "broken down" >>>>> True, in an absolute sense nothing is "broken", however, what has >>>>> happened is that we have allowed one class of DAG representation >>>>> to be impacted in such a way that we have allowed it to become the >>>>> second class of DAG representation because we did not clearly >>>>> define the distinction and what was to be allowed and not allowed. >>>>> This has nothing to with whether the ancestor or URI method is >>>>> used. It has only to do with the relationships that are allowed to >>>>> be represented when two resources are "connected" by virtue of >>>>> their hierarchical relationship being established. >>>>> >>>>> Specifically, one has a choice of: >>>>> >>>>> 1. only allowing the relationship that is being established to be >>>>> active. For example if my boss is assigned to be subordinate to >>>>> a task force leader when a cross functional team is being set >>>>> up, this case would say that has no impact on my relationship >>>>> with the task force leader unless I am a member of the task >>>>> force. i.e. the task force leader has control over my boss's >>>>> resources to whatever degree is implied by the task force >>>>> situation, however the task force leader has zero direct >>>>> control >>>>> over my resources as a result of this assignment. In this >>>>> model, >>>>> that direct control could be simply be established by either >>>>> assigning me directly to the task force leader, or assigning me >>>>> a second subordinate relationship to my boss in the context of >>>>> the task force relationship. >>>>> This is a clearly defined process, where there is no ambiguity >>>>> about relationships between the resources. If you want the >>>>> relationship, you explicitly establish it, if not, you don't. >>>>> >>>>> 2. the other choice is the exact opposite, namely allowing >>>>> incidental relationships to be established simply because they >>>>> connect to a node with direct relationships. To take an extreme >>>>> light-spirited example, for the purpose of showing how >>>>> "extraneous" relations are introduced, if the company CEO was a >>>>> member of a company bowling team, where the captain of the >>>>> bowling team happened to be a junior software engineer who just >>>>> joined the company, then everyone in the company would suddenly >>>>> have this junior engineer as their ancestor. Possibly this >>>>> would >>>>> be disallowed by acyclic graph rules, but a similar situation >>>>> would occur if the VP of engineering was on a bowling team >>>>> captained by the junior sales trainee, who would now be >>>>> ancestor >>>>> to everyone in engineering organization. >>>>> >>>>> Both methods are acceptable for assigning relationships, but one >>>>> or the other may be more effective for one or another type of >>>>> organization. Personally, I think most enterprise security >>>>> departments would favor the first approach, because it appears to >>>>> offer more direct control and less chance of unintended >>>>> consequences resulting from the assignment of a direct relationship. >>>>> >>>>> However, either choice can be used with either the "ancestor >>>>> method" or the "URI method". Which choice is made is a function of >>>>> the node collecting algorithm that is used for policy evaluation. >>>>> i.e. when you collect the parent nodes of the requested node, >>>>> >>>>> * choice 1 above means only collect those nodes to which the >>>>> parent has a direct relationship with the requested node, >>>>> * and choice 2 means collect all the nodes of choice 1 plus all >>>>> other nodes where the parent has a hierarchical relationship >>>>> that does not directly involve the requested node. >>>>> >>>>> These are the two primary use cases of the DAG, which were >>>>> mentioned above. Which use case is chosen depends only on the node >>>>> collection algorithm and not how the nodes are represented. i.e. >>>>> parents and ancestors exist whether or not they are incorporated >>>>> for handy access within a URI or not. >>>>> When the URI can be used, the URI collection within the requested >>>>> node itself contains all the nodes that will be collected with >>>>> method 1 and there is no need to access any additional information. >>>>> >>>>>> >>>>>> >>>>>>> Again, I am not trying to add or change any of the existing >>>>>>> functionality, >>>>>> >>>>>> You are proposing an addition that is a subset of the more >>>>>> general approach. >>>>> Hopefully, the description above satisfactorily demonstrates that >>>>> the URIs are simply a concrete mechanism to implement the general >>>>> solution. It is also a mechanism that, if used effectively, >>>>> appears to be much more efficient since all nodes that need to be >>>>> collected in method 1 actually are already contained in the URI >>>>> collection of the requested node. >>>>> Therefore it is a concrete representation of the general approach, >>>>> however it is a concrete representation that capitalizes on the >>>>> fact that the object used to represent the node (the URI) has an >>>>> equivalent structure to the spatial relationships of the nodes in >>>>> the DAG that need to be collected in method 1, and so those nodes >>>>> do not need to collected at all since they are already present. >>>>> The same structural relationship exists in method 2, however, >>>>> method 2 fans out so far so fast that collection outside the >>>>> requested node will be required to fulfill the needs of method 2. >>>>> It is functionally equivalent to the general approach, however, it >>>>> has the advantage that a single URI contains the normative >>>>> identity of all the required nodes for method 1 and some for >>>>> method 2. >>>>>> >>>>>> I understand that you favor a different approach to this problem. >>>>>> It may be worth our while to create a separate profile for such >>>>>> an approach, but I do not see any reason to muddy the existing one. >>>>>> >>>>> It should be clear from the above discussion that showing how URIs >>>>> address the same problem is not a "different approach". It is the >>>>> same approach, except the work required to collect the nodes is a >>>>> lot less, and can be eliminated almost completely depending on >>>>> what node collection strategy is chosen, method 1 or method 2. >>>>> >>>>> Finally, it should be clear that the bulleted algorithms in >>>>> section 3.2 of the spec represent a nonURI approach using a method >>>>> 2 collection algorithm. >>>>> >>>>> Now that the problem is clearly defined, I expect it will take >>>>> much fewer words than have been exchanged in these emails to >>>>> explain the available options in section 3.2, which are: >>>>> >>>>> 1. method 1 node collection, URI method (all nodes required are in >>>>> requested node) >>>>> 2. method 1 node collection, ancestor method: (requested node has >>>>> pointers to parents, but need to recursively navigate to parent >>>>> to advance up the hierarchy, but does not navigate thru >>>>> nodes of >>>>> which the requested node is not a hierarchy member) >>>>> 3. method 2 node collection, URI method (subset of nodes required >>>>> are in requested node, the rest must be obtained by recursively >>>>> navigating based on parent hierarchy nodes of which requested >>>>> node is not a member) >>>>> 4. method 2 node collection, ancestor method (this is the >>>>> algorithm >>>>> currently in section 3.2 bullets and need to recursively >>>>> navigate thru all parent nodes regardless of whether requested >>>>> node is a member of the hierarchy or not.) >>>>> >>>>> These 2 choices of node collection are implicit in the DAG problem >>>>> definition and are not currently explained in the document and I >>>>> believe need to be. i.e. a DAG is the result of a set of >>>>> hierarchies (as defined above) being layed across a set of >>>>> resources. i.e. it is the result of a set of explicit relations >>>>> being applied between pairs of nodes. The "choice" is whether to >>>>> retain the "history" of why those relations were applied (i.e. the >>>>> direct relations) or not. If you don't then additional, indirect, >>>>> extraneous relations automatically appear and there is no way >>>>> distinguish between them and the direct relations, at least in the >>>>> "general" or "ancestor" case. In the URI case, the direct and >>>>> indirect relations are always present and may be used or not as a >>>>> matter of choice. >>>>> >>>>> The choice of ancestor or URI method for node identification is >>>>> simply whether URI "can" be used and whether URI is "desired" to >>>>> be used. Functionally, URI will produce the same results. >>>>> >>>>> Thanks, >>>>> Rich >>>>> >>>>>> >>>>>> Daniel; >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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]