[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
> 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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]