Re: [xacml] Obligations in Rules roundup

[Polar Humenn <polar@syr.edu>]

On Tue, 13 Apr 2004, Seth Proctor wrote:

> The first issue, determinism, comes from the fact that using unordered
> combining algorithms may lead to different results from the same
> requests on the same policies. This is decidedly a problem. It's no
> different, however, than any other aspect of the system. Using a
> non-deterministic algorithm can already lead to unexpected results from
> Obligations, Rule/Policy evaluation, etc.

The "unordered" combining algorithms *are* deterministic algorithms!
For Deny overrides, if there a single deny anywhere, its a deny. For
permit-overrides, if there is a single permit anywhere, its a permit.

There is nothing non-deterministic about them. I do not want them
classified as non-deterministic.

> If you want determinism, you need to use ordered, deterministic
> combining algorithms. This solves the problem for Obligations in Rules.
> I think we all agree on this point.

No, I think if you want a strategy that limits or allows you to prune the
obligations that you pick up, then an "ordered" version is probably more
of what you want. Say, if you have a permit overrides strategy, and you
don't want any obligations after the first policy that returns permit, use
the ordered-permit-overrides combining algorithm. (I'm only assuming
that's the way it works).

The "unordered" versions just must evaluate every policy for obligations
in order to get a common answer in all implementations.

> The second issue is that this kind of statement:
>
>   <Rule Effect="Permit" ...
>     ...
>     <Obligations>
>       <Obligation FulfillOn="Deny" ...
>
> specifies an Obligation that can never be returned. Is this a problem?
> Perhaps, although as Michiharu has pointed out, you can already
> construct statements like this at several levels, so we're not adding a
> new ambiguity, just another place to include it. :)
>
> [My personal take is that this isn't a problem, though it is ugly.

Ugly is a problem for me. It means lack of elegance, which translates into
suspicion.

> If you want to write a policy like this, fine. It doesn't actually
> affect anything, except the clarity when you're reading through. An
> intelligent authoring tool or PDP can always remove this statement
> without changing the meaning of the policy.]

Not so. Michiharu stated that the obligation applies if the rules
condition is true.

> A related question raised by Polar is when the Obligations in a Rule
> should actually be returned. I think, and the concensus seems to be,
> that it should work just as Obligations work elsewhere. The Rule is
> evaluated, and if it returns Permit, then all its Obligations with
> FulfillOn=Permit are supplied to the combining algorithm. If the Rule
> returns Deny, then the Deny Obligations are returned. This is very easy
> to handle, requires (essentially) no extra overhead in evaluation, and
> keeps the meaning and interpretation of Obligations consistent
> throughout the specification (ie, this is how it works with Policy and
> PolicySet).

Again. in contrary, Michiharu said that regardless of the Rule's Effect,
it is the rule's Condition that governs (i.e. True) whether the obligation
is picked up.

> [I think that it might be useful to add a paragraph of text explaining
> this behvior for Rules.]
>
> In a recent email, Polar suggested a ConditionalizedObligations
> construct. I think the goal here was to tie applicable Obligations to
> the Condition's result, and not the Rule's result. Respectfully, I have
> to say that this only adds confusion, and I suggest we do not do this.
> For one thing, deciding which Obligations to use based on the Rule's
> result is consistant with the current semantics for Obligations. Also, I
> think we've introduced enough complexity around the Condition, and we
> don't need to confuse things further. Finally, I believe it's a bad idea
> to de-couple Obligations and Effects, which is basically what this
> proposal does...a Condition of true does not equal an Effect of Permit.
> Obligations talk about Permit and Deny, not True and False.

You say above, "It doesn't actually affect anything, except the clarity
when you're reading through." So, first of all, how can you state that
conditions on obligations is confusing, when you think that obligations on
rules is confusing?

I think from what Michiharu clarified in my questions to him, that indeed,
it is the condition that what he considers important for the obligation.

I'm willing to concede that point, but not in rules.

The other thing that you state, that it doesn't "affect anything", which I
can say is explicitly false. Previously, rule-combining algorithms did not
take into effect any obligations. For this, they would have to. That's an
effect.

> Where does this leave us? I think there is some support for Rules in
> Obligations, though it's still not clear to me that this is a needed
> feature. If we include it, we should take the simple approach and let
> Obligations be included in Rule they way it is in Policy and PolicySet.
> Likewise, Obligations are returned to the combining algorithm the same
> way they are with Policy and PolicySet: by matching the Effect returned
> by the Rule.

I still don't see what the rule says to me when an obligation is listed
with it, perhaps the "lack of clarity" which you so amiably state is a
factor?

Furthermore, conditionalizing an obligation makes sense to me.
 "If access-time is after midnight and access is allowed, call the
security desk".

I think you still are (and I was) under the impression that the obligation
is only picked up if the FulFillOn matched the effect of the rule.

However, after clarification from Michiharu, this is not the case. After
understanding that the <condition> is the only thing that governs whether
the obligation is picked up, regardless of the Effect of the rule may
change your story.

I also, don't think it complicates <Condition>. However, we certainly can
use some other name if its a real problem.

Cheers,
-Polar

> Speaking as someone who has implemented Obligations for XACML, I think
> this is pretty easy to support, and makes sense. The only open question
> is what to do about Obligations that can never be returned. I would like
> the ability to remove them when I parse a policy, but I think that's
> really an implementation detail.
>
> Comments?
>
>
> seth
>
>
> [1] Personally, I think that this issue should have been closed when we
> decided to exclude Rule referencing, since the same arguments apply
> here. I don't think that Obligations in Rules lead to the same
> dangerious cases as Rule referencing, however, so ultimately I'm pretty
> easy on this issue.
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>