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

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

Hi Erik,

Thanks for this feedback. Unfortunately I did not have time to process this email before today's meeting, but now that I have, it addresses one of my major concerns which was the motivational context. i.e. by seeing the actual example you provided, I can see that a Policy can now base decisions knowing that some node happens to be an ancestor of the requested node.

In addition, for your example, I think it would be instructive to show when a node belongs to two or more hierarchies, that the collection of attributes should probably have a mechanism to indicate which hierarchy a node belongs to. For example, if C had an alias C', and parent B' and ancestors A'->D' where, while (C = C'), that in general (B != B') and (A != A') and obviously D' has no relation to the unprimed nodes at all. We would then have a request:

<Resource>
 resource-id = C
 parent-id = B
 self-or-ancestor = C
 self-or-ancestor = B
 self-or-ancestor = A
 resource-id = C'
 parent-id = B'
 self-or-ancestor = C'
 self-or-ancestor = B'
 self-or-ancestor = A'
 self-or-ancestor = D'
</Resource>

It would seem to me that there needs to be a mechanism whereby one would be able to tell the primed from unprimed attributes. Possibly using Issuer

In any event, it is useful information to have this additional context for understanding the current spec.

As agreed at the meeting, I will try to find some cycles to say what I think needs to be done to make the spec easier to understand, which is possibly just including the above information (i.e. your email extended to multiple hierarchies with some example policy concepts, also such as you provided).

Also, I think, as I mentioned at the end of the meeting that "scope" may also have a meaningful role to include in this profile as well. i.e. one can easily see that if policies are defined whereby certain conditions apply when a resource-id node is within scope (as defined by multi-resource spec) of some other node, that some if that ""other node" happens to be a parent or ancestor of the resource-id node, then those "certain conditions" would apply to the current resource-id being requested.

    Thanks,
    Rich

Erik Rissanen wrote:

496F4DC8.4030200@axiomatics.com" type="cite">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