OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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,

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:

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?

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]