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

[Erik Rissanen <erik@axiomatics.com>]

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