Re: [xacml] The new advice "obligation"

[Erik Rissanen <erik@axiomatics.com>]

bill parducci wrote:
>
> On Dec 20, 2008, at 12:49 AM, Erik Rissanen wrote:
>> And yes, if you mix policies across domains, you would get <Advice>
>> across domains. So in that case it wouldn't make sense to use them.
>
> 100% in agreement here.
>
>> But this is really not any different from the case where you use
>> AppliesTo="Deny" with refactored policies, since in that case you end up
>> with Denys across domains, so you get interference in policy combining
>> as well, which is even worse.
>
>
> OK, this is where I am looking for clarity. Perhaps I do not
> understand your "refactoring" process. If Advice is limited to
> Permit|Deny and I have a mixed domain PDP those Policies that are not
> part of the decision (aka "not applicable") would not be evaluated.
> (It makes no sense to evaluate the Rules of a Policy where the
> Resource is not applicable to the question being asked, right?).
> Therefore, by definition the PDP would not return an Advice (or
> Obligation :) contained within these Policies because they should
> never lead to a Permit or Deny decision (the only thing that can be
> said of them is that they are not applicable to the decision). This of
> course assumes that individual Polices do not cross domain boundaries
> but I think that is a safe assumption for a number of reasons.
>
> Conversely, if you extend Advices to Not Applicable then you compel
> the system to return ALL Advices(=NotApplicable) to the PEP that are
> in all other domains since, by definition, any such Policy/Rule meets
> the condition of being not applicable. I do not see any way to avoid
> or control this and in the situation of a distributed system to be
> able reasonably bound the problem.
>
> For example, take the case of a Grid, would all peers need to be
> queried to derive the exhaustive list of those things that are not
> applicable to a decision? I know that this is an extreme case, but my
> point is that the concept of "do something about those things that
> don't apply to the situation" seems like it can lead to many
> unintended consequences.

They are doing policies similar to this (in pseudo-XACML):

<Rule Effect="Permit">
  <Target>
    a doctor
    a medical resorce
  </Target>

  <Condition>
       check that the doctor has consent from the patient
  </Condition>
</Rule>

If a doctor tried to access a medical resource and is denied because of
lack of patient consent, they would like to tell the doctor that he
needs to ask for the consent. So they are looking to put an obligation
in there. In XACML 2.0, the first thing they need to do is to refactor
the rule into a policy to put in the obligation:

<Policy RuleCombining="whatever ...">
  <Target>
    a doctor
    a medical resorce
  </Target>

  <Rule Effect="Permit">
    <Condition>
         check that the doctor has consent from the patient
    </Condition>
  </Rule>
  <Obligation ObligationId="NotifyLackOfConsent" FullfilOn="???"/>
</Policy>

But note how the obligation should be returned when the rule/policy does
not match because of lack of consent. This is why they would like to
have an obligation for a NotApplicable, which is not possible.

So they now need to further refactor it to return a Deny.

<Policy RuleCombining="ordered-permit-overrides">
  <Target>
    a doctor
    a medical resorce
  </Target>

  <Rule Effect="Permit">
    <Condition>
         check that the doctor has consent from the patient
    </Condition>
  </Rule>
  <Rule Effect="Deny"/>
  <Obligation ObligationId="NotifyLackOfConsent" FullfilOn="Deny"/>
</Policy>

Now they get a deny with the obligation when the condition does not
match. However, it means that this policy now sometimes returns a deny
instead of NotApplicable, so the logic of the policy set in which it is
contained has also to be refactored.

Instead, if <Advice> is allowed at the rule level and for a
NotApplicable, they could do this:

<Policy RuleCombining="whatever ...">
  <Target>
    a doctor
    a medical resorce
  </Target>

  <Rule Effect="Permit">
    <Condition>
         check that the doctor has consent from the patient
    </Condition>
    <Advice AdviceId="LackOfConsent" AppliesTo="NotApplicable"/>
  </Rule>
</Policy>

There is no reason to refactor the decision into a deny and the logic of
the policy set containing this policy is unaffected. The advice will be
returned in those cases where the target of the policy matches, that is,
it is a doctor accessing a medical resource, but he does not have consent.

The advice will not be returned if it's a chemist trying to access a
protein folding simulator.

And the advice will be returned only when the final decision was
NotApplicable, which means that there is no other policy which applies.

Best regards,
Erik