Hi Daniel,
I will try to continue the example below to see where it leads. I am
only taking it to the point of setting up the names of the resources,
starting with the serial numbers as a given, then suggesting one
possible manner that the 2 organizations might use to apply their own
labelling to these resources. What I am trying to do is determine the
point at which we begin to diverge on how we are envisioning this
general problem.
What I am also trying to do is come up with a "story" that I can tell
people, who I am advising on the use of xacml, how they might step by
step go about using xacml to represent policies to govern their
resources that they have chosen to organize in a hierarchical manner
(as explained in prev email, incl below, re: manager's
conceptualization of projects).
Daniel Engovatov wrote:
Hi Daniel,
If you would care to elaborate on the use case of 'access to a "PC" is
governed by rules applied to both "DEPT" and "FACILITIES" ', I would be
interested, however, with the info you have given, I simply do not see
a hierarchy represented there. I am truly interested, because when I do
not understand something, I generally assume that there is information
of which I am not yet fully cognizant, as was the case when Erik
responded with his example that showed usage of the ancestors
capability.
This is the most basic example that is the whole idea of the
profile. What we are trying to achieve is to define a mechanism to
write a rule that applies to a resource and all resources that are
connected to it through "inheritance".
"PC" is a resource representing a PC. "DEPT" is a resource
representing a department. "FACILITIES" is a resource representing
facilities. When I define an attribute of the "PC" resource that
lists {"PC", "DEPT", "FACILITIES"} I implicitly define a hierarchy that
make rule written on "DEPT" and "FACILITIES" to apply. It does not
matter what is the exact structure of that graph: "PC" may have two
"parents", or "DEPT" may be part of "FACILITIES". The only thing of
concern is how to collect a bag of applicable rules.
In the use case I am considering, for the sake of concreteness, I am
assuming that each PC has a record in a table that in order to support
its management has at least the following 3 fields:
- PC serial numberL: r*
- DEPT id: /a1/*
- FACILITIES-id: /a2/*
Therefore, in the example of this use case from earlier email, my
"database" would contain the following records:
PC DEPT-id FACILITIES-id
r1 /a1
r2 /a2
r4 /a1/b1 /a2/b2
r5 /a1/b1/c1 /a2/b2/c2
Basically, the DEPT manager has decided to name the resources that
are under dept control, r1,r4,r5 using the /a*/b*/c* scheme where the
value "1" is used to indicate DEPT names. (Actually, I think all that
is necessary is for the root to have a unique name, but let's ignore
that for now)
Similarly, the FACILITIES mgr is using the names with the "2" suffix
for the resources under facilities control, r2,r4,r5.
My questions for you now are:
- do you agree that it "could" be set up this way? (while
recognizing there are other ways as well)
- is the issue that we are discussing simply that the naming I have
chosen for the DEPT-id and FACILITIES-id is simply an "unnecessarily
complex" naming scheme, and that I could have chosen something simpler?
- if the above is the case, then what are the simpler schemes for
these ids that would represent a "better" approach?
Thanks,
Rich
The whole point here is that you do not want to and do not need to
concoct any hierarchical naming scheme or to restrict it to any
particular structure.
My experience with hierarchies includes the
following as a common use case:
A manager conceptualizes a project, large as a whole company or govt or
small as a simple team leader scoped project, and creates a
hierarchical structure within which resources: people, equipment,
facilities, etc. are deployed. As such, for one example, the manager
creates a hierarchical org chart of the people in the project and
defines responsibilities etc wrt to that org chart. When the project
commences, individuals are assigned their places within the hierarchy
and they have the hierarchical identifier added to their identity
properties. Such is the case with the /a*/b*/c* that I used in my
example. "r5" was the serial number on the PC that doesn't change,
however, the hierarchies that PC participates in will generally vary
over time, which is reflected by the identifiers from the various org
structures that it is assigned.
One additional realization that has occurred to me after last night's
email is that when resources are assigned URIs for the purpose of being
within a particular organization, that set of URIs satisfies the
requirements of the algorithms ("corrected" or not) in section 3.2.
This is because, as I pointed out, without being fully cognizant of the
implications at that point, the URI, itself, implicitly contains the
normative identity of "self", "parent", and all "ancestors" by nature
of its construction.
Yes, but such a scheme is a subset of the profile, and there is no need
to add it. It will only confuse the users. We do not want to
imply that there is any tree behind it, so even using the "/" notation
to represent a hierarchy is confusing.
We are not in the business of defining enterprise resource
ontologies. We are just providing a generic mechanism to map them
into access control policy inheritance.
Current "ancestors" profile is definitely not the only possible
approach. We may want to add a different profile, but I do not think
we should overload the current one with unrelated concepts.
Daniel
|