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;
