Re: [xacml] Added Issue 41: "evaluate all policies"

[Erik Rissanen <mirty@sics.se>]

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.

Regards,
Erik

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:
>
> 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
>>
>