MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Obligations in Rules roundup
Following-up to my mail from last night, I am providing here a summary
of the key points from the discussion between Polar and Michiharu. I
will also add my opinions [1] to the discussion. Again, please correct
me if I've missed something! We're getting close to the end, and I don't
want us to lose track of these issues..
The issue at hand is whether Obligations should be allowed in Rules the
way they are allowed in Policies and PolicySets. As the work item
states, this is simply to create shorter policies, since you can always
put each Rule in its own Policy and then put Obligations in each Policy.
Polar has raised two good questions: how does this affect determinism,
and how do we handle Obligations that can never be used (yes, I'll
explain).
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. 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.
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. 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.]
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).
[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.
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.
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]