Rich.Levinson wrote:
> I am trying to understand what policies are supposed to do with the
> definitions in the spec. i.e. it is the spec that says in section 3.2
> that all the parent and ancestor nodes need to be assembled in the
> request context. What "policy evaluation" are you referring to? Are
> you saying what I indicated in original email that a policy does not
> need to know anything about hierarchies that the resource-id node does
> not belong to?
Hi Rich,
I don't understand all the questions you have, but here's the basic
approach of the profile in a simple example.
Assume the following simple hierarchy:
A <- B <- C
If someone requests access to C, the request will contain these
attributes. this is from the top of my head, so it might be slightly
inaccurate and I might have forgotten some of the attributes, but
hopefully you get the idea.
<Resource>
resource-id = C
parent-id = B
self-or-ancestor = C
self-or-ancestor = B
self-or-ancestor = A
</Resource>
All these attributes are there so it is possible to write policies which
apply to parts of the hierarchy, not just individual nodes.
For example:
<Target>
resource-id = C
</Target>
Matches only the resource C, nothing else.
<Target>
parent-id = B
</Target>
matches the immediate children of B. In the example this is C, but if C
had a sibling, it would also match.
<Target>
ancestor-or-self = B
</Target>
Matches B or any node below B. In this case also C.
Best regards,
Erik
