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;
