Re: [xacml] Example of dag and forest used to manage collection ofresources for comparison

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Daniel and TC,

I am disappointed that this response does not directly address the example. I consider it to be a very reasonable example. One such use case would be a "farm" of sharable computers, and two applications, each organized as a hierarchy of modules, that the appl deployer configures on different machines, possibly because those machines have resources needed by specific application modules.

Also, it is not an "overly complicated example". It is as simple as 2 sheets of paper with numbered boxes that are each filled in by a different person with a different purpose for using the shared resources.

Each person may want to make the contents of those boxes (physical or logical) available only to certain members of that person's organization and allocates access to the boxes within organization's own hierarchical framework (which is all contained in the two columns allocated to the customer by the parent attribute associated with each customer-specified node name).

This is typical enterprise use case with many large distributed applications over world-wide corporate resources. Each application needs to be managed independently of other applications, yet at the same time must share the common corporate resources on which it is run.

Finally, I want to emphasize one more time: I have not advocated removing any of the DAG functionality that already exists in the spec. If you carefully read the proposed modified spec, I think you will see it is functionally unchanged. The changes are only to distinguish the DAG from the forest and to fill in the missing information to show how the forest can be used, if one chooses to do so.

Both the forest and URI capabilities (URI is concrete representation of more general forest) have been in the spec since the beginning, long before I had any working involvement with the XACML specifications. There are many obvious use cases for forest and URI, such as the ones I have mentioned and, at a minimum, cases where an investment has already been made and URIs already exist and the customer has no interest in changing them.

The example I have given demonstrates the distinction of information content between the forest and the DAG, namely that the forest, as a set of disjoint trees, one way or another contains the hierarchical relationship of the collection of resources within each disjoint tree, as well as the relationships to the other trees when the trees are mapped on the common resources to be organized.

The DAG specifically does not need to keep whatever structures are used to keep the original trees disjoint, and similarly has no capabilities for recovering any information about the original disjoint properties of its current members unless it happens to have kept this information around. That is why the DAG leads one to dismantle URIs, because there is no need to maintain the order of the components. That is analogous to the row compression in the example I gave.

For application use cases where the URI structure or the example row structure is not needed, then DAG is a perfectly good solution.

However, the use cases in enterprise security quite often are geared around independent hierarchical lines of authority for which it is very important to maintain knowledge of precisely where this authority is coming from.

The change to the spec leaves the DAG capabilities unchanged and available for use. The change also explicitly distinguishes DAG and forest and fills in section 3.2, which currently only contains DAG information and is missing the comparable forest information.

The main difference between DAG and forest is that DAG can be used  to "merge" hierarchies into a single uniform structure which has no memory of the original hierarchies. The forest "aggregates" hierarchies into a single uniform structure that does have memory of the original hierarchies and the capability of maintaining that info thru adds moves and changes.

The example shows a concrete instance of this forest implementation and the changes that can be made to transform it into a DAG, which is essentially the same structure minus the original hierarchy mechanism, which was to maintain a customer as two columns.

The "forest", applied to resources, is in common use today under the term "polyarchy". Since the XACML Hierarchical Resource Profile already has this capability, I see no reason to suppress or remove it, but consider it a strength of XACML that it currently does support it and that it can be used if properly explained in the specification, which is the purpose of these proposed changes.

    Thanks,
    Rich


Daniel Engovatov wrote:

Bottom line: again as I see it, this is the problem with the person who was the xacml-commenter referenced in earlier emails who was seeking advice, presumbably guided by the spec in its current form to dismantle their URIs. To me, this appears as if they are basically destroying information that they had already established as a sunk cost, and constraining themselves to work within the more limited framework that the lesser information provides.

This assumption is incorrect.  There is no need to construct any URI in the first place.

This whole overly complicated example demonstrates that XACML should not be involved in any form of resource ontology management.  It is based on wrong and completely unjustified assumption about what hierarchy means for the purpose of policy evaluation.     From the point of view of PDP, there is only one hierarchy.  There is only one "customer" at a time.  All we need to do is to specify is a protocol to transmit this information to PDP.    That is completely sufficient.   DAG accomplishes that.   Everything else is completely extraneous, not needed, and none of our business.    We should clarify the existing specification about the use of opaque unique identifiers, remove any references to URI's for the non-XML case, and leave it at that.  It works, and works correctly.

Daniel;