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 am not sure exactly what you are driving at here, but I include comments below:

Daniel Engovatov wrote:
For example, all the PCs in a company have serial numbers. When managers create policies, they have the physical resources in mind and may organize them hierarchically for various purposes. A department manager may label the PCs in his/her dept according to some hierarchical structure in the dept organization and assign policies accordingly. At the same time these PCs are company property and may be labeled independently by the IT dept in terms of who is responsible for maintenance on them.

If someone wants to take one of these PCs out of the building, maybe there is a policy that says even if the employee's manager says it is ok, the facilities manager must also approve before permission is granted. This can be modeled with a dept hierarchy and a facilities hierarchy, and there are rules within the hierarchy producing a result and policy combining between the 2 hierarchies that can resolve conflicts such as described above.

In the above example the /a1/b1/c1 might be the dept hierarchy and /a2/b2/c2 might be the facilities hierarchy.

There is no need for separate hierarchies here if the "remove from building" is a single access decision.  In your example, let's "PC" be a resource, "DEPT" be a department, and "FACILITIES" be facilities.     In this case resource-ancestors will be {"PC", "DEPT", "FACILITIES"}    (or {"a1", "a2", "b1", "b2", "c"} )  There is no need for two hierarchies.   That is the advantage of not being pidgeonholed into a single inheritance URI-like scheme.
The hypothetical scenario I am describing is based on two sub-organizations within a larger organization which operate independently on the same set of physical resources. In general, the operations are independent, but in some cases there is need for both organizations to be brought into some kinds of decision. The dept manager has set up a hierarchy for controlling the PCs in his department, while the facilities manager has set up an independent hierarchy on the same set of PCs for controlling the maintenance on those PCs from within the facilities organization.

The parent organization recognizes that there may be situations where the decisions of the two organizations may come into conflict and have set up combining algorithms above the two hierarchies to resolve differences.

From what you are saying, and I do not follow your example, it sounds like it is possible to restructure the existing hierarchies into a new framework where somehow the existing hierarchies no longer need to exist. This may be useful as an academic exercise, but operationally, one would need to educate the company, the facilities and the department about this new uniform paradigm and explain to the people involved why they no longer need the hierarchical representations.

However, I do not understand precisely what you are recommending:
  1. 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.
  2. The ancestor nodes of /a1/b1/c1 and /a2/b2/c2 are the same, namely {/a1, /a1/b1, /a2, /a2/b2}. I do not see how you can say {"a1", "a2", "b1", "b2", "c"}. "c" is not one of the terms. "a2" and "b2" by themselves are not normative identities.

It is also uniquely defined by a URI if a URI scheme has been applied to the same resources, since all the ancestors are readily identifiable within the URI.

That's a bit of a contorted way to represent a simple bag of strings.
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.

 Within the policies themselves, there would generally be no need to include this attribute except possibly for reporting purposes.

Then what exactly is the problem?   Policy, as specified, can be evaluated deterministically.   The mapping of physical entities into policy resources is outside of the scope of this profile.   I do not see anything broken here.
I was addressing the statement you made that you thought I had a problem confusing the physical and policy resources. I was showing that the physical mapping was simply an orthogonal property of the node which of necessity must include an identity for each of its purposes, in this case: one for the dept, one for the facilities, and one for the physical identifier. However, for policies, the physical identifier need not be used and may be regarded as a resource attribute on the node entity outside of the policy structures, but available to be included if necessary.

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.



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