[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Example of dag and forest used to manage collection ofresources for comparison
Hi Daniel and TC,|
Some of these appear to be repeat criticisms from previous discussions that I thought were addressed in previous emails, but will try again to clarify, so TC members have context for evaluating situation.
All the concrete examples, such as a "farm of computers" or a "warehouse of boxes" are not attempts to standardize anything. They are simply examples, which some people find useful to understand the abstract concepts in the specifications. I am well aware that some people find these kinds of examples useful and some don't. Personally, I find them useful, and find that some people who I explain things to also find useful. Also, it is a very common practice to explain by example, so I do not understand the issue here.
"managing a "farm of sharable computers", or anything else of that nature should not be a part of XACML"does not appear to me to be addressing the example, but simply making a statement that the example should not be a part of XACML. Since the example was only used to explain an aspect of the XACML Hierarchical Profile, and was not intended to be put in the profile, but only help the TC members understand what the purpose of the proposed changes are in the profile, the statement appears to me not to be in conflict with what was said in the original email, nor does it appear to take issue with the example itself on any of the particulars.
On your second point:
"The only thing that matters for a simple, core hierarchical rules management system is an ability to specify a rule that apply to "descendants" of a resource and an ability to specify what resources are "descendants". "Again, in principle, I don't think we have a disagreement here. The DAG and the forest define two different sets of descendants. The forest defines only "direct" descendants from the original hierarchies. The DAG defines only "direct" descendants from the merged hierarchy. Previous emails have explained the details of the differences, but for many people the key fact is that the original hierarchy is changed by the DAG. Users who want to maintain the original hierarchies will not be able to use the DAG for this, but they will be able to use the forest. Furthermore, any structure that can be created with a DAG can also be created in the forest. Therefore, the DAG members can be obtained from the forest "simply" by directing the forest manager to collect all nodes that are descendants of ancestors whether direct or not. Obviously forest is not optimized for this type of operation, but information is available if needed.
The notion that you have suggested in this email and some of the previous emails,
"That is one of a myriad of possible such resource ontologies. All of them can be mapped into a simple attribute based scheme that is needed to apply hierarchical rules."I still have interest in and would like to see a clearly defined example so that I might understand the DAG use cases better and if they have broader application capabilities then is currently apparent to me.
However, for those use cases, such as have been described explicitly and generally, where the DAG has no capabilities, the critical factor is that there is no DAG capability to maintain multiple hierarchies that retain the original lines of authority without spreading that authority to additional unintended entities. As a result, any particular resource in a DAG will be subject to policies from direct ancestors and indirect ancestors as well with no way to distinguish them. Without this capability, other capabilities are not a factor, because the DAG will not meet the requirements.
For the forest, the capability to maintain the original lines of authority is built-in. The capability to obtain, what we might call the additional lines of "influence" is also available as is the ability to distinguish each from the other. For applications that only require "influence + direct", then DAG is appropriate. When there is a requirement to maintain "direct lines of authority only" then DAG will not meet the requirement, and one has the option in the spec, then, of choosing forest.
This next point still keeps coming up and still I must address it because it does not represent what the proposal is:
"I am glad that you do not advocate removing DAG. I am voicing my opinion about adding anything else. There is no need for that and it brings complexity. "This statement creates the impression that the "forest" capability is being "added". It is not. It is already there and has been there since the spec was first released. However the capability has not been properly explained and it is difficult for me to see how anyone could discern between the two very distinct characteristics of the DAG and forest from the current spec. Since there are many application that require the forest and not the DAG, the purpose of the clarifications in the spec is to enable readers to understand the distinction and select what they need appropriately.
What currently exists in the spec is "complexity" because these two concepts are intertwined in a manner that one cannot see the difference between disjoint and merged trees and if one is interested in disjoint trees then there is tremendous complexity figuring out how to use the spec for this purpose. The proposed changes simplify the spec by disambiguating the two concepts and enabling the user of the spec to have a clear choice.
The final statement also mixes up the capabilities:
"From the point of view of PDP there are no hierarchies to merge. There is one hierarchy at a time that is pertinent to an evaluation. Merging etc. is to be handled by an external system. "It is correct that the PDP does not merge hierarchies, nor does anything in the proposed changes suggest that does.
It is the DAG content handler that merges hierarchies by applying the ancestor collection algorithms in section 3.2 to the resource collection data before it submits the request to the PDP. These algorithms explicitly collect ancestors that are not direct ancestors of the requested node, because they make the assumption that the information distinguishing between the two kinds of ancestors is not available, which in itself is an assumption about the external systems that cannot objectively be made.
The example given in earlier email shows exactly the kinds of external systems that exist and shows that the information is generally available if it is of potential use. The assumption in the 3.2 algorithms is that there is no distinguishing information externally to distinguish between direct and indirect ancestors. This is, in general, a false assumption. One should be free to implement context handlers that have any capabilities necessary to meet the needs of the policy designers who use the PDP.
In the example given, one would have the choice of the "forest resource manager" or the "DAG resource manager". If the enterprise wanted to maintain "disjoint, but overlapping" lines of authority, then they could deploy a "forest resource manager". If they wanted "merged" lines of authority, they could deploy a "DAG resource manager".
I expect, in principle, if they wanted a mix of both, disjoint for some policies, and merged for other policies, there are probably enterprise design strategies where the PEP in initial request could be configured to trigger one or the other type of ancestor collection by the context handler, which is the point of specifying the "forest" identifier for the URIs in section 2.2 and the functions in 3.2. If context handler needs to gather only direct ancestors, or if it is all URIs not gather any ancestors, or if is DAG gather all ancestors, then contexthandler can make that choice based on identifiers in request.
Daniel Engovatov wrote: