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

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

Hi Daniel,

See replies inline:

Daniel Engovatov wrote:

Based on this situation, my proposal is to enhance the existing Hierarchical spec using the URI representation in section 3.2 and indicating that this approach can be used instead of resource-parent and ancestor when the hierarchies are represented by nodes with URI resource-ids.

Using URI is a very limited approach, and it can be trivially mapped into "ancestor" approach.    Requiring a unique URI for resources is often not feasible

I am not recommending removing or replacing what is there, but simply representing the URI approach and the manner in which it can be used in parallel. When the URI is present, there is no need to create the ancestors, and one may simply use the anyURI-regexp-match as specified in section 4.3 (which I notice now needs to be updated to be consistent w core). Also, as stands, 4.3 really should have corresponding description in 3.2, which it currently does not.
I am not recommending requiring URI, but only making it available when convenient, which I think includes quite a broad range of use cases and I would not characterize it as "very limited" despite the fact that it may not be "universally applied".
My objectives are usability of the policy language. Scoping based on URI  regular expression matching is a universal technique, which is much easier than parsing URIs into parents and ancestors and then using XPath-type referencing, which is the approach indicated by Erik's example.
As you and others have indicated in the 2004 emails, there are use cases where URI is not readily available or desired, and the mechanisms from XPath are very useful there and I have no intention to remove them, but only to "correct" them, if need be, as indicated by the example I included in prev email.

The following example will show why this is doubly and actually triply specified and also why it is essential that the changes described in 1-3 above are needed.

Consider 3 hierarchies:
/a1/b1/c1
/a2/b2/c2
/a3/b3/c3
Let's say that a1, a2, and a3 are distinct roots and represent 3 separate nodes (or resources) in the overall collection.

I think you are confusing physical resources and policy resources.    Such mapping is outside of XACML.    There is no real hierarchy in XACML, we just provide a convenient normative way to represent them - only for the purpose of using it in a policy target.

I do not believe I am confusing the two. Physical resources are a fact of existence and in the case of XACML, the hierarchical identifiers are simply labels that the managers of those resources have applied to them. In the example I gave, it is the r* that represent the physical labels on the physical resources. They are an unordered flat collection. All the /a*/b*/c* are hierarchical representations of subsets of those resources. A given instance of "*" represents one hierarchy that is mapped onto the physical resources. All the policies deal with are the hierarchical representations. The physical is only mentioned to give people some context for understanding what is being discussed.

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.

For the purpose of a single policy evaluation hierarchy that is used is uniquely defined by the provided "resource-ancestors" attribute.  

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.

The fact that there is some persistent identity that may participate in different hierarchies should be outside of the scope of this profile.

As indicated above and original email, the r* persistent identity is only used as contextual reference for humans to know what is being discussed. Within the policies themselves, there would generally be no need to include this attribute except possibly for reporting purposes.

    Thanks,
    Rich

Daniel;