Re: [xacml] Obligations in Rules roundup

[Seth Proctor <Seth.Proctor@Sun.COM>]

On Tue, 2004-04-13 at 12:57, Polar Humenn wrote:
> 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.

Deny overrides will always return Deny for any value of Deny found.
However, depending on the ordering, it may be a different Policy/Rule
that returns Deny, and that Policy/Rule could contain Obligations. So,
yes, you always get the same decision from deny-overrides, but you
aren't guarenteed that you always get the same Result.

> > 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).

That's not the way it works, but I think that's orthagonal to this
discussion. Ordered and non-ordered alike let you short-circuit
evaluation.

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

Nothing in the specification requires this, which is why you don't get
this determinism. It's unrealistic to require evaluation of all
sub-trees. This is the whole reason that we're supporting ordered
combining algorithms.

> > 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.

Fine. The solution to this "ugliness" is to require extra syntax. That's
ugly to me. Ugly is subjective. I would far rather see this case, which
as I said is already a problem elsewhere in the spec, over more tags. If
you don't want to use this wierdness, then don't, and have your PDP or
tools optimize it out.

> > 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.

I think you should read his responses again. He makes it clear that the
Condition must be true for the Obligations to be used. That's true. But
that's consistant with the use of Obligations elsewhere. You still
choose which Obligations are retrurned based on the Rule's Effect. If
the Condition is false then the Rule doesn't apply, and because the Rule
returns NotApplicable no Obligations are returned.

> > 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.

Again, re-read his comments. The Rule must apply for any Obligations to
be returned, and so by definition the Condition must return True (or be
absent). It is still the Effect of the Rule that decides which
Obligations are returned.

Michiharu - If I am reading your comments incorrectly, please let me
know! From what you've written, however, and based on how Obligations
already act, this is the only way I can intrpret your suggestions.

> > [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?

Read my email more carefully. I said that clarity is effected only when
you have an Obligation with a different Effect than what the Rule
provides. In general I see nothing confusing about Obligations in Rules.

> 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.

The Condition is an integral part, but it should not determine which
Obligations are ultimately returned.

> 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.

I said it doesn't affect anything in terms of how a policy is evaluated.
That is true. Of course it affects an implementation, since it's a new
feature and therefore by definition requires new code. It does not and
will not change the Decisions being returned by combining algorithms.

> > 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?

I have no idea what this means. Are you saying you don't understand how
Obligations work? If the Rule returns Permit, and it is evaluated in the
course of policy evaluation, then all Obligations within the Rule that
have a FulfillOn of Permit are returned in the Result. I think that's
pretty simple.

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

This is exactly what you've been crusading against: making the
Obligations returned to a PEP a "provided that" construct. How can you
now support this? Morover, there is already condition logic in a Rule.
Why add more?

> 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.

I am indeed. And from re-reading Michiharu's emails, that's what I see.
I also strongly believe that's the only way this makes sense.

> 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.

Did this clarification come in the form of personal email to you? If so,
can you share with the rest of the list? I'm going on what I've seen
posted to the list, and from that I believe I'm reading the correct
behavior.

If the Effect of the Rule is ignored in choosing which Obligations are
returned, then I have to object strongly to the use of Obligations in
Rules under any condition.


seth