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 Forest boiled down to the fact that in some
cases, the DAG and forest approaches would yield different lists.

 

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 Forest the list would be:

 

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:] 

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;