[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Re: Combining algorithm combining orders
You are right, errors should not be propagated if it can be avoided, but we are discussing two particular cases where propagation of the error cannot (or should not) be avoided since a clear decision _cannot_ be made. Currently the combining algorithms make an arbitrary choice to deny access in case of an error, which is not correct if analyze how the error could affect the final outcome. There are other cases where the combining algorithms correctly discard errors since they can tell from the other policies that the error shouldn't affect the outcome. There is no issue with giving an attacker information, since we are propagating the error to the PEP, which controls the resource anyway. Regards,l Erik Daniel Engovatov wrote: > > On Fri, 26 Sep 2008 , at 11:52 PM, Erik Rissanen wrote: > >> Notice how the result depends on what the indeterminate could >> potentially be. However the current definition gives a definite Deny in >> all cases. This breaks the error propagation safety of the combining >> algorithm. > > Error propagation safety??? Error should not be propagated if that > can be avoided. The whole point of Indeterminate value is that it > can be explicitly handled by a combining algorithm, and error > propagation avoided whenever possible. Just throwing an exception > all the way to the client is what we have tried to avoid. > > In all the examples result would be Deny if no error had occurred. > There is no reason to propagate errors (and to give a would be > attacker any hints that some sort of disruption actually worked) when > there is a clear decision. It is somewhat different on the rule > combining level, as it does not return the result to the PEP, so it is > ultimately handled on the policy combining level. > > I think we have designed it this way on purpose. I do not think it > is a mistake. > > Daniel; > > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]