Re: [xacml] Obligations in Rules roundup

[Polar Humenn <polar@syr.edu>]

On Tue, 13 Apr 2004, Seth Proctor wrote:

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

Not good enough.

If we don't mandate that you don't always get the same result we loose
that much integrity of the specification.

Would you sell a product that had that "feature", of "Well, I don't know,
run it a few times, see what you get".

If I have to certify this standard for a National Lab, or write an
evaluation of it under the Common Criteria, this would be key negative
point.

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

There had better be some well-defined semantics about how it works,
otherwise we created just another name and some garbage.

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

That's my point. I'm saying that the specification should require it.

> It's unrealistic to require evaluation of all sub-trees. This is the
> whole reason that we're supporting ordered combining algorithms.

It's not unrealistic.

In the "unordered" version that deals with obligations that evaluation
strategy may be undesirable, and that's why we are supporting the 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.

Problems with the spec, is what I am trying to ELIMINATE! Not preserve,
not perpetuate, and not to make more problems based on ones that already
exist.

"extra" syntax is not an issue.

It is *much* better to have specific syntactic structures that force the
clarity of the semantics, instead of overloading the meaning of an
existing structure, and end up leaving half of it meaningless, or just
wrong.

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

No, you chose the obligations that are to be returned based on the result
of the combination of the rules, not the individual rule itself.

> If the Condition is false then the Rule doesn't apply, and because the
> Rule returns NotApplicable no Obligations are returned.

True, But if the rule has an Effect of Permit, but the obligation has
FulfillOn=Deny, and the result of the combining algorithm is Deny, then
that obligation is 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.

I have. again, it is the result of the combination that picks from the
obligations at the policy level and the ones conditionalized by the rules'
conditions.

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

???? The effect on the clarity, or should I say the definitive semantics,
is my point.

Can you give me a good English sentence stating what a rule like that
says?

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

I think we are just in violent disagreement for this.

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

Okay, lets not talk about the "implementation". It affects the model.
Because now the rule combining algorithm DESCRIPTION must define what it
does with the obligations in the rules. Whereas, without obligations in the
rules, it didn't.

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

Again, that's not how it works.  I leave that to a disagreement.

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

Ehhh, hmmmmm,

I DID NOT SAY "PROVIDED THAT"! It says:

IF access-time is after midnight

  AND

    IF access *IS* ALLOWED

    THEN

    Call the security desk.


It DOES ***NOT*** SAY

Access is allowed ONLY IF You call the security desk.

Ehhh, hmmmm.

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

Please give me an example of which it 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.

I think I sent you (and the list) an excerpt from it. However, Michiharu
did post to the list. It's unfortunate, that the
subject of the thread is a bit off.

Re: [xacml] oasis-xacml-2_0-core-spec-wd-08.zip

Ah, I think I found it:

http://www.oasis-open.org/archives/xacml/200404/msg00073.html

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

Ah, okay.

Gad, I love these heated arguments.!  :)

Cheers,
-Polar

>
>
> seth
>