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

[Erik Rissanen <erik@axiomatics.com>]

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