|Rich.Levinson||Jan 14, 2009 10:54 pm|
|Daniel Engovatov||Jan 14, 2009 11:23 pm|
|Rich.Levinson||Jan 15, 2009 6:42 am|
|Erik Rissanen||Jan 15, 2009 6:52 am|
|Rich.Levinson||Jan 15, 2009 8:36 am|
|Daniel Engovatov||Jan 15, 2009 11:09 am|
|Anil Saldhana||Jan 20, 2009 6:04 pm|
|Hal Lockhart||Jan 21, 2009 8:48 am|
|Rich.Levinson||Feb 16, 2009 4:22 pm|
|Daniel Engovatov||Feb 16, 2009 4:48 pm|
|Rich.Levinson||Feb 16, 2009 5:40 pm|
|Daniel Engovatov||Feb 16, 2009 5:59 pm|
|Rich.Levinson||Feb 16, 2009 8:05 pm|
|Daniel Engovatov||Feb 16, 2009 8:39 pm|
|Erik Rissanen||Feb 17, 2009 3:37 am|
|Rich.Levinson||Feb 17, 2009 7:40 am|
|Rich.Levinson||Feb 17, 2009 7:48 am|
|Daniel Engovatov||Feb 17, 2009 11:19 am|
|Rich.Levinson||Feb 17, 2009 8:33 pm|
|Daniel Engovatov||Feb 18, 2009 10:15 am|
|Seth Proctor||Feb 18, 2009 10:29 am|
|Daniel Engovatov||Feb 18, 2009 11:02 am|
|Rich.Levinson||Feb 18, 2009 12:37 pm|
|Daniel Engovatov||Feb 18, 2009 12:51 pm|
|Rich.Levinson||Feb 18, 2009 3:04 pm|
|Daniel Engovatov||Feb 18, 2009 3:16 pm|
|Rich.Levinson||Feb 18, 2009 6:54 pm|
|Erik Rissanen||Feb 19, 2009 6:57 am|
|Daniel Engovatov||Feb 19, 2009 10:59 am|
|Rich.Levinson||Feb 19, 2009 8:02 pm|
|Rich.Levinson||Feb 19, 2009 9:11 pm|
|Erik Rissanen||Feb 20, 2009 1:34 am|
|Erik Rissanen||Feb 20, 2009 1:41 am|
|Rich.Levinson||Feb 20, 2009 2:12 am|
|Erik Rissanen||Feb 20, 2009 2:30 am|
|Rich.Levinson||Feb 20, 2009 8:14 am|
|Rich.Levinson||Feb 20, 2009 8:55 am|
|Daniel Engovatov||Feb 20, 2009 10:37 am|
|Daniel Engovatov||Feb 20, 2009 10:37 am|
|Rich.Levinson||Feb 20, 2009 10:46 am|
|Daniel Engovatov||Feb 20, 2009 11:01 am|
|Rich.Levinson||Feb 20, 2009 1:22 pm|
|Daniel Engovatov||Feb 20, 2009 3:03 pm|
|Subject:||Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent|
|Date:||Jan 15, 2009 8:36:47 am|
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.
Erik Rissanen 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?
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.
<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