Re: [xacml] Combining algorithms

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Daniel,

My objective here has not been to redesign algorithms, but to simply provide an option for those situations where it might be preferable to have what to some people is possibly a more intuitive container structure. i.e. a uniform container structure, where PolicySets and Policies have the same kinds of combining algorithms which operate on the logical properties of the contained entities. In particular, those logical properties that are used in the combining algorithms is "half-boolean" Rule property and potential "half-boolean" Policy and PolicySet property which occurs when all applicable Rules contained within a Policy have the same half-boolean "Effect".

In addition, this analysis has revealed the "biased" character that may or may not appear within a combining-algorithm, which, if not explicitly recognized and addressed, can result in additional non-intuitive behavior. By having consistent bias a set of combining algorithms is potentially much easier to understand.

As a result, the proposal Erik has provided explicitly isolates these properties within three groups of algorithms, so that the properties can be evaluated independently rather than to be partially included or not included, which leads to types of questions that motivated the analysis in the first place.

The intention is to leave existing things as undisturbed as possible, while at the same time opening the possibility of including these additional existent, but not explicitly represented, properties: "bias", and "implicit Policy Effect", either explicitly within the algorithms or implicitly by Policy and Rule design, or not at all.

Personally, I have not explicitly addressed the issue of a "normative interoperable way to extend them", however, my sense tells me that by isolating and quantifying these properties, that appear to result from the "half-boolean" nature of the Rules themselves, puts us in a stronger position to address larger problem of "normative, interoperable" by identifying the properties that will need to be carried by such a representation.

    Thanks,
    Rich


Daniel Engovatov wrote:

1309154434-1226450910-cardhu_decombobulator_blackberry.rim.net-785709555-@bxe148.bisx.prod.on.blackberry" type="cite">

I still think that there is no compelling reason to redesign existing algorithms and that we should rather design a normative way to extend them in an interoperable way. 

Daniel. 

-----Original Message-----
From: "Rich.Levinson" <rich.levinson@oracle.com>

Date: Tue, 11 Nov 2008 19:27:54 
To: Erik Rissanen<erik@axiomatics.com>
Cc: <xacml@lists.oasis-open.org>
Subject: Re: [xacml] Combining algorithms


Hi Erik,

Nice job putting together the combining algorithm sections. I agree with 
most everything you supplied although I have not yet looked at all the 
explicit details of each algorithm, but for the sake of discussion will 
assume that they are correct and just focus on the details of the 
extended algorithms.

First, the things I agree on are:

    * Agree that we don't need to define biased algorithms. Might want
      to comment on that and indicate that recommendation is to build
      any bias directly into the policies, if needed.
    * Might also want to mention that PEP bias is possible, but that it
      can be removed by defining appropriate policies, especially at top
      level. For example, if you want a Deny for all cases of errors and
      indeterminate, a top level PolicySet w permit-overrides can
      contain one policyset for all other policies which collectively
      can return Permit, Deny, Indeterminate, NotApplicable, plus a
      second policyset that has an automatic Deny Rule if the first
      PolicySet did not return a Permit.
    * Agree on change deny-overrides policy combining to unbiased as you
      have included.
    * Agree on change permit-overrides policy combining to unbiased, as
      well, also, it is symmetric w deny-overrides.

On the extended algorithms, I think we have a disagreement as to the 
potential value, and therefore I will try to point out the value that I 
see there as the basis of why I think they should be included.

I'd like to initially point out that what we are dealing with here is a 
pre-existing condition in the current set of combining algorithms that 
neither Erik nor I were a party to creating in the first place. Erik's 
proposal is to "fix" some aspects of the existing algorithms, and I 
agree that those fixes are improvements to the current state. My 
proposal has been to revisit whether, in fact, that separate policy and 
rule combining algorithms actually add value or subtract value, when 
compared to a single combining algorithm that applies to both 
policy(set)s and rules.

