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] Combining Algorithms & the Hierarchical Resource profile


Hi Ray,

I think what you are describing is the difference between default = deny (everything denied unless permitted) vs default = permit (everything permitted unless denied).

This can usually be accomplished by having permit-overrides combining alg with a final rule of deny (default=deny) vs having a deny-overrides combining alg with a final rule of permit (default=permit).

This appears to me to be an orthogonal property wrt hierarchical traversal.

     Thanks,
     Rich


On 9/6/2011 1:22 AM, remon.sinnema@emc.com wrote:
> Rich,
>
>
>> -----Original Message-----
>> From: rich levinson [mailto:rich.levinson@oracle.com]
>> Sent: Monday, September 05, 2011 11:30 PM
>> To: xacml@lists.oasis-open.org
>> Subject: Re: [xacml] Combining Algorithms&  the Hierarchical Resource
>> profile
>>
>> Hi Ray,
>>
>> I think your question may be a bit outside the scope of the
>> hierarchical profile for the following reason.
>>
>> You have defined 2 independent rules, Rule-A and Rule-D that identify
>> separate resources.
>>
>> Since when one traverses the hierarchy, one first encounters node A, it
>> would seem that should take precedence before continuing the path to
>> node D. i.e. if rejected at node A, you are done, if accepted then you
>> get to try node D.
> If my example resources are file system directories, and the action is write, then I hope this is not the case. No OS should allow me to write in the root, but I certainly should be able to write in my home directory.
>
>
>> A lot depends on how you construct the Policy. If you used ordered
>> rule-combining then you could place either rule first to achieve
>> whichever effect you preferred.
> I guess. I'm not a big fan of rule ordering, though. It just seems fragile.
>
>
>> The hierarchical profile is primarily about how to represent the nodes
>> in a hierarchy and addresses a variety of common use cases. It builds
>> on top of the Multiple profile and the core spec, so it is expected
>> that one would use the node representations in that context.
>>
>> If there is another specific context that you have in mind, I would be
>> interested to learn more about it. The use case you have described does
>> not seem to me to have any particular motivation except trying to
>> define some precedence order for applying the Rules which I do not
>> quite understand.
> I think that in many cases the precedence order follows quite naturally from the hierarchy, either top overrides as in your example, or bottom overrides as in mine. That's why I expected the Hierarchical Resource profile to define some CAs that implement such precedence.
>
>
> Thanks,
> Ray
>


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