|Subject:||Re: [xacml] Added Issue 41: "evaluate all policies"|
|From:||Erik Rissanen (mir...@sics.se)|
|Date:||Jul 24, 2006 1:33:24 am|
I have also been thinking about this issue, and I agree with Anne that the suggested approach doesn't seem right. Her explanation in the quoted email is good in my opinion. Also, if the use case is to help debug policies, which is a very important use case btw, then I think sending a request to the PDP is not interactive enough, even if it would force evaluation of everything.
What I think is needed is a tool that takes the policy and evaluates it while allowing some kind of interactive view of the evaluation. For instance, it should be possible for the user to expand nodes in the policies, maybe search them. Disabling, adding and editing could be used to see the effects to the evaluation. I have mentioned "partial evaluation" before, that is "what happens if the user is in group X" (and other attributes of the request are not specified).
To me it is very unclear currently how to do these things in a good way. I suppose we need some kind of primitive operations and algorithms that can be used to build tools for solving these use cases. Right now I have no clear view of what those primitives would be, but some ideas might be:
* Make the state of processing available to the tools. * The attributes of the entitites involved in the processing. * Reverse queries on attributes. * Partial evaluation, that is, collapse policies in those cases where attributes are known with certainty and leave other parts unevaluated.
Based on those primitives it would (hopefully :-)) be possible to build tools to assist administrators. However, because of the problems highlighted by Anne, I don't think the proposed evaluation procedure would be a useful primitive.
We also need specific use cases.
But I do think that this is an important aspect of access control systems and needs attention. We are doing some research on it here at SICS, but the research is still at early stages.
Also, I am not sure about, even if we would have good ideas, how much of them should be worked on within the XACML TC. What is the need to standardize in this area and what are just features in products? From the XACML standard point of view it would be possible to work on, for instance, a document which would describe primitives, methods, algorithms, best practices, ideas, experiences, etc for how to most efficiently examine and debug XACML policies. Such a document would certainly be useful for users and implementors of the standard, but what of it is within the scope of what the TC should be doing? Features in the evaluation model to support it? Features of APIs to invoke the PDP, such as the SAML profile? Suggested algorithms? Suggested ways to display XACML policies? Suggested methods to use the tools?
Note that I am not saying that all or none of this is within the scope. I don't know myself. But thinking about that perhaps makes it a bit more clear what we are looking for here.
I suppose the best way to proceed is for everyone interested to think about clear uses cases and solutions to the use cases and we can see how it would affect the standard and what is relevant for the TC.
Anne Anderson wrote:
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:
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.
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.
Hal Lockhart wrote:
I proposed this back on June 22, but it never made it to the issues list.
---- 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