First, I agree that the extended algorithms Erik has written appear to 
be functionally equivalent to what I was recommending in the earlier 
discussion on this topic:
http://lists.oasis-open.org/archives/xacml/200810/msg00053.html
(Note: I recommend changing the Indeterminate(DP) defn to be: "an 
Indeterminate from a policy which could have evaluated to a Deny or 
Permit." i.e. remove the "or rule" because a rule can either be a "D" or 
a "P" but not both. This has no algorithmic impact but might be 
conceptually useful when examining the algorithms, i.e. to know DP 
applies to policies only. (In fact this brings out a key concept, namely 
that policies, while inherently can be DP, depending on the contained 
rules and their evaluations, can effectively be constrained to only "D" 
or "P", which carries the character of the collection of applicable 
rules that it contains.)

In particular, the 3 flavors of Indeterminate preserve the results as to 
whether there was a possible override or not, which is lost in the 
current "base" permit/deny-overrides algorithms that simply return 
Indeterminate in the case where there is a potentialDeny or 
potentialPermit flagged and do not distinguish the cases where those 
potentials are not present.

In other words, it is obvious by inspection of the base 
permit/deny-overrides algorithms, that Indeterminate in both algorithms 
can be returned in 2 distinct cases, which causes you to lose track of 
whether there was a potential deny in the deny-overrides case or a 
potential permit in the permit-overrides case.

In fact, one could take the point of view that we are effectively 
introducing the complexity of having two classes of combining algorithm 
(policy and rule) in order to remove information that we are 
presupposing will be of no value to any customer. i.e. the reason that 
the policy-combining algorithms are simpler than the rule-combining is 
that potentially useful decision making information is removed by the 
rule combining algorithms after using only a portion of the information 
that they have gone to the trouble to collect.

The net result is that there is a non-uniformity of containers for Rules 
that adds conceptual complexity to the strategy of building PolicySets 
with no obvious added value, but with subtracted decision-making 
information.

For example, consider a deny-overrides Policy with 2 Permit Rules, RP1 
and RP2, and 1 Deny Rule, RD3. If the Deny Rule, RD3,  is NotApplicable 
and one Permit Rule, RP2 is Indeterminate then if the remaining Rule, 
RP1, evaluates to Permit, then the Policy evaluates to Permit.

Now split the Rules into 2 Policies, one with a Permit, RP2, and Deny, 
RD3, and the other with one Permit RP1, and put the Policies in a 
deny-overrides PolicySet. If the Deny Rule, RD3, again is NotApplicable 
and the companion Permit Rule, RP2, is again Indeterminate then that 
Policy will return Indeterminate. If the remaining Rule, RP1, in the 
other Policy, again evaluates to Permit, then that Policy will evaluate 
to Permit. Now the PolicySet, which contains the two Policies which 
together contain the same three rules as the case above, and all the 
Rules evaluate the same as above, then now this combined PolicySet 
evaluates to Indeterminate, even though there was a valid Permit and no 
applicable Deny.

Interesting, if you switch RP2 to be NotApplicable, and RD3 to be 
Indeterminate, then both cases evaluate to Indeterminate.

The point is that by introducing a distinction between rule and policy 
combining we end up with a non-intuitive structure where sometimes 
behavior is consistent and sometimes not depending on the subtleties of 
the whether the container is a container of Rules directly or a 
container of containers of Rules.

Now my proposal is not to take away any of the above-mentioned behavior 
from those who choose to use it, but to offer an alternative behavior 
which is container-consistent, which will enable one to focus on 
managing collections of Rules without worrying about whether the 
structure of the containers might contain unexpected side-effects such 
as described above.

The extended algorithms provide this container uniformity, while at the 
same time not introducing new complexity, but simply by avoiding 
removing potentially useful decision making information. With the 
combined algorithms, for example, a top level deny-overrides PolicySet 
will always know when it receives an Indeterminate, whether that 
Indeterminate was a potential deny or not.

I believe the combination of retaining information that is lost from the 
existing algorithms plus the conceptual improvement of having uniform 
container algorithms is sufficient justification to include these 
extended algorithms as valuable options that one can choose. No one will 
have to use them under any circumstances, but I believe that there are 
organizations that would value the conceptual simplification that the 
extended algorithms offer from the perspective of getting consistent 
behavior from the container structures.

    Thanks,
    Rich






Erik Rissanen wrote:
  

All,

We still have the combining algorithms issue to consider. I have 
written some text to consider and tried to organize the decisions we 
need to make.

First, do we want to fix the current deny/permit policy algorithms at 
all? I think we should since it is not good that the basic algorithms 
are biased. It can lead to strange effects in policies, like a policy 
can return Deny although there is no rule with Effect="Deny" in it.

Assuming that we do want to fix the basic combining algorithms so that 
they are not biased,  then there are two orthogonal decisions for us 
to make:

1. Do we want to define biased algorithms as well, or do we rely on 
the PEP bias alone?

2. Do we want to make use of an extended Indeterminate to allow more 
fine grained treatment of errors in the combining algorithms?

See the attached documents for what the different algorithms look like.

comb-algs.doc contains combining algorithms which makes the basic 
algorithms unbiased and introduces separate biased algorithms. The 
word diff is against the current 3.0 working draft 7.

comb-algs-extended.doc shows algorithms which make use of an extended 
indeterminate. The diff is against the unbiased algorithms in 
comb-algs.doc. I have not "ported" the other algorithms to the 
extended Indeterminate yet or written biased variants. Also note that 
under the extended indeterminate the rule and policy combining 
algorithms become the same, so I joined up their descriptions.

My preference is that

- The basic combining algorithms are made unbiased. (I feel strongly 
about this, the rest I care less about.)

- We do not introduce biased alternatives. (I am happy with the PEP 
bias.)

- We do not introduce an extended indeterminate. (I think it 
complicates matters for fairly little value.)

Best regards,
Erik
------------------------------------------------------------------------

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