Re: [xacml] New combining algorithms profile and a potential issue in 3.0 core spec

[Bill Parducci <bill@parducci.net>]

Fundamentally, I am not a fan of introducing ordered evaluation--particularly on PolicySets--because it makes a key element of evaluation less obvious: the order by which PoliciesSets are passed to the combiner is germane to the decision. This is somewhat palatable in FirstApplicable because it applies to Policies in a Policy Set so the order is fairly obvious, however my understanding of this proposal that PolicySets may be ignored based upon this decision. In the past there has been little if any differentiation between Policy/PolicySets, but I think that in the case it becomes relevant. 

What this proposal implies is that there is a level of precedence that is only obvious in the context of the implementation. If PolicySets A, B & C have overlapping exclusions then the order of which PolicySet is presented to the combiner matters. How is this manifested to an Author?

b


On Jun 19, 2013, at 1:14 AM, Erik Rissanen <erik@axiomatics.com> wrote:

> All,
> 
> I have uploaded a new working draft of the combining algorithms profile.
> 
> I have generalized the on-permit-apply-second algorithm so it can take
> a third child which is applied in case the first child ("the condition")
> returns N/A or Deny. This is the if-then-else feature which we discussed
> earlier on the list.
> 
> I also made some other changes to the algorithm. It used to be "clever" in
> case of different flavors of Indeterminate. But I realized that doing so
> is dangerous and undesirable for this algorithm, so I simplified
> the error handling. Let me explain why.
> 
> The purpose of this algorithm is to allow using conditions in policies.
> For instance, someone could write a policy like this:
> 
> PolicySet Y [on-permit-apply-second]
>  Policy A, Rule, Condition: the subject has an account in corporate LDAP
>  PolicySet X
>    ... policies which apply to these subjects ...
> 
> Now, when the PolicySet X is authored, it is likely to be done with the
> assumption that the user has an ldap account, since this is what is
> tested for in the condition. The author would assume that the policy set X
> is not evaluated if the condition is false.
> 
> However, in WD 03 of the profile, if Policy A (with the condition) returns
> an Indeterminate{P} or Indeterminate{DP}, the policy set X is evaluated
> anyway to determine the flawor of Indeterminate which should be
> returned as a whole for policy set Y.
> 
> But since the policy A was indeterminate, we don't really know whether
> the condition is true or not, so we might in fact be in a situation
> where we violate the assumptions which were made when X was authored. That is,
> in this case, the user might not have an account in ldap.
> 
> That in turn means that policy set X may malfunction and behave incorrectly.
> That could in WD 03 lead to an incorrect N/A or the wrong flavor of
> Indeterminate from the on-permit-apply-second combining algorithm.
> 
> The potential generalization of the algorithm to three children would mean
> that to discover the flavor of Indeterminate, one would evaluate both
> children and then use a flavor depending on the result. Also, when the two
> children agree on the decision, then one could even make a defined decision
> even if the first child (the condition) is Indeterminate. I made a table
> which I have attached to the end of this email which lists all the cases.
> 
> However, if we consider that if it is not known whether the condition holds,
> then we cannot really trust the result of either of the children, so
> the values on the left in the table could be seen basically as random,
> meaning that an algorithm which tries to be smart can potentially return
> _any_ decision randomly.
> 
> Do note that already the WD 03 version of the algorithm is dangerous since
> the wrong flavor of Indeterminate could influence a nesting combining algorithm
> to do the wrong thing.
> 
> So therefore I did not use smart Indeterminate handling in the combining
> algorithm when I generalized and I have removed the smartness from
> the case where there are only two children as well. This applies to the
> case when the first child is Indeterminate{P} or Indeterminate{DP}.
> The case of Indeterminate{D} should be safe since that implies that there
> is no way the second child should be evaluated, regardless of the error. So
> I kept that case as it was.
> 
> One more thing: when I thought about this algorithm, I realized that we have
> a similar issue with plain 3.0 targets. In sections 7.12 through 7.14 the spec
> tells to evaluate the children and combine them in case the target is
> Indeterminate. This is to determine the flavor of Indeterminate, but if
> target is failing, we don't really know whether the children behave
> as intended either.
> 
> I think we should do an errata on the core spec because of this and let the
> Policy/PolicySet always be Indeterminate{DP} in case of a target which is
> Indeterminate.
> 
> Best regards,
> Erik
> 
> Here is the table for choosing a decision among two policies if
> it is not known which of the two should be used:
> 
> Permit Permit -> Permit
> Permit Deny -> Indeterminate{DP}
> Permit Indeterminate{P} -> Indeterminate{P}
> Permit Indeterminate{D} -> Indeterminate{DP}
> Permit Indeterminate{DP} -> Indeterminate{DP}
> Permit NotApplicable -> Indeterminate{P}
> Deny Permit -> Indeterminate{DP}
> Deny Deny -> Deny
> Deny Indeterminate{P} -> Indeterminate{DP}
> Deny Indeterminate{D} -> Indeterminate{D}
> Deny Indeterminate{DP} -> Indeterminate{DP}
> Deny NotApplicable -> Indeterminate{D}
> Indeterminate{P} Permit -> Indeterminate{P}
> Indeterminate{P} Deny -> Indeterminate{DP}
> Indeterminate{P} Indeterminate{P} -> Indeterminate{P}
> Indeterminate{P} Indeterminate{D} -> Indeterminate{DP}
> Indeterminate{P} Indeterminate{DP} -> Indeterminate{DP}
> Indeterminate{P} NotApplicable -> Indeterminate{P}
> Indeterminate{D} Permit -> Indeterminate{DP}
> Indeterminate{D} Deny -> Indeterminate{D}
> Indeterminate{D} Indeterminate{P} -> Indeterminate{DP}
> Indeterminate{D} Indeterminate{D} -> Indeterminate{D}
> Indeterminate{D} Indeterminate{DP} -> Indeterminate{DP}
> Indeterminate{D} NotApplicable -> Indeterminate{D}
> Indeterminate{DP} Permit -> Indeterminate{DP}
> Indeterminate{DP} Deny -> Indeterminate{DP}
> Indeterminate{DP} Indeterminate{P} -> Indeterminate{DP}
> Indeterminate{DP} Indeterminate{D} -> Indeterminate{DP}
> Indeterminate{DP} Indeterminate{DP} -> Indeterminate{DP}
> Indeterminate{DP} NotApplicable -> Indeterminate{DP}
> NotApplicable Permit -> Indeterminate{P}
> NotApplicable Deny -> Indeterminate{D}
> NotApplicable Indeterminate{P} -> Indeterminate{P}
> NotApplicable Indeterminate{D} -> Indeterminate{D}
> NotApplicable Indeterminate{DP} -> Indeterminate{DP}
> NotApplicable NotApplicable -> NotApplicable
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php