[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 collectionof resources for comparison
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. 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. My understanding was that the issue or DAG
or 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. 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 R is also a member of the blue hierarchy
which consists of parent X and X’s parent Y. Y-X-R R is not a member of the green hierarchy,
but A is and so is A’s parent Z. Z-A Now if I understand you, for Resource: R Parents: A, X Ancestors: A, B, X, Y However for DAG it would be: Resource: R Parents: A, X Ancestors: A, B, X, Y, Z Please tell me if this is correct, or if
not explain what you mean. If this is correct, as far as I can see,
the difference will never be in the parents, only in non-parent ancestors. Hal From: Rich.Levinson [mailto:rich.levinson@oracle.com] Hi Daniel and TC, "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. "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. "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.
"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. "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.
Hi Daniel and TC,
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.
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]