Hi Erik,
Thanks for the input. I think there are still some fundamental
misunderstandings of what exactly the issue is that I have been raising
here (maybe not, maybe I am misunderstanding something in which case, I
will be happy to close the issue, but not there yet). I will address
your comments below after prelim comment:
First, for people who have been observing this seemingly endless
sequence of extremely detailed emails, please rest assured that I
believe there is a significant issue that needs to be addressed. Here
are a couple introductory points to consider:
- As a result of the natural complexity of the problem of
identifying the applicable policies to apply to a requested resource
that can be known to policies under more than one "normative
hierarchical name" (where the "hierarchical" name either contains the
hierarchical info internally, as in the case of URI, or whether the
name is an unstructured unique string that uniquely identifies the
resource in some external resource collection, whereby the
contexthandler before submitting the request is able to identify and
collect all the relevant names of "hierarchical" ancestor nodes to the
requested resource node), these emails have had to contain enough
detail to address some specific somewhat subtle characteristics of the
process for collecting the list of ancestor nodes.
- To further help frame the issue, it should be commonly understood
that when a PEP submits a request, it is first handled by a context
handler, which is defined in XACML to handle input requests as follows:
- "converts decision requests in the native request format to the
XACML canonical form"
- Therefore the context handler needs to know, given a requested
resource, how to assemble the list of ancestors for that resource to
submit with the request as part of its responsibility of converting the
request to "XACML canonical form".
- The current document, before the modifications I made, had
effectively defined two methods of ancestor collection:
- an explicit method: defined by the algorithms in section 3.2
- an implicit method: implied by the definition in section 2.2 of
how to form a URI that could be used with the hierarchical profile, and
by the anyURI methods described in section 4.3 intended to be used by
policies that apply to resources identified using the guidelines of
section 2.2
- As it turns out, as can be understood in detail by reviewing the
chain(s) of emails on this subject in Jan-Feb-Mar 2009,
- the explicit methods in section 3.2 imply that the resources
are collected in a manner that assumes that policies will be written
with the "mindset" of protecting a hierarchical resource structured as
a DAG.
- the implicit methods of sections 2.2/4.3 effectively imply that
the resources are collected in a manner that assumes that policies will
be written with the "mindset" of protecting a hierarchical resource
structured as a forest. (For example, if a node has 2 normative URIs,
then it is a member of 2 trees in the forest - policies written using
anyURI will be applicable if their scope includes either of the 2
normative URIs
- This is roughly the point I was at when I started raising this
issue. The first thing I noticed was that there were effectively 2
different ancestor collection methods at work, which had the following
curious properties:
- the methods in section 3.2 involve collecting ancestors of the
resource that are not "direct" ancestors, in the sense that if the
resource's parent has a parent that is not directly connected then
policies associated with that ancestor apply to the requested resource
- To use the common "sibling" terminology, a "direct" ancestor
would be a bloodline ancestor, such as a grandparent. In "indirect"
ancestor would be equivalent to a "step-grandparent", i.e. one not
connected by bloodline, but that established a relation with the
bloodline parent "after the fact" and now has an "indirect" relation
with the "step-grandchild".
- So the question which "lights all the fires" on this issue is
whether a "step-grandparent" should have an equal relation with the
requested resource as a bloodline "grandparent".
- It turns out that with the DAG model there is no way for the
context handler to differentiate between "grandparents" and
"step-grandparents", so the answer is ALWAYS that these are treated
equally.
- By comparison, it turns out that "by default" (i.e. the
contexthandler just collects the set of URIs from the resource with no
need to search for ancestors because all the needed URIs are right
there) using URIs that only grandparents will be selected.
"step-grandparents" could be obtained if desired, but simple out of the
box URIs give you only the bloodline ancestors.
- The reason I am concerned about this issue is that from a
security perspective, it makes little sense to me to force commonly
understood hierarchies, such as organization charts, geographic
breakdowns of organization operations, whether within a building or
around the world, to suddenly have policies that are intended only to
apply to the resources within these specified domains, suddenly apply
to resources outside of these domains.
- Similarly, resources within these domains will find themselves
subject to policies applied to resources outside of these domains.
- For example, if I am a manager in the United States, and there
is a policy that says employees in the United States may treat the 4th
of July as a holiday, then anyone outside the United States who has any
superior inside the United States will be subject to this policy.
- Why? Because the resources are treated as a DAG. DAGs do not
deal with resources individually, they only deal with subtrees.
With that background, let me address Erik's points:
Erik Rissanen wrote:
49AE6BE2.3060302@axiomatics.com" type="cite">Rich
and TC,
I have reviewed the draft you have posted (wd 05-02) as well as the
recent discussion on the list, and I think the draft needs some more
work.
I agree with you that the old profile had lots of ambiguities and small
errors in it, and I think you have done a good job at spotting them and
you have improved the text in many places.
However, I also think that the new work you have added in there
complicates matters needlessly. There are two reasons for that:
1. You try to write the profile so it works with multiple intersecting
hieararchies. I think that is the wrong way to do it. It should be
specified for a single hierarchy only. If you need to apply it on
multiple hierarchies, the way to do it is to preprocess the hierarchies
by merging them into a single hierarchy. This joint hierarchy also
needs to meet some consistency criteria, or the whole thing becomes
meaningless and inconsistent. See more about that below.
This is an invalid assertion. I leave the profile unchanged, except for
distinguishing the DAG and forest/polyarchy distinctions.
The DAG is inherently is multiple "overlapping" hierarchies that can be
combined into a "single multiroot hierarchy" (see ref prev email)
http://en.wikipedia.org/wiki/Directed_acyclic_graph#Properties
The forest is inherently multiple "intersecting" hierarchies, that can
be combined into a "single multiroot disjoint hierarchy" identical in
every way to the DAG except that:
- it retains the identity of the multiple hierarchies as its
disjoint property
- it is not restricted from having "cycles" as long as the circuit
travels over at least segments from 2 disjoint hierarchies
As should be clear from above description, and all previous emails on
this subject, the preprocessing is done by creating a joint hierarchy.
The only difference between the DAG and the forest is that with the
DAG, potentially useful information about the joint hierarchy is thrown
away, with the forest it is kept. All is done before contexthandler
submits request based on what contexthandler is capable of doing with
the resource collection of which the requested resource is a member.
Unfortunately, this statement appears to characterize the conceptual
gap on this issue:
"This joint hierarchy also needs to meet some consistency
criteria, or the whole thing becomes meaningless and inconsistent."
All one needs to do is peruse the emails to quickly realize that it is
the profile that mixes the DAG/forest concepts, which renders the
existing spec "meaningless and inconsistent" and that my effort has
been to separate these concepts in order to establish meaning and
consistency to the contents of the spec.
49AE6BE2.3060302@axiomatics.com" type="cite">
2. You use the "root" concept. That is actually not required at all. As
you have realized, the concept of a root in a DAG becomes messy to
define and handle. I think we should just drop any reference to a
"root" in the whole profile. All we need are "ancestors", and those are
found by following the edges upwards. Not down from the root, so the
root doesn't have to be defined. (In fact, in a DAG, there is not
necessarily a unique root anyway.)
DAG is a directed graph. If you keep following any parent relationship
recursively from the requested node you will come to one of the roots
of the DAG. If you chose different parents along the way you will come
to a different root, in general. In a DAG, it doesn't matter from the
perspective of the requested node, all roots are functionally
equivalent in the sense that there is no inherent distinction as to the
status of one root vs another.
In the forest model, you can have exactly the same layout as any DAG.
And you can traverse the same recursive paths to any of the same roots.
The only difference along the way is at each step you know whether you
are proceeding along the same hierarchy as in your previous step or
whether you are switching to another hierarchy.
In the world of security, these hierarchical paths are commonly known
as "lines of authority". Generally, in security applications the notion
of "clear lines of authority" is desirable, and the notion of "tangled
lines of authority" is detrimental. This is precisely the distinction
of forest (clear lines) and DAG (tangled lines).
49AE6BE2.3060302@axiomatics.com" type="cite">
Finally, I think we should write the normative sections so they target
a DAG only. Trees and forests follow as special cases. We can add
explanatory text to make this clear, but the normative parts become
much simpler if we don't define many different types of hierarchies.
Obviously, from my above remarks, if we were to target "only" one of
DAG or forest, I would choose forest because
- forest represents "clear lines of authority" for security
applications
- URI as recommended in section 2.2 already provides it out of the
box
and I would not choose DAG, because
- DAG represents uncontrolled ambiguous lines of authority
- DAG is intended for sub-tree, or whole "sub-assembly at a time"
type of operations, which is why it is popular in source code control
systems. If we think global enterprises can be modeled as special case
of source code control system then DAG will be great, otherwise, a
forest is needed.
Bottom line: I think when the dust and smoke is removed from this
issue, we are left with what kind of model do we want for resources: a
highly structured model as in forest, or a more loosely structured,
"social network" type of model such as DAG.
Or we could follow the path I have represented in the profile which is
that you can choose either, as appropriate, for specific subset of the
overall enterprise resources.
Thanks,
Rich
49AE6BE2.3060302@axiomatics.com" type="cite">
I propose the following changes:
- First, a small nitpick. ;-) I don't like "Working draft 05-02". I
think working drafts should progress 5, 6, 7, 8 and so on. It's
confusing that there are several documents, all called working draft 5.
- Remove all the new definitions of "polyarchy", etc. They are not
needed. Use only the term "DAG".
- Define a hierarchy as a DAG, where the nodes correspond to resources
and the edges correspond to child-parent relationships.
- Define that each node in the hierarchy has one or more "normative
representations" (names). A normative representations is defined as an
XACML datatype value instance, which is provided in the request
(through the context handler or the PEP). A representation which is not
provided in the request is not normative, and may not be referenced in
policies.
- This is actually already implied, but maybe worth stating: if one
merges a number of hierarchies in the pre-processing step, the merged
hiearchy must be consistent with respect to node representation/naming
and the parent-child relationship. That is, if A and B are two
representations of a node and C and D are representations of another
node, and there is a relationship between the nodes, the same
relationship applies to all representations/names. So all of the
following would apply, not just some of them: A-C, A-D, B-C and B-D. I
think the complexities in what you have done Rich is much due to that
you have tried to cover hierarchies where this is not true. But those
hierarchies are not internally consistent, so we cannot make them work.
- The ancestors of a node are defined as simply the transitive closure
of the parent-child relationship.
Note that the above points imply that there is a single hierarchy which
is a DAG. Also note that I don't make use of the term "root". It's not
needed.
- Add in a couple of examples with illustrations showing a simple tree
formed DAG and a more complex DAG which is not a tree and show how the
ancestors are found.
- Remove section 1.1.1. It's not needed if we specify the algorithms on
a sigle DAG only.
- Make a separate section about the URI-only scheme, saying that "in
some cases when the resources are represented as URIs, it may be
possible to simply do matching on portions of the resource
representations". Also make it clear that the PEP and PDP must agree on
which scheme is used, or the policies won't work.
- I think that a node may be represented by any XACML data type, like a
string for instance, not just URIs. This is what the user posted to the
comments list and requested that we change.
- I think there are some problems with section 2.2. In particular, it
should not say anything about UTF-8 encoding. That's already defined by
the core schema and it's unicode consistency requirements. I think
actually that we can drop the whole of section 2.2 and allow any form
on the normative representations of nodes. There is no reason to
restrict it to a particular form of a URI. (The section on the
URI-based schema should of course contain some restrictions for how
that scheme is made to work.)
- We should not define a new identifier for a functionality named
"...:forest:...".
- There is no need to various subsections on multi-rooted hierarchies
or polyarchies. See for instance 3.2.1 and 3.2.2.
In short, I think we need very few changes compared to the original
profile. We just need to clarify the terminology and definitions, put
in a couple of illustrations, relax the data type restrictions and add
a section of a URI matching based scheme as an alternative to the other
two schemes.
Best regards,
Erik
Rich.Levinson wrote:
Hi Erik,
The hierarchical profile is ready for review as is. There are no more
changes planned.
Note: The two added identifiers in section 2.2,
"...hierarchical:forest:non-xml-node-id" and 3.2.2,
"...hierarchical:forest:non-xml-node-req" are for convenience only
and the spec could be rephrased without them, if necessary.
The profile is located at:
http://www.oasis-open.org/committees/document.php?document_id=31407&wg_abbrev=xacml
The example that Hal requested, which provides further motivation for
the changes, as well as detailed explanatory technical structure, is
at:
http://lists.oasis-open.org/archives/xacml/200902/msg00058.html
A fresh example of application of the profile using URIs that came up
yesterday on the xacml-users list is at:
http://lists.oasis-open.org/archives/xacml-users/200903/msg00001.html
Thanks,
Rich
Erik Rissanen wrote:
All,
I have posted new drafts of the core and the multiple resource profile.
See the change logs and tracked changes for details.
As far as I can tell, we don't have any open issues on the following
specs:
- Core
- Multiple resource
- Administration
- Privacy
- SAML
- Dsig
The hierarchical profile is being discussed currently and there was
discussion about improving the RBAC profile.
The proposed work on the RBAC profile seems in very early stages and
the issue (policies about management of roles) is a major topic, so I
propose that we don't bring this in 3.0.
So, could we agree on a feature freeze on the above mentioned profiles?
If so, all of the expect hierarchical are ready for review before going
to committee draft.
I also propose that if we don't get resolutions on the issues in the
hierarchical profile soon and it would appear that there are major
changes required, then we use the old version of that profile. However,
my understanding is that Rich has pretty much completed the work on
that. I haven't had the time to review it myself yet, but I will do so
now.
So, given the above, can we agree on the following?
- everybody reviews the above mentioned profiles
- We correct any mistakes
- I will fix the metadata, references, namespaces, etc,
- Go CD with the above
One final issue: we need to update the acknowledgements section of the
core. What goes in there? My name is not in there, and I would like to
include it. :-) I presume that we keep all the old names, right? John
Tolbert has requested to be added. Anybody else?
Best regards,
Erik
---------------------------------------------------------------------
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
|