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

[Erik Rissanen <erik@axiomatics.com>]

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;