OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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.


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]