[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, 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;
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]