Hi Hal,
Let me try to quickly address the points you raise. If there is
insufficient detail, I will be happy to provide, but will try to keep
short for clarity inline:
Hal Lockhart wrote:
> I am sorry Rich, I cannot make any sense out of this example. Let me try to explain what I thought last week was the distinction you were trying to make.
>
Ok, I still think it is simplest representation of issues that have been
discussed, but will follow your example here.
>
>
> First, my reading of the non-xml hierarchical profile says that the key step is that the context handler must put in the context the following:
>
>
>
> the id(s) of the resource
>
> the id(s) of the parent(s) of the resource
>
> the id(s) of the ancestor(s) of the resource
>
> the id(s) of the ancestor(s) or self of the resource
>
>
> we can ignore the last as it is by definition the union of the first and third.
>
>
Yes, they have already been added.
>
>
> My understanding was that the issue or DAG or Forest boiled down to the fact that in some cases, the DAG and forest approaches would yield different lists.
>
>
That is correct.
>
>
> Specifically, I thought that your point was that in the forest model, the resource would only have ancestors that were in the one of the hierarchies which the resource belongs to. Whereas in the DAG, the resource could have ancestors which were not in the same hierarchy, but which were in a hierarchy with a parent or ancestor of the resource.
>
That is also correct.
>
>
> Let me try to give an example of what I think you mean.
>
>
>
> A resource R is a member of the red hierarchy which consists of its parent A and A's parent B.
>
>
>
> B-A-R
>
>
Ok, let me add direction: B->A->R
>
>
> R is also a member of the blue hierarchy which consists of parent X and X's parent Y.
>
>
>
> Y-X-R
>
OK, Y->X->R
>
>
> R is not a member of the green hierarchy, but A is and so is A's parent Z.
>
>
>
> Z-A
>
OK, 3rd hierarchy, no problem: Z->A
>
>
> Now if I understand you, for Forest the list would be:
>
>
>
> Resource: R
>
> Parents: A, X
>
> Ancestors: A, B, X, Y
>
>
Yes, I agree.
>
>
> However for DAG it would be:
>
>
>
> Resource: R
>
> Parents: A, X
>
> Ancestors: A, B, X, Y, Z
>
>
Yes, I also agree.
>
>
> Please tell me if this is correct, or if not explain what you mean.
>
At this point we appear to be "on same page". :)
>
>
>
> If this is correct, as far as I can see, the difference will never be in the parents, only in non-parent ancestors.
>
>
Yes.
>
>
> Hal
>
That's it? Ok, well the problem I see here is that if you go and collect
applicable policies for DAG, then if there is policy on Z it will be
applicable to R.
It you are modeling "intersecting hierarchies" then this would be
incorrect for any use cases that require this model. For example company
departments on different floors of building. Policies associated with
floor 2 should not be applicable to descendants of department members on
floor 2 who are on other floors.
However, if you are modeling "sub-assemblies" or "code-versioning" type
resource collections, then DAG might be more appropriate since it
automatically sweeps up subtrees as opposed to individual nodes.
Thanks,
Rich
>
>
> ________________________________
>
> From: Rich.Levinson [mailto:rich.levinson@oracle.com]
> Sent: Thursday, February 26, 2009 7:23 PM
> To: Daniel Engovatov
> Cc: xacml
> Subject: Re: [xacml] Example of dag and forest used to manage collection of resources 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.
>
> Simply saying
>
> "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.
>
> Thanks,
> Rich
>
>
> Daniel Engovatov wrote:
>
>
> On Feb 26, 2009, at 2:18 PM, Rich.Levinson wrote:
>
>
>
>
> 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.
>
>
> I did address the example. I have said that managing a "farm of sharable computers", or anything else of that nature should not be a part of XACML. There is a multitude of possible structures that we could possibly address, but trying to standardize them is a folly. It should be left to an industry/vendor/domain specific profiles.
>
> 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".
>
>
>
>
> 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.
>
>
> 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.
>
>
>
>
>
> 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.
>
>
> 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.
>
>
>
>
> 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.
>
> 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.
>
>
> Daniel;
>
>
>