Re: [xacml] Multiple obligations

[Erik Rissanen <erik@axiomatics.com>]

On 2011-06-10 09:27, remon.sinnema@emc.com wrote:
> Erik/TC,
>
>
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Tuesday, June 07, 2011 3:59 PM
>> To: xacml@lists.oasis-open.org
>> Subject: Re: [xacml] Multiple obligations
>>
>> All,
>>
>> I don't think combining decisions and combining obligations are
>> orthogonal.
>>
>> Consider the case of the following (agreed, contrived) policy
>> structure:
>>
>> PS1 ordered-permit-overrides
>>     Target:
>>       printing-enabled-for-user = true
>>       resource-id = printing
>>     P2 ordered-deny-overrides
>>       R3 permit printing with obligation "invoice-printing-cost"
>>       R4 deny printing if authentication-level = basic
>>     P5 ordered-deny-overrides
>>       R6 permit printing if staff-member = true with obligation
>> "log-printing"
>>
>> Assume following request:
>>
>> Subject:
>>     subject-id = alice
>>     staff-member = true
>>     authentication-level = basic
>>     printing-enabled-for-user = true
>> Resource:
>>     resource-id = printing
>>
>> R3 and R4 and R6 will all apply. R3 because the basic rule is that
>> anybody with printing enabled on their account can print (given that
>> they are invoiced). Except that R4 denies a user who is using only
>> basic
>> authentication. And R6 allows staff members to print regardless of
>> level
>> of authentication (and for free, but we want to log the access).
>>
>> Clearly we would like to correlate obligation combining with the
>> combining of the decision, so that we don't invoice the staff member,
>> although one of the leaf rules matched. However the decision from that
>> R3 was later overridden by another rule R4, so the _reason_ why the
>> access was permitted was different than the conditions in R3, so we
>> should not apply the obligations from R3, since they are relevant only
>> to the situation which R3 was about.
> This makes perfect sense to me.
>
> I would phrase it as follows. Combining algorithms aren't actually *combining* decisions, as there is no way to simultaneously Permit and Deny a request. One can only chose between them. So the combining algorithms are actually really doing *conflict resolution*. From that perspective, their job is to select one Rule from the potentially multiple Rules that are applicable to the request. And then it would make sense to return the Obligations associated with that one selected Rule only.
>
> I'm wondering, therefore, why the spec mentions "evaluating" rules as a criterion for returning obligations? What was the rationale behind that wording?
>
>
> Thanks,
> Ray
>

Remon,

I think the rationale has been to avoid having to explicitly talk about 
obligations in each combining algorithm description. I don't like the 
way it is now. A better way to define it would be that each combining 
algorithm specification explicitly specifies which obligations are returned.

As you say, probably the most meaningful way in most cases would be that 
we should view it such that there is ultimately a single leaf rule which 
"caused" the decision and obligations would come only from the path to 
this rule. In section 7.16 it says "If the PDP's evaluation is viewed as 
a tree of rules, policy sets and policies, each of which returns 
'Permit' or 'Deny', then the set of obligations and advice returned by 
the PDP to the PEP will include only the obligations and advice 
associated with those paths where the effect at each level of evaluation 
is the same as the effect being returned by the PDP." This was perhaps 
intended to mean it.

Things get more complicated if the combining algorithms do more than 
simple conflict resolution between policies, like for instance majority 
voting for the decision, in which case there would be more than one rule 
which "caused" the decision.

All these cases would be easily defined on a case by case basis for each 
algorithm if the collection of obligations is specified in the combining 
algorithms rather than it's own section in the specification. For each 
algorithm we can include those obligations which make sense from a use 
case perspective, which would be to be collect those obligations to 
which belong to rules and policies which impacted the decision, not 
those which were later overridden.

The case where there are more than one rule which actually could have 
caused the decision is more open in terms of what makes sense. that's 
what the obligation families working draft tries to address in part at 
least.

Best regards,
Erik