Hi Erik,
In my previous email I tried to show how the forest can cleanly handle
the use case.
I am not sure why you say:
- "We must have a single consistent hierarchy to work on."
In the example I gave a couple weeks ago:
http://lists.oasis-open.org/archives/xacml/200902/msg00058.html,
I showed how multiple hierarchies across a common set of resources
could be represented by an equal number of columns in a table, where
each column represented one hierarchy. Optionally each column could
have an adjunct column with the names that are used for the members
within each hierarchy, but, functionally, that's a "bellandwhistle".
I also showed that the DAG could be made from this by considering the
columns to altogether be considered as a 2 dimensional table, and that
the DAG could be formed by "compressing" the data in the rows to the
left. This would save some space, but also destroy the columns.
If I am not mistaken, there is no actual requirement to create the DAG,
except for possibly some performance gains. However, if the cost of
performance is such that the operations no longer can be made to work,
then this does not appear to be reasonable choice to make.
Finally, none of these discussions have really changed anything as far
as I can see in terms of the basis on which I put together the v5-02
spec. The descriptive text in the glossary is optional. It is only
there to be helpful. Section 3.2.2 and 3.2.2.1 describe the forest and
URI alternatives respectively for those use cases where creating a DAG
does not work or, in general, for people who prefer to keep their
hierarchies intact when creating a model around which to develop
policies.
Thanks,
Rich
Erik Rissanen wrote:
49B87AB7.2000402@axiomatics.com" type="cite">
Hi Rich,
See my previous email for an explanation why it will not be possible to
define the profile in terms of multiple hierarchies. We must have a
single consistent hierarchy to work on. The 2.0 profile talks about
multiple parents, so it works on a DAG or forest in addition to a plain
tree.
Anyway, I've completely lost track of the various proposals for how to
proceed with the profile text. :-) Maybe it's time for a new working
draft after today's call? It would be so much easier to talk about a
specific document, rather than lots of "imaginary" proposals from
several people. :-)
Regards,
Erik
Rich.Levinson wrote:
Hi Erik,
Previous email was simply to respond to what I believe was the
inaccurate premise about on which you started your email.
That aside, let me respond to the content of your email. You say:
"if we define the profile in terms of the ancestor attributes.
This corresponds to that for the purposes of the profile, there is
an already defined, _single_ "hierarchy" (if we allow a general
interpretation of the term), which is "flattened" to ancestor
attributes. The profile does not have to deal with inconsistencies
in multiple hierarchies."
The assumption you are making here appears to be that the resources
are simply part of a predefined hierarchy. *There is a big problem
with this assumption, when you consider it in terms of the algorithms
defined in section 3.2.*
* These algorithms (3.2) presume that the requested node can have
multiple parents and those parents also can have multiple
parents etc.
* If we are also to take as a given, that this "hierarchy" has
already been "flattened" in terms of ancestor attributes, then
that assumes we have already erased any original hierarchical
relationships.
That is the problem: the prescription in section 3.2 essentially tells
customers that they must turn their multiple hierarchically arranged
forest of resources into a DAG in order to use this profile.
My proposal allows you to do exactly that, and if that's what you want
to do, use section 3.2.1 of my proposed revision which is exactly what
is in the existing profile.
However, if as I believe is perfectly reasonable, that customers do
not want to do a preprocessing step that effectively destroys their
existing hierarchies in order to create a DAG with all of its
problems, then I am offering section 3.2.2, which saves them the
trouble of having to do this DAG pre-processing, and allows them to
work with their pre-existing forest as is, instead.
And, finally, once again, if they have their resources hierarchically
named, as prescribed in section 2.2, they can use the forest model
from section 3.2.2 without the need to create the ancestors, because
they already have them in the URIs.
The issue here seems to be the ancestor model for forest. The existing
algorithms basically suggest that the customer cut down their original
forest and replace it with a DAG.
Section 3.2.2 says that instead of replacing the forest with a DAG,
determine the ancestors by following the original hierarchies
directly, which of course you can't do if you have already replaced
your forest with a DAG.
Or if you didn't replace your forest and just created a DAG in front
of it, section 3.2.2 says disregard this DAG and process the forest
directly.
One final note: you made the following point twice in your email, so I
want to clarify that I do not believe what you are claiming is, in
general, a problem:
* "Once you start adding a resource to multiple, independently
defined hierarchies, *you can get inconsistencies.* Two nodes
may have reverse ancestor relationships in two different
hierarchies."
* "for the purposes of the profile, there is an already defined,
_single_ "hierarchy" (if we allow a general interpretation of
the term), which is "flattened" to ancestor attributes. The
profile does not have to *deal with inconsistencies* in multiple
hierarchies"
These "inconsistencies" you are referring to, only exist if you want
to create a DAG. If you just work on the forest, they are not
inconsistencies and do not create any problems. It is only when you
map the forest into the highly constrained DAG that you find that by
forcing a DAG on the forest, you effectively force rules on the forest
that only need to be there if you want to create a DAG.
As has been discussed, not everyone believes that transforming a set
of hierarchies into a DAG is a good idea. It may be for some
applications, like creating dictionaries of resources, but that is not
an access control application. It is an inventory-type application.
For access control there is no requirement to create a DAG, and little
incentive to do so, if it will force rules on assignment of relations
for resources that are not needed and prevent creation of
organizational resource relations that are considered desirable.
On the one hand, technically, this issue boils down to:
* How to define the ancestors (DAG or forest)
On the other hand, operationally, the issue boils down to:
* Do customers want to represent their resources in the form of a
DAG, which will effectively make it impossible for them to
manage multiple hierarchies independently.
For the first technical point, my proposal offers both options.
For the second operational point, my proposal offers 3.2.2, 3.2.2.1 if
they find the DAG too restrictive.
All this is done with no change in functionality, but simply be
explaining the problem being solved by the profile more clearly, which
makes obvious the alternate set of algorithm in section 3.2.2.
Thanks,
Rich
Rich.Levinson wrote:
Hi Erik,
I think that you are misinterpreting what I said in the previous
email. Let me try to be more explicit:
1. Start with an unnamed collection of resources. Let's say there are
N individual identical resources.
2. On a laptop, using a program, create an array of N variables, for
example
int parent[] = new parent[N];
3. Now I can start creating my hierarchy by assigning a value to
these parent ints which somehow identifies another of the
resources in the collection. I believe at this point that I must
pick some method to identify the elements of the collection,
otherwise there is no meaning to this value.
4. For the sake of discussion, let me choose to use the index of the
element in the array as the way to identify the parent. Therefore,
I can pick any element in the array and assign it a value in the
range 0->N-1. For example, I can say:
parent[i] = j;
5. Using this technique I can create a hierarchy of these resources.
This is basically an implementation of the example I gave in this
email I was asked to prepare to help the TC understand the issue by
example:
http://lists.oasis-open.org/archives/xacml/200902/msg00058.html
The bottom line is that in order to assign parent child
relationships, you need to have something to hold the assignment
artifact. There will be one artifact holder for each resource. When
you assign an artifact to a holder, this artifact must somehow
identify another resource in the collection in order for it to have
any meaning in terms of this operation of assigning a parent child
relationship.
So, in the example I gave in the email, each of the 2 customers
assigned parent child relations to the empty boxes on the piece of
paper they were each handed.
When customer 1 handed the paper to the collection manager, the
manager did the equivalent of the above.
The fact that I had id-numbers painted on the box was just to help
people understand the problem. The example works equally well if you
paint the numbers on the boxes later after the customers have handed
in their papers and the manager entered their data into 2 arrays.
The manager would then create a 3rd array and assign these painted
numbers then.
This is totally consistent with what you are calling "Way A":
"In way A, one first defines the parent-child relations on the
resources themselves, independent of anything with names. After that
is done, one can give name to the nodes. There is no risks of
inconsistencies."
So, I do not understand, what you are trying to indicate in your
email, since it appears to premised on an assumption you are making
that appears to be inconsistent with what I have been saying in these
emails. Since I believe I have been totally consistent in my
representation of the problem, we should be able to unambiguously
resolve this "Way A", "Way B" discussion, and possibly come up with
some terminology on which we agree so that we may continue this
analysis without having to continually re-explain what we are talking
about.
Thanks,
Rich
Erik Rissanen wrote:
Hi Rich,
What you describe is what I meant with "Way B".
In way A, one first defines the parent-child relations on the
resources themselves, independent of anything with names. After that
is done, one can give name to the nodes. There is no risks of
inconsistencies.
In contrast, in Way B, you initially have a set of hierarchies. Once
you start adding a resource to multiple, independently defined
hierarchies, you can get inconsistencies. Two nodes may have reverse
ancestor relationships in two different hierarchies. This is
inherent in this model, and has nothing to do with how we formulate
the profile.
Anyway, all this is outside the scope of the profile itself if we
define the profile in terms of the ancestor attributes. This
corresponds to that for the purposes of the profile, there is an
already defined, _single_ "hierarchy" (if we allow a general
interpretation of the term), which is "flattened" to ancestor
attributes. The profile does not have to deal with inconsistencies
in multiple hierarchies.
The single "hierarchy" which the profile works on, may be a the
result from a preprocessing step where a number of independent
hierarchies have been merged. But not, it's not always possible to
merge hierarchies consistently.
Best regards,
Erik
Rich.Levinson wrote:
Hi Erik,
In fact, my view has always been "Way A". My conceptualization is
that there is a collection of physical resources and that an
organization organizes the resources in various ways, and, in
particular, as hierarchies. Every time someone adds a resource to a
hierarchy, the resource gets a new name and parent attached to it.
After this has been done for a while the net result is that the
collection of physical resources can be viewed as having one or
more hierarchies "draped" over it. For every hierarchy a resource
belongs to, it, in general can be assumed to be assigned a name and
a parent. Hopefully, we agree that is "Way A" and based on that
assumption, it should be fairly straight forward to understand the
issue:
Ok, so, based on your formula, what I do is:
* follow the parent-child relations
* this is fine at the requested resource, I find all my parents
* now I go to each parent and collect all of its parents ***
This is where the problem is introduced. As soon as I collect a
parent of my parent that is not a member of a hierarchy I am in, we
have defined a DAG.
If I stick to parents of parents that are members of hierarchies I
am in, then I am in a forest.
The diff in these 2 methods is that the DAG method doesn't bother
to look at whether the requested node is a member of the hierarchy
that it is following from the requested node's parent.
The problem compounds as you follow each generation.
Thanks,
Rich
Erik Rissanen wrote:
Rich, Hal and All,
Just a quick comment. I don't think that just because a resource,
or an ancestor, has multiple normative names, the hierarchy would
become a DAG. We need to differentiate between resources and names
of resources.
One way ("Way A") to think of the problem is that the parent-child
relations are bound to resources, not the resource names. To
collect the ancestors to the request, one has to follow the
parent-child relations, and then include all names of all ancestor
resources. That is what the profile tries to say. (I think.) And
that would be correct in my opinion. And would not necessarily
mean that the profile was made to support a DAG.
An alternative way ("Way B") is to think that the parent-child
relations are tied to the resource names, not the resources
themselves (or that there are no resources independent of names).
I get the feeling that at least Rich looks at it like this.
I think way B is problematic since it opens up the possibility
that parent-child relations between different names for the same
resources conflict with each other. This is what I meant with
"consistency" in my post last week. By adopting way A, we avoid
the problem.
Best regards,
Erik
Rich.Levinson wrote:
/ /I agree with that. However, it is the algorithms that allow
and appear to encourage collection of non-member ancestors. Here
is the text:
For each ancestor of the node specified in the “resource-id”
attribute or attributes, *and for each normative
representation of
that ancestor node*, an <Attribute> element with AttributeId
“urn:oasis::names:tc:xacml:2.0:resource:resource-ancestor”.
The <AttributeValue> of this <Attribute> SHALL be the normative
identity of the ancestor node.
The DataType of this <Attribute> SHALL depend on the
representation chosen for the identity of nodes in this
particular
resource.
This <Attribute> MAY specify an Issuer.
For each “resource-parent” attribute, there SHALL be a
corresponding “resource-ancestor” attribute.
If the requested node is part of a forest rather than part of a
single tree, *or if the ancestor node has more than one
normative
representation*, there SHALL be at least one instance of this
attribute for each ancestor along each path to the multiple
roots
of which the requested node is a descendant, *and for each
normative representation of each such ancestor*.
It is the addition of all the "...each normative representation
of each such ancestor" which clearly opens up these algorithms to
imply a DAG. Without these phrases, it is still not particularly
tight, but alone they could be interpreted to imply a forest.
With the phrases DAG is inescapable.
The point is that these are ancestor nodes and nothing ties their
normative representations to be those that are in the hierarchies
of which the requested node is a member.
This IS the problem. It is these specific algorithms and what
they say about ancestors that forces you into a DAG. It clearly
includes hierarchies of which the requested node is not a member.
Therefore, it sounds like we are in agreement. That there is a
problem that needs to be fixed.
Thanks,
Rich
Hal Lockhart wrote:
As I have said repeatedly, the only problem with combining the
initial hierarchies into a DAG arises if the original
hierarchies include hierarchies of which the Resource is NOT A
MEMBER.
Hal
________________________________
From: Rich.Levinson [mailto:rich.levinson@oracle.com] Sent:
Tuesday, March 10, 2009 8:56 AM
To: hal.lockhart@oracle.com
Cc: Erik Rissanen; xacml@lists.oasis-open.org
Subject: Re: [xacml] Summary of what I think I said on the call
about the hierarchical profile
Hi Hal,
The fact is that it is the algorithms in section 3.2 that imply
that the hierarchies are combined as a DAG. There is no problem,
in general, if the one or more of the original "hierarchies"
happens to be a DAG. The problem is that the algorithms force
the combination of the originals, DAG or forest.
The recommended changes to the spec that I have proposed is to
have a choice of algorithms for combining the hierarchies. That
way customers can decide for themselves which is appropriate for
their resource collections.
Thanks,
Rich
Hal Lockhart wrote:
I think the source of confusion was this. Daniel's point was
that the initial representation of each hierarchy could be a
DAG, since it is a generalization of a tree. Rich's point was
that if you start out with all the hierarchies in whatever form,
and you include defined hierarchies which do not include the
Resource in question as a member, even though ancestors of the
Resource are members of the hierarchy, if you combine all the
hierarchies you lose the information about the original
hierarchies necessary to be able to distinguish whether the
nodes above the Resource are true ancestors or not.
My comments on the call and below on the DAG were based on the
premise that we started out with one or more hierarchies merged
them into a DAG and then determined the parents and ancestors.
Under this premise, the use of a DAG seemed like a intermediate
step of no particular interest. I now see that Daniel was trying
to say that at the very beginning, any of the distinct
hierarchies may be multi-rooted and thus represented as a DAG.
My feeling now is to make minimal changes to the document. I
think if we make it clear that the starting point is one or more
hierarchy each of which may be singly or multiply rooted, but
only hierarchies which contain the resource. I don't object to
the individual hierarchies or their union as being described as
a DAG, but the ancestors could also be computed by examining
each hierarchy in turn.
I have some concerns about the URI part, which I will put in a
separate email.
Hal
-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Monday, March 09, 2009 7:43 AM
To: hal.lockhart@oracle.com
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Summary of what I think I said on the
call about the
hierarchical profile
Hi Hal and all,
If I understand you correctly, then what you propose is
the exact same
thing as I proposed, except I used the DAG term because I
thought we
wanted to specify how you would get the list of ancestors
from a graph.
If that is not the case, then we can drop the terms DAG,
forest and so on.
So, basically we just say that you have one or more
hierarchies in which
the resource is part of and for the request context you send
in the
resource itself, and its ancestors.
The only thing which I am still uncertain about in your
email is whether
you are trying to ban the use of a DAG. Sending a list of
ancestors this
way would work for a DAG, which I think is ok.
Best regards,
Erik
Hal Lockhart wrote:
This is an attempt to summarize what I said on
the call today. I have
changed the order a little and added a few
extra comments.
First, let us agree that the hierarchical profile
assumes that some
party needs an AZ decision about a resource
that is part of one or more
hierarchy. The profile does not define what the hierarchy
is, the
semantics of the relationships among its members or anything
like that. It
does define how to extract a small subset of the information
and put it in
the Request Context.
Now let us consider the two modes of operation in
the draft Rich created.
He called them DAG and Forest mode. If we look
at my msg from Tuesday I
give a small example of some hierarchies and a case where
the two methods
produce different information in the request context. Note
that they will
never differ in their parents, but the DAG mode can include
ancestors
which are not actually in the same hierarchy as the
resource. In the
example, Z is an ancestor of an ancestor (parent actually).
Another way to express this is that in the DAG
model, the "is an
ancestor" relationship is transitive. Every
ancestor of an ancestor is an
ancestor. In the forest model, it is only transitive within
a given
hierarchy.
It is my opinion that the intent of the 2.0
profile, although it is
certainly not clear and definitely contains
mistakes, was that the
information put in the request context only include
hierarchies of which
the resource is a member. In my example, the Z-A hierarchy
would not even
be considered. Therefore the issue of transitivity does not
arise. In
effect, we are always using the forest model.
Therefore I do not believe it is necessary to
have the forest and DAG
modes. I do not see any valid usecases for the
transitivity property and I
do not think it was intended in the 2.0 version of the
profile. As an
example, my father is a navy officer. I am below him in a
family hierarchy,
but that does not make navy admirals my ancestors in any
way. If my father
was the resource, the navy hierarchy would be relevant, but
if I am the
resource, it is not. I think all that is required is to
clarify that only
hierarchies of which the resource is a member will be given any
consideration in computing parents and ancestors.
Next I talked about loosening the requirement
that resources be named
using a hierarchical URI. We previously agreed
to allow strings. My only
concern was to allow strings or URIs, not URIs carried in
strings. This
allows URI typed operations to be used when the name
actually is a URI.
Eric proposed that we allow any XACML datatype, and I agree.
People who
want the functionality of parsing a hierarchical URI can use
a URI and
others can use whatever is convenient for them. Of course it
is possible
that the information on ancestors and parents might be
inconsistent with
the structure of the hierarchical URI, but that was true in
the 2.0
profile and there are lots of other legal ways for the
request context to
contain inconsistent information. If you put sand in your
car's gas tank,
it will not run, an XACML PDP is the same. In other words,
GIGO.
Finally I said I generally supported Erik's
proposed plan of action with
one exception. Thinking about the problem
independently, I had come to the
conclusion we should totally eliminate mention of a DAG,
before reading
Erik's email. Here is my reasoning. As I said above, we
start out with a
rich set of information about the various hierarchies, at
the end we end
up with a request context which contains nothing but an
unordered list of
parents and an unordered list of ancestors. A DAG is simply
a possible
intermediate step. It contains more information than the
request context,
but less than the original set of multiple hierarchies.
Talking about a
DAG doesn't seem to me to help in explaining what the
context handler must
do, because it represents neither the starting point nor the
ending point,
just one possible intermediate step.
What I did not say on the call.
During the call I was thinking of the distinct
hierarchies as being
singly rooted as in my simple example. However,
after the call I realized
that the algorithm I mentioned completely eliminates the
problem of
transitivity regardless of whether the initial, distinct
hierarchies are
singly or multiply rooted. Therefore it doesn't matter
whether the
individual hierarchies or their union is represented as a
forest, dag,
polyarchy or database table.
To be explicit here is what I mean:
1. Start with all hierarchies in the space of resources
of the type of
interest.
2. discard all descendants of the resource.
3. discard all resource hierarchies (and their members)
which do not
contain the resource.
Now, however you represent the information, any
reasonable algorithm to
enumerate the parents and ancestors, discarding
duplicates will produce
the same results, ignoring order. The issue of transitivity
will not arise,
thus Rich's concern is satisfied.
Hal
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. Follow this link to all your TCs
in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC
that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|