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 Erik,

I agree that you can use a set of names, which maybe already existed and use them simply on the basis of their superclass string property and create any hierarchical relationships using some independent method. But then you could not advertise that you were using a hierarchical naming scheme, because would be wondering what happened to the hierarchical properties of the naming scheme.

In fact, that is exactly what is being done in the Hierarchical profile. By trying to capitalize on the value implied by the title "Hierarchical Profile", and then implementing the spec using algorithms of DAG, which in general destroys any hierarchical properties, the spec is effectively self-contradictory.

In general, hierarchies are a subclass of DAG. In particular, a forest, which is a disjoint set of trees is a subclass of DAG. The forest, by its disjointness, retains the hierarchical properties of its member nodes, by treating each node as a member of one or more explicit hierarchies.

However, the ancestor method of section 3.2, is explicitly that part of the DAG superclass that does not apply to the forest subclass. More specifically, the ancestor method explicitly destroys the disjointness of the trees within the forest, resulting in a structure that is explicitly non-hierarchical.

As we have seen, users of this specification, who start out with an inherently hierarchical set of resources, are immediately led to implement this algorithm which will transform what is initially a "hierarchical resource" into an explicitly non-hierarchical resource.

Since this specification is explicitly about providing:
"access control for a resource that is organized as a hierarchy"
it is self-evident that using an algorithm for target matching that will collect nodes that are not ancestral hierarchical nodes will result in identifying non-applicable policies to be applied to the request. This is certain to produce unexpected results.

If an organization were to invest a lot of time and resources building a security infrastructure assuming they were using hierarchical properties only based on this profile, and then found out that the profile actually explicitly specifies only algorithms that will, in general, disregard and violate the hierarchical structures of the resources that are being managed, I expect that the organization that produced this specification will have a lot of difficult questions to answer.

    Thanks,
    Rich


Erik Rissanen wrote:
499E793D.7070201@axiomatics.com" type="cite">Hi Rich,

The ancestor scheme is more general since the hierarchy is completely independent from naming.

You could have a hierarchy where http://example.com/A is the parent of urn:oasis:xacml:D

You could also have a hierarchy where http://example.com/A is not the parent of http://example.com/A/B

Regards,
Eri,k


Rich.Levinson wrote:
Hi Erik,

A few points I'd like you to consider with respect to your first point:

   1. I am not sure why you have chosen to refer the URI scheme as the
      "limited URI scheme", because as I showed in previous emails, it
      appears that the URI scheme is, in fact, more general than what
      you refer to as the "more general approach advocated by Daniel".
      The reasons for this are quite simple. First, the URI scheme is
      functionally equivalent and more efficient as can be easily seen
      as follows:
          * in the ancestor scheme, as I understand it, we might have
            a node, "a", which is a normative identity for a
            particular node, and it might have 2 ancestors, a parent,
            "b", and ancestor "c".
            Presumably, if a request to access "a" comes in, the CH
            will have to gather the ancestors. This means the CH must
            have some means of finding out that "b" and "c" are the
            ancestors of "a". Since this information is not included
            in the node name of "a", the CH must look elsewhere.
          * in the URI scheme, I would name my "a" node as "/c/b/a"
            using the same strings as above. In the URI scheme, a
            request for "a" would come in as "/c/b/a". In this case,
            the CH is done, it doesn't have to go looking for
            ancestors for 2 reasons: 1. because it doesn't need them,
            2. even if it did need them, they are already there.

   2. The reason why the URI scheme is more general is a bit subtle,
      but still should be straight-forward to understand. The subtlety
      is that when presented from an inverted perspective, it might at
      first appear that the ancestor scheme is more general, but a few
      quick points should explain why that is not the case:
          * Sticking with the same use case as above as a starting
            point, let us consider the case where "b" has 2 parent
            nodes "c" and "d". I don't believe there are many people
            who would argue that this structure is still a hierarchy,
            however a rational case could be made that it is actually
            2 hierarchies, one headed by "c" and one headed by "d". In
            this case "b" would be a member of 2 hierarchies.
          * At this point the differences in the two methods becomes
            clear. Let us first look at the ancestor case. Because a
            relationship between "d" and "b" has been established,
            does that mean there is now a relation between "d" and
            "a". In the ancestor case, the answer is "yes".
          * If we now look at the same use case with the URI method
            and ask the question whether there is now a relation
            between "d" and "a" the answer is "no".
          * One says yes, the other says no. Does this mean they are
            simply "equal" in capability, but different in "result"?
            Similar to a xacml Rule that can be designed for Permit or
            Deny?
          * If that was the end of the story, then one could say they
            are equal in capability, but it is not the end of the story.
          * In the URI case, we may now establish a 2nd relation
            /d/b/a, which now will produce the answer yes, when asked
            the question whether there is now a relation between "d"
            and "a".
          * Therefore the URI scheme can produce both a yes and a no
            to this question, while the ancestor scheme can produce
            only a yes. Therefore the URI scheme has greater
            capabilities and is thus, more general than the ancestor
            scheme.
          * QED

Again, this is not a change to the profile, this is simply exposing a capability of using the URIs in the profile that is not present when using the ancestors.

There is a 2nd issue that I will also comment on shortly in a separate email, so that we may reference these use cases in a discrete manner.

    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]