Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

["Rich.Levinson" <rich.levinson@oracle.com>]

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.

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.

Therefore the augmentation of section 3.2 need be little more than to emphasize this now obvious fact. More specifically, in the case of multiple URIs as a result of belonging to multiple hierarchies, this fully models the general DAG case as well. i.e. given a single hierarchy (one root), it is obvious that a URI scheme can be used to apply identifiers to the members of that hierarchy. Furthermore, given a DAG, because the DAG can be transformed into a set of independent hierarchies, a separate URI scheme can be applied to each hierarchy there, and when transformed back into the DAG, the nodes that appear in multiple hierarchies will simply have multiple URIs and the problem is fully defined.

    Thanks,
    Rich


Daniel Engovatov wrote:

However, I do not understand precisely what you are recommending:
I do not understand how {"PC", "DEPT", "FACILITIES"} relates to the scenario I have described. I have specific PCs, in the example they have serial numbers r5, r6. One of these PCs, r5, is identified in the "dept" as /a1/b1/c1. In the facilities org the same pc is identified as /a2/b2/c2.

No, PC is identified by "r5".   The fact that a PC is governed by a policy of the "dept" does not change that fact.   The only purpose of hierarchy is to determine an applicable set of rules for a particular evaluation.   That is it.  Constructing a hierarchical identifier is beyond the scope of that task.

So in my example access to a  "PC" is governed by rules applied to both "DEPT" and "FACILITIES".   Very simple.

It is also uniquely defined by a URI if a URI scheme has been applied to the same resources, since all the ance

URIs do not represent bags of strings. Possibly one might choose to represent a URI as a bag of strings, however, one loses the ordering in the process. If one wants to identify the specific set of nodes represented by a URI, it is a simple matter to sequentially strip one component at a time off the URI, and at each step one has the normative identity of the next node up the chain until one reaches the root.

For the purposes of defining a hierarchical policy in this model all you need is a bag of strings.   Using URI for that is not needed.   Use cases that can be represented that way are a subset of use cases that can be represented wit "ancestors" approach.  Ordering is not important in this model, just like for the rest of our rules.

At this point I fail to understand the purpose of specifically not using a hierarchical naming scheme in order to identify a set of resources that will be managed as a hierarchy. I understand that there may be cases where for some reason it may not be possible or practical to use such a naming scheme, but in those cases where it is possible and practical, I do not understand why it would not be a good idea to use it.

The purpose is that a hierarchical naming scheme is not generic enough.   For those cases when it is possible, it is still easier to use, as it does not require one to introduce a superfluous naming scheme and preserves the ability to change the structure of the inheritance graph if needed.


Daniel;