[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Added Issue 41: "evaluate all policies"
I can understand the motivations for this "Request for Enhancement", but I think it would be a mistake to try to add such an option. There are other, clean ways to achieve the desired goals. Here are my objections: 1) Fundamental What if a policy writer really, explicitly wants evaluation to terminate as soon as it is possible to determine the result, and writes a combining algorithm to that effect? Would this "must evaluate all children" option have to be supported for that combining algorithm too? A combining algorithm specifies how a decision is to be reached, including the order in which policies are evaluated (if that is important), and when evaluation may be terminated. A policy writer chooses a combining algorithm based on how the policy writer wants the policy to be evaluated. If you tell the PDP to do something different from what the combining algorithm itself says, then it is not using that combining algorithm and it is not doing what the policy writer intended. We defined new "ordered-*" versions of the standard combining algorithms for use where someone really wants to specify the order; we did not add a new option to existing combining algorithms. Likewise, if you want to have a consistent set of policies evaluated for every request, then define and enforce use in your system of new combining algorithms that explicitly require evaluation of all children. 2) Implementation Every single existing combining algorithm would have to be re-written to support this option, and the value for the option would have to be conveyed to each invocation of each combining algorithm. Every new combining algorithm would also have to be designed to support it. 3) "What if" case reporting the policies used to make the decision This doesn't answer any question other than "What if I said all applicable policies and rules must be evaluated?". If the "What if" Request Context were actually submitted to the PDP normally, a different set of policies might be executed based on the actual semantics of the combining algorithms and based on the implementation's use of implementation options explicitly allowed by that combining algorithm. If, for analysis purposes, you want to know all the policies that potentially apply to a given Request Context, then perhaps a new option for the SAML XACMLPolicyQuery could be designed that says, return not just the top-level policies that are applicable to the input RequestContext, but also prune their descendants to contain only the policies and rules that are applicable. This then becomes a new operation on the policy repository, not an operation performed by the PDP. 4) Consistent set of Obligations Again, if this is important, write a new combining algorithm that requires execution of every applicable descendant. The existing set of combining algorithms were written with specific semantics designed to allow performance optimization, and if a policy writer specifies them, that is what the policy writer intends. If, in a particular system, different semantics are desired, then define and use different combining algorithms in that system. Regards, Anne Hal Lockhart wrote: > I proposed this back on June 22, but it never made it to the issues > list. > > Hal > > ---- > In the course of thinking about Issue 13, it occurred to me that it > might be useful to define some sort of flag which would force the PDP to > forgo optimization and evaluate every applicable policy and rule, even > if it can determine the outcome by skipping some of them. > > This would have two primary purposes. To be used in conjunction with a > "what if" which reported the policies used to make the decision and > where a consistent set of Obligations is desired for a given set of > policies, independent of PDP implementation. > > The flag could appear in the Request Context or somewhere else. > > Anne and Seth commented that this would change the semantics of the > language, but I do not think this is true. With respect the Effect, the > result should be the same. Policies should only be skipped when the > result is certain without evaluating them. With respect to Obligations, > this might cause more Obligations to be returned, but they would always > be the set of Obligations returned by all possible evaluation strategies > and might in fact be returned by other PDPs using different optimization > strategies. The difficulty of implementation is a different matter. > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Anne H. Anderson Anne.Anderson@sun.com Sun Microsystems Labs 1-781-442-0928 Burlington, MA USA
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]