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