OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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-id = C
  parent-id = B
  self-or-ancestor = C
  self-or-ancestor = B
  self-or-ancestor = A

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:

  resource-id = C

Matches only the resource C, nothing else.

  parent-id = B

matches the immediate children of B. In the example this is C, but if C 
had a sibling, it would also match.

  ancestor-or-self = B

Matches B or any node below B. In this case also C.

Best regards,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]