OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Re: [xacml] Combining algorithm combining orders

    Posted 10-27-2008 01:08
    
    
      
    
    
    Hi Daniel,

    I do not understand your objection. My suggestion removes nothing from the existing logic in terms distinguishing between effect and decision. In fact, it adds the ability to determine effect at the policy level as well, which the current algorithms do not include which results in the ambiguous and contrary results as described by Erik in his original email:
    http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
    where a Rule with Effect="Permit" results in a parent Policy with decision = "Deny".

    If you follow the logic I described in detail, especially in the 3rd email (although it also exists in the first two as well):
    http://lists.oasis-open.org/archives/xacml/200810/msg00044.html
    I think you will find it to be the case that current effect logic is preserved, as well as all distinctions between errors and results.

    The main point is to define what "Effect" really means, which is that the contained logic can produce one and only one of the decision types: i.e. either Permit or Deny, but not both (obviously not "both" at the same time, but "both" in the sense that until evaluation it is not determisitic which can be produced, which becomes the case when multiple Rules are present within a Policy that have different "Effects".). Once characterized in this manner, it is straight-forward to carry it up along with rest of the combining information.

        Thanks,
        Rich



    Daniel Engovatov wrote:
    1260244890-1225067743-cardhu_decombobulator_blackberry.rim.net-1359720348-@bxe148.bisx.prod.on.blackberry" type="cite">
    I disagree with this assessment. I think it was important to separate the ability to explicitly handle errors from results. So effect and decision are distinct on purpose. 
    
    What we really need is a normative and portable way to define and exchange combining policies. 
    
    Daniel. 
    


  • 2.  Re: [xacml] Combining algorithm combining orders

    Posted 10-29-2008 18:15
    Rich, All,
    
    It's a very interesting discussion you have here with some good 
    thoughts, but there are some things that I don't agree with.
    
    It's a long thread, so it's a bit hard to make responses, so I will just 
    write up my comments here, in the hope that everybody can figure out 
    what I mean. :-)
    
    1. You say that we don't need all of the levels PolicySet, Policy and 
    Rule. I kind of agree. I have thought the same thing before. I don't see 
    the need to differentiate between PolicySet and Policy. A Rule on the 
    other hand is something entirely different, and should be distinct. 
    (When you say that a Rule and Policy need not be separated, you are at 
    the same time modifying the Policy to contain an Effect, essentially 
    making it what a Rule is today.)
    
    However, I don't think this is important enough to motivate a change 
    which complicates compatibility between 2.0 and 3.0.
    
    2. In your first email you suggest that the rule combining algorithm 
    should be changed (around the test for a "potential deny"). I don't 
    agree. It's the policy combining algorithm which is wrong, the rule 
    combining algorithm is right and by changing it you would introduce the 
    same kind of error in the rule combining algorithm as well.
    
    3. You say that policies should be constrained by an Effect. I don't 
    agree with this. Policies/PolicySets are not the leaf nodes in the 
    policy tree, where the effect should be. Policy/PolicySet is for 
    combining results from lower levels. This is completely right.
    
    Instead, what you are kind of approaching here is something similar to 
    what Olav Bandmann did at SICS when we did some formal analysis/modeling 
    of XACML.
    
    He suggested to me that the concept of Indeterminate could be extended 
    to include a set of "potential results". Currently an Inderminate means 
    "There was an error, and it could have been a Deny, Permit or NA".
    
    Instead, we could extend Indeterminate so it also includes a more fine 
    grained set of potential results. For instance, if a rule with 
    Effect=Permit is evaluated to Indeterminate, we know that it could never 
    have been a Deny, so we could say that the result is Indet{P/NA}, 
    meaning that "there was an error, and it could have been eitther a 
    Permit or a NA". There are two other possible versions of Indeterminate 
    in this model: Indet{D/NA} and Indet{P/D/NA}. Under the old rules, every 
    Indeterminate is equivalent to an Indet{P/D/NA}. (It's this model Olav 
    used to analyze the current algorithms, and that was when he found the 
    errors we are currently debating.)
    
    Now, if a deny overrides combining algorithm would have to combine a 
    Permit and a Indet{P/NA}, it could see that the indeterminate could 
    never be Deny, so it can safely return a Permit, despite the error.
    
    I think Rich you were looking for something similar. But it's the 
    Indeterminate result which needs to be extended with the effect, not the 
    Policy.
    
    Under this extended model, the extended set of the Indeterminate could 
    be something entirely internal to the PDP, just for the combining 
    algorithms to use, or it could also be exposed to the outside the response.
    
    Anyway, Olav made the suggestion a couple of years ago, but I never 
    posted it to the list since we both thought it would be too 
    controversial to be accepted by the TC.
    
    It is interesting to note that the rule combining algorithms already 
    work like this. That's what the "potential-deny/permit" tests do in 
    effect. If this analysis would have been followed also on the policy 
    combining algorithms, they would not have been made the way they are today.
    
    I guess that the reason the policy combining algorithms are wrong is the 
    use case you are talking about Rich: sometimes policy authors want to 
    specify in their policy that indeterminates should not be propagated 
    upwards. To handle this, the end result in the design became the current 
    algorithms. (I am just speculating here, I wasn't a member of the TC 
    back then, so I don't know.)
    
    Sure, I agree that sometimes it is useful to not propagate errors, but 
    in many (most?) cases it is not. We need to separate these two use cases 
    into two different algorithms.
    
    So I propose that:
    
    A. For 2.0 we change nothing. This is is too big to be errata.
    
    B. For 3.0 we change the behavior of the currently defined 
    permit/deny-overrides algorithms so that they always propagate 
    Indeterminates upwards. (We do not change the identifiers.)
    
    C. For 3.0 we introduce new combining algorithms 
    "permit-overrides-indeterminate" and "deny-overrides-indeterminate", 
    which never propagate an Indeterminate upwards, rather they will default 
    to Permit/Deny in case of an error.
    
    (I think the concept of extended Indeterminate is a bit complex, and I 
    am not sure if it's really worth so much, so I do not propose that we 
    introduce it.)
    
    Best regards,
    Erik
    
    
    Rich.Levinson wrote:
    > Hi Daniel,
    >
    > I do not understand your objection. My suggestion removes nothing from 
    > the existing logic in terms distinguishing between effect and 
    > decision. In fact, it adds the ability to determine effect at the 
    > policy level as well, which the current algorithms do not include 
    > which results in the ambiguous and contrary results as described by 
    > Erik in his original email:
    > http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
    > where a Rule with Effect="Permit" results in a parent Policy with 
    > decision = "Deny".
    >
    > If you follow the logic I described in detail, especially in the 3rd 
    > email (although it also exists in the first two as well):
    > http://lists.oasis-open.org/archives/xacml/200810/msg00044.html
    > I think you will find it to be the case that current effect logic is 
    > preserved, as well as all distinctions between errors and results.
    >
    > The main point is to define what "Effect" really means, which is that 
    > the contained logic can produce one and only one of the decision 
    > types: i.e. either Permit or Deny, but not both (obviously not "both" 
    > at the same time, but "both" in the sense that until evaluation it is 
    > not determisitic which can be produced, which becomes the case when 
    > multiple Rules are present within a Policy that have different 
    > "Effects".). Once characterized in this manner, it is straight-forward 
    > to carry it up along with rest of the combining information.
    >
    >     Thanks,
    >     Rich
    >
    >
    >
    > Daniel Engovatov wrote:
    >> I disagree with this assessment. I think it was important to separate the ability to explicitly handle errors from results. So effect and decision are distinct on purpose. 
    >>
    >> What we really need is a normative and portable way to define and exchange combining policies. 
    >>
    >> Daniel. 
    >> 


  • 3.  Re: [xacml] Combining algorithm combining orders

    Posted 10-30-2008 04:50
    
    
      
    
    
    Hi Erik,

    Thanks for the detailed response. I think we are pretty much on the same wavelength and it is just a matter of identifying the key details and how to represent them in 2.0 and 3.0 (w no intent to change anything in 2.0 except possibly combining algorithm details if they are found to be inconsistent with what we perceive to be intended).

    Responses inline: (Note: I am still not 100% sure of the logic I am suggesting (i.e. I may be missing something), but am offering it as analysis, which appears to me at least to yield a possible simplification, which appears to remove the problem of Permits being converted into Denys, plus fairly simply also removes the need for separate rule and policy combining algorithms.)

    Erik Rissanen wrote:
    490886C9.6030003@axiomatics.com" type="cite">Rich, All,

    It's a very interesting discussion you have here with some good thoughts, but there are some things that I don't agree with.

    It's a long thread, so it's a bit hard to make responses, so I will just write up my comments here, in the hope that everybody can figure out what I mean. :-)

    1. You say that we don't need all of the levels PolicySet, Policy and Rule. I kind of agree. I have thought the same thing before. I don't see the need to differentiate between PolicySet and Policy. A Rule on the other hand is something entirely different, and should be distinct. (When you say that a Rule and Policy need not be separated, you are at the same time modifying the Policy to contain an Effect, essentially making it what a Rule is today.)
    Actually, all I am saying is that conceptually, based on the Effects of the Rules that a Policy contains that a Policy may or may not have a defined Effect. If all the Rules within a Policy are Deny, then the Policy cannot possibly produce a Permit, and vice versa. I am also saying that when the Policy processes the Rules it can keep track of the Effects and determine if it effectively has a Permit or Deny or no Effect. Then a PolicySet, with its policy combining algorithm can apply the same type of logic: i.e. if a Policy evaluates to Indeterminate, it can easily within the rule combining algorithm have retained the fact whether all the rules had the same Effect or not, and, if so, which value the Effect would have.

    What happens with the current combining algorithms is that in the rule combining deny overrides there is a built-in unbiased choice being made which passes up ambiguity which results in the PolicySet that is delivered this rule combining result is unable to determine whether or not the Policy could have possibly returned a Deny or not.

    That is an observation, not intended to say whether the algorithm is right or wrong, just that it appears to be unnecessarily removing information that might have been useful.

    The other obvious choice is to return a Deny, which is what I suggested, which is what I would call a "deny-biased deny overrides" rule combining algorithm. i.e. it would return deny if it found a deny could possibly be returned. This might be slightly less ambiguous than unbiased version, but also has the disadvantage of introducing ambiguity into whether the Deny was real or potential.

    Actually, given the asserted objective of the algorithm, I think both choices are bad and that a better choice is to calculate whether there is a game changer in the Indeterminates. This way the rule combining algorithm would return one of the following:
    • Permit
    • Deny
    • Indeterminate + (calculatedEffect = Permit, Deny, or None)
    • NotApplicable
    where the "calculatedEffect" is just an indicator as to whether all the applicable Rules were Permit or all Deny or a mix in which case the Policy has no implicit Effect.

    I believe this slight change would have two results:
    1. It would remove the distinction between rule combining and policy combining because both types of algorithm would now process definitive Deny's and Permits plus have a possible modifier indicating the character of an Indeterminate result that might have been obtained.
    2. With that distinction removed, the PolicySet and Policy no longer need to be distinct either.
    I think the net effect would be that the Indeterminates could be cut off at whatever level desired by simply inserting a "biased" combining algorithm wherever it was deemed to be needed.You could put it in the top level policy set and have a flag as to whether you had a biased PDP or not, and if not, pass it on up and leave the choice to the PEPs.

    But I think the net effect is that we could have a uniform structure of PolicySets containing Rules and PolicySets, just like a file system has directories that contains directories and files. Each PolicySet would have a "combining algorithm", which could be either a biased or un-biased flavor.

    For 2.0 we simply could define rule combining algorithms that return a calculatedEffect along with the result. For a biased algorithm, the calculatedEffect would be irrelevant since it is already embodied in the result, and for an unbiased algorithm it passes up the potentially useful information that the Policy could have produced only one possible Effect.
    490886C9.6030003@axiomatics.com" type="cite">
    However, I don't think this is important enough to motivate a change which complicates compatibility between 2.0 and 3.0.

    2. In your first email you suggest that the rule combining algorithm should be changed (around the test for a "potential deny"). I don't agree. It's the policy combining algorithm which is wrong, the rule combining algorithm is right and by changing it you would introduce the same kind of error in the rule combining algorithm as well.
    I believe this was answered above - basically the point I was making there was that by making the rule combining biased, that the policy combining would no longer be in a position to turn Permits into Deny because potential Denys would be pre-resolved and that if the policy combining had the calculatedPolicyEffect then it would be able to make its own decision in the unbiased case. Basically, at that point I was concerned with the fact that information was being screened out of the policy combining which caused it to be in the position you originally characterized of one where it reversed a Permit rule into a Deny. As indicated above, I think there are no "good" choices if you don't return the calculatedEffect. Either choice removes information, causing policy combining to be dealing with ambiguous results.
    490886C9.6030003@axiomatics.com" type="cite">
    3. You say that policies should be constrained by an Effect. I don't agree with this. Policies/PolicySets are not the leaf nodes in the policy tree, where the effect should be. Policy/PolicySet is for combining results from lower levels. This is completely right.
    I didn't say the policies "should be constrained by an Effect". I said that policies could calculate an Effect, which policy combining could use or not depending on the algorithm. Again the only "Effect" a Policy would have is "Permit" if all the applicable Rules were Permits, i.e. similar to a single Rule with Effect of Permit in a Policy should not be able to produce a Deny, I think one can argue that a collection of Rules, all whose Effects are Permit, should not be able to produce a Deny either. That is the only meaning to this calculatedPolicyEffect that I am considering.
    490886C9.6030003@axiomatics.com" type="cite">
    Instead, what you are kind of approaching here is something similar to what Olav Bandmann did at SICS when we did some formal analysis/modeling of XACML.

    He suggested to me that the concept of Indeterminate could be extended to include a set of "potential results". Currently an Inderminate means "There was an error, and it could have been a Deny, Permit or NA".

    Instead, we could extend Indeterminate so it also includes a more fine grained set of potential results. For instance, if a rule with Effect=Permit is evaluated to Indeterminate, we know that it could never have been a Deny, so we could say that the result is Indet{P/NA}, meaning that "there was an error, and it could have been eitther a Permit or a NA". There are two other possible versions of Indeterminate in this model: Indet{D/NA} and Indet{P/D/NA}. Under the old rules, every Indeterminate is equivalent to an Indet{P/D/NA}. (It's this model Olav used to analyze the current algorithms, and that was when he found the errors we are currently debating.)
    I believe that the "calculatedEffect" I describe above serves this same function. It is simply a byproduct of rule processing that can be factored into policy combining algorithmically rather than defining different classes of "Indeterminate".
    490886C9.6030003@axiomatics.com" type="cite">
    Now, if a deny overrides combining algorithm would have to combine a Permit and a Indet{P/NA}, it could see that the indeterminate could never be Deny, so it can safely return a Permit, despite the error.

    I think Rich you were looking for something similar. But it's the Indeterminate result which needs to be extended with the effect, not the Policy.

    Under this extended model, the extended set of the Indeterminate could be something entirely internal to the PDP, just for the combining algorithms to use, or it could also be exposed to the outside the response.

    Anyway, Olav made the suggestion a couple of years ago, but I never posted it to the list since we both thought it would be too controversial to be accepted by the TC.

    It is interesting to note that the rule combining algorithms already work like this. That's what the "potential-deny/permit" tests do in effect. If this analysis would have been followed also on the policy combining algorithms, they would not have been made the way they are today.
    I pretty much agree with all this. What I think happens with the current structure is that by removing the notion of "Effect" at the policy combining level, that we are introducing unnecessary complexity conceptually which results in all kinds of strange behavior such as the Permit becoming Deny that you originally described. By simply retaining the "notion" of "Effect" we are able to have uniform logic in the combining algorithms, which preserves information of a consistent character that is currently being thrown away plus removes the need to have distinct policy or rule combining algorithms.
    490886C9.6030003@axiomatics.com" type="cite">
    I guess that the reason the policy combining algorithms are wrong is the use case you are talking about Rich: sometimes policy authors want to specify in their policy that indeterminates should not be propagated upwards. To handle this, the end result in the design became the current algorithms. (I am just speculating here, I wasn't a member of the TC back then, so I don't know.)

    Sure, I agree that sometimes it is useful to not propagate errors, but in many (most?) cases it is not. We need to separate these two use cases into two different algorithms.
    I agree. I think this is the notion of biased (consumes errors) vs unbiased (propagates errors).
    490886C9.6030003@axiomatics.com" type="cite">
    So I propose that:

    A. For 2.0 we change nothing. This is is too big to be errata.
    I agree 2.0 should be left alone.
    490886C9.6030003@axiomatics.com" type="cite">
    B. For 3.0 we change the behavior of the currently defined permit/deny-overrides algorithms so that they always propagate Indeterminates upwards. (We do not change the identifiers.)
    This I would consider the "unbiased" set of algorithms, which, if they do not include a calculatedPolicyEffect, remove the fact of potentialDeny or potentialPermit that might have been encountered.
    490886C9.6030003@axiomatics.com" type="cite">
    C. For 3.0 we introduce new combining algorithms "permit-overrides-indeterminate" and "deny-overrides-indeterminate", which never propagate an Indeterminate upwards, rather they will default to Permit/Deny in case of an error.
    This I would consider to be the "biased" set of algorithms, which, regardless of whether they retain a calculatedPolicyEffect remove the information as to whether the Deny or Permit being reported was potential or real.
    490886C9.6030003@axiomatics.com" type="cite">
    (I think the concept of extended Indeterminate is a bit complex, and I am not sure if it's really worth so much, so I do not propose that we introduce it.)
    I believe the "calculatedPolicyEffect" very cheaply produces the same information as the "extended Indeterminate" and would remove the need to have separate rule and policy combining algorithms which I believe have the effect of removing information causing unnecessary ambiguity at the policy combining level.
    490886C9.6030003@axiomatics.com" type="cite">
    Best regards,
    Erik


    Rich.Levinson wrote:
    Hi Daniel,

    I do not understand your objection. My suggestion removes nothing from the existing logic in terms distinguishing between effect and decision. In fact, it adds the ability to determine effect at the policy level as well, which the current algorithms do not include which results in the ambiguous and contrary results as described by Erik in his original email:
    http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
    where a Rule with Effect="Permit" results in a parent Policy with decision = "Deny".

    If you follow the logic I described in detail, especially in the 3rd email (although it also exists in the first two as well):
    http://lists.oasis-open.org/archives/xacml/200810/msg00044.html
    I think you will find it to be the case that current effect logic is preserved, as well as all distinctions between errors and results.

    The main point is to define what "Effect" really means, which is that the contained logic can produce one and only one of the decision types: i.e. either Permit or Deny, but not both (obviously not "both" at the same time, but "both" in the sense that until evaluation it is not determisitic which can be produced, which becomes the case when multiple Rules are present within a Policy that have different "Effects".). Once characterized in this manner, it is straight-forward to carry it up along with rest of the combining information.

        Thanks,
        Rich



    Daniel Engovatov wrote:
    I disagree with this assessment. I think it was important to separate the ability to explicitly handle errors from results. So effect and decision are distinct on purpose.
    What we really need is a normative and portable way to define and exchange combining policies.
    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


  • 4.  Re: [xacml] Combining algorithm combining orders

    Posted 10-30-2008 09:15
    Hi Rich,
    
    I misunderstood you on some points, so thanks for the clarifications. 
    With those, yes, I think we are in agreement on the nature of the problem.
    
    Some comments:
    
    1. The calculatedEffect and extended Indeterminate are exactly the same 
    thing, we just call them different names and I used a different 
    notation. (I would perhaps prefer "potentialEffect" instead.)
    
    2. If I understand you correctly, you would like to have a global 
    setting in the PDP to decide whether combining algorithms would be 
    biased or not. I think this is not the correct way to do it, since I 
    think you would probably want to use unbiased combining at lower levels 
    in the policies and propagate errors upwards because there might be 
    other low level policies which do not have errors and could take over 
    and produce a correct result. The biased algorithm would be typically be 
    used at a higher level in the policies to filter out errors if the 
    happen at lower levels and the lower levels cannot sort them out 
    themselves. So I think separate biased/unbiased algorithms are a better 
    choice.
    
    3. I would not like to change the PolicySet/Policy/Rule structure, 
    although PolicySet/Rule would be enough. This would be a change which 
    probably makes migration from 2.0 to 3.0 more difficult because of 
    compatibility issues which I guess are likely to result from this. (But 
    I haven't thought much about this yet, so I don't know for sure.)
    
    4. Yes, currently returning Indeterminate means that information is 
    lost. It would be possible to include the calculatedEffect with each 
    Indeterminate as they are propagated upwards. But I don't think this is 
    a big concern in practice, and it is probably not worth making the 
    standard more complex like this.
    
    Best regards,
    Erik
    
    
    Rich.Levinson wrote:
    > Hi Erik,
    >
    > Thanks for the detailed response. I think we are pretty much on the 
    > same wavelength and it is just a matter of identifying the key details 
    > and how to represent them in 2.0 and 3.0 (w no intent to change 
    > anything in 2.0 except possibly combining algorithm details if they 
    > are found to be inconsistent with what we perceive to be intended).
    >
    > Responses inline: (Note: I am still not 100% sure of the logic I am 
    > suggesting (i.e. I may be missing something), but am offering it as 
    > analysis, which appears to me at least to yield a possible 
    > simplification, which appears to remove the problem of Permits being 
    > converted into Denys, plus fairly simply also removes the need for 
    > separate rule and policy combining algorithms.)
    >
    > Erik Rissanen wrote:
    >> Rich, All,
    >>
    >> It's a very interesting discussion you have here with some good 
    >> thoughts, but there are some things that I don't agree with.
    >>
    >> It's a long thread, so it's a bit hard to make responses, so I will 
    >> just write up my comments here, in the hope that everybody can figure 
    >> out what I mean. :-)
    >>
    >> 1. You say that we don't need all of the levels PolicySet, Policy and 
    >> Rule. I kind of agree. I have thought the same thing before. I don't 
    >> see the need to differentiate between PolicySet and Policy. A Rule on 
    >> the other hand is something entirely different, and should be 
    >> distinct. (When you say that a Rule and Policy need not be separated, 
    >> you are at the same time modifying the Policy to contain an Effect, 
    >> essentially making it what a Rule is today.)
    > Actually, all I am saying is that conceptually, based on the Effects 
    > of the Rules that a Policy contains that a Policy may or may not have 
    > a defined Effect. If all the Rules within a Policy are Deny, then the 
    > Policy cannot possibly produce a Permit, and vice versa. I am also 
    > saying that when the Policy processes the Rules it can keep track of 
    > the Effects and determine if it effectively has a Permit or Deny or no 
    > Effect. Then a PolicySet, with its policy combining algorithm can 
    > apply the same type of logic: i.e. if a Policy evaluates to 
    > Indeterminate, it can easily within the rule combining algorithm have 
    > retained the fact whether all the rules had the same Effect or not, 
    > and, if so, which value the Effect would have.
    >
    > What happens with the current combining algorithms is that in the rule 
    > combining deny overrides there is a built-in unbiased choice being 
    > made which passes up ambiguity which results in the PolicySet that is 
    > delivered this rule combining result is unable to determine whether or 
    > not the Policy could have possibly returned a Deny or not.
    >
    > That is an observation, not intended to say whether the algorithm is 
    > right or wrong, just that it appears to be unnecessarily removing 
    > information that might have been useful.
    >
    > The other obvious choice is to return a Deny, which is what I 
    > suggested, which is what I would call a "deny-biased deny overrides" 
    > rule combining algorithm. i.e. it would return deny if it found a deny 
    > could possibly be returned. This might be slightly less ambiguous than 
    > unbiased version, but also has the disadvantage of introducing 
    > ambiguity into whether the Deny was real or potential.
    >
    > Actually, given the asserted objective of the algorithm, I think both 
    > choices are bad and that a better choice is to calculate whether there 
    > is a game changer in the Indeterminates. This way the rule combining 
    > algorithm would return one of the following:
    >
    >     * Permit
    >     * Deny
    >     * Indeterminate + (calculatedEffect = Permit, Deny, or None)
    >     * NotApplicable
    >
    > where the "calculatedEffect" is just an indicator as to whether all 
    > the applicable Rules were Permit or all Deny or a mix in which case 
    > the Policy has no implicit Effect.
    >
    > I believe this slight change would have two results:
    >
    >    1. It would remove the distinction between rule combining and
    >       policy combining because both types of algorithm would now
    >       process definitive Deny's and Permits plus have a possible
    >       modifier indicating the character of an Indeterminate result
    >       that might have been obtained.
    >    2. With that distinction removed, the PolicySet and Policy no
    >       longer need to be distinct either.
    >
    > I think the net effect would be that the Indeterminates could be cut 
    > off at whatever level desired by simply inserting a "biased" combining 
    > algorithm wherever it was deemed to be needed.You could put it in the 
    > top level policy set and have a flag as to whether you had a biased 
    > PDP or not, and if not, pass it on up and leave the choice to the PEPs.
    >
    > But I think the net effect is that we could have a uniform structure 
    > of PolicySets containing Rules and PolicySets, just like a file system 
    > has directories that contains directories and files. Each PolicySet 
    > would have a "combining algorithm", which could be either a biased or 
    > un-biased flavor.
    >
    > For 2.0 we simply could define rule combining algorithms that return a 
    > calculatedEffect along with the result. For a biased algorithm, the 
    > calculatedEffect would be irrelevant since it is already embodied in 
    > the result, and for an unbiased algorithm it passes up the potentially 
    > useful information that the Policy could have produced only one 
    > possible Effect.
    >>
    >> However, I don't think this is important enough to motivate a change 
    >> which complicates compatibility between 2.0 and 3.0.
    >>
    >> 2. In your first email you suggest that the rule combining algorithm 
    >> should be changed (around the test for a "potential deny"). I don't 
    >> agree. It's the policy combining algorithm which is wrong, the rule 
    >> combining algorithm is right and by changing it you would introduce 
    >> the same kind of error in the rule combining algorithm as well.
    > I believe this was answered above - basically the point I was making 
    > there was that by making the rule combining biased, that the policy 
    > combining would no longer be in a position to turn Permits into Deny 
    > because potential Denys would be pre-resolved and that if the policy 
    > combining had the calculatedPolicyEffect then it would be able to make 
    > its own decision in the unbiased case. Basically, at that point I was 
    > concerned with the fact that information was being screened out of the 
    > policy combining which caused it to be in the position you originally 
    > characterized of one where it reversed a Permit rule into a Deny. As 
    > indicated above, I think there are no "good" choices if you don't 
    > return the calculatedEffect. Either choice removes information, 
    > causing policy combining to be dealing with ambiguous results.
    >>
    >> 3. You say that policies should be constrained by an Effect. I don't 
    >> agree with this. Policies/PolicySets are not the leaf nodes in the 
    >> policy tree, where the effect should be. Policy/PolicySet is for 
    >> combining results from lower levels. This is completely right.
    > I didn't say the policies "should be constrained by an Effect". I said 
    > that policies could calculate an Effect, which policy combining could 
    > use or not depending on the algorithm. Again the only "Effect" a 
    > Policy would have is "Permit" if all the applicable Rules were 
    > Permits, i.e. similar to a single Rule with Effect of Permit in a 
    > Policy should not be able to produce a Deny, I think one can argue 
    > that a collection of Rules, all whose Effects are Permit, should not 
    > be able to produce a Deny either. That is the only meaning to this 
    > calculatedPolicyEffect that I am considering.
    >>
    >> Instead, what you are kind of approaching here is something similar 
    >> to what Olav Bandmann did at SICS when we did some formal 
    >> analysis/modeling of XACML.
    >>
    >> He suggested to me that the concept of Indeterminate could be 
    >> extended to include a set of "potential results". Currently an 
    >> Inderminate means "There was an error, and it could have been a Deny, 
    >> Permit or NA".
    >>
    >> Instead, we could extend Indeterminate so it also includes a more 
    >> fine grained set of potential results. For instance, if a rule with 
    >> Effect=Permit is evaluated to Indeterminate, we know that it could 
    >> never have been a Deny, so we could say that the result is 
    >> Indet{P/NA}, meaning that "there was an error, and it could have been 
    >> eitther a Permit or a NA". There are two other possible versions of 
    >> Indeterminate in this model: Indet{D/NA} and Indet{P/D/NA}. Under the 
    >> old rules, every Indeterminate is equivalent to an Indet{P/D/NA}. 
    >> (It's this model Olav used to analyze the current algorithms, and 
    >> that was when he found the errors we are currently debating.)
    > I believe that the "calculatedEffect" I describe above serves this 
    > same function. It is simply a byproduct of rule processing that can be 
    > factored into policy combining algorithmically rather than defining 
    > different classes of "Indeterminate".
    >>
    >> Now, if a deny overrides combining algorithm would have to combine a 
    >> Permit and a Indet{P/NA}, it could see that the indeterminate could 
    >> never be Deny, so it can safely return a Permit, despite the error.
    >>
    >> I think Rich you were looking for something similar. But it's the 
    >> Indeterminate result which needs to be extended with the effect, not 
    >> the Policy.
    >>
    >> Under this extended model, the extended set of the Indeterminate 
    >> could be something entirely internal to the PDP, just for the 
    >> combining algorithms to use, or it could also be exposed to the 
    >> outside the response.
    >>
    >> Anyway, Olav made the suggestion a couple of years ago, but I never 
    >> posted it to the list since we both thought it would be too 
    >> controversial to be accepted by the TC.
    >>
    >> It is interesting to note that the rule combining algorithms already 
    >> work like this. That's what the "potential-deny/permit" tests do in 
    >> effect. If this analysis would have been followed also on the policy 
    >> combining algorithms, they would not have been made the way they are 
    >> today.
    > I pretty much agree with all this. What I think happens with the 
    > current structure is that by removing the notion of "Effect" at the 
    > policy combining level, that we are introducing unnecessary complexity 
    > conceptually which results in all kinds of strange behavior such as 
    > the Permit becoming Deny that you originally described. By simply 
    > retaining the "notion" of "Effect" we are able to have uniform logic 
    > in the combining algorithms, which preserves information of a 
    > consistent character that is currently being thrown away plus removes 
    > the need to have distinct policy or rule combining algorithms.
    >>
    >> I guess that the reason the policy combining algorithms are wrong is 
    >> the use case you are talking about Rich: sometimes policy authors 
    >> want to specify in their policy that indeterminates should not be 
    >> propagated upwards. To handle this, the end result in the design 
    >> became the current algorithms. (I am just speculating here, I wasn't 
    >> a member of the TC back then, so I don't know.)
    >>
    >> Sure, I agree that sometimes it is useful to not propagate errors, 
    >> but in many (most?) cases it is not. We need to separate these two 
    >> use cases into two different algorithms.
    > I agree. I think this is the notion of biased (consumes errors) vs 
    > unbiased (propagates errors).
    >>
    >> So I propose that:
    >>
    >> A. For 2.0 we change nothing. This is is too big to be errata.
    > I agree 2.0 should be left alone.
    >>
    >> B. For 3.0 we change the behavior of the currently defined 
    >> permit/deny-overrides algorithms so that they always propagate 
    >> Indeterminates upwards. (We do not change the identifiers.)
    > This I would consider the "unbiased" set of algorithms, which, if they 
    > do not include a calculatedPolicyEffect, remove the fact of 
    > potentialDeny or potentialPermit that might have been encountered.
    >>
    >> C. For 3.0 we introduce new combining algorithms 
    >> "permit-overrides-indeterminate" and "deny-overrides-indeterminate", 
    >> which never propagate an Indeterminate upwards, rather they will 
    >> default to Permit/Deny in case of an error.
    > This I would consider to be the "biased" set of algorithms, which, 
    > regardless of whether they retain a calculatedPolicyEffect remove the 
    > information as to whether the Deny or Permit being reported was 
    > potential or real.
    >>
    >> (I think the concept of extended Indeterminate is a bit complex, and 
    >> I am not sure if it's really worth so much, so I do not propose that 
    >> we introduce it.)
    > I believe the "calculatedPolicyEffect" very cheaply produces the same 
    > information as the "extended Indeterminate" and would remove the need 
    > to have separate rule and policy combining algorithms which I believe 
    > have the effect of removing information causing unnecessary ambiguity 
    > at the policy combining level.
    >>
    >> Best regards,
    >> Erik
    >>
    >>
    >> Rich.Levinson wrote:
    >>> Hi Daniel,
    >>>
    >>> I do not understand your objection. My suggestion removes nothing 
    >>> from the existing logic in terms distinguishing between effect and 
    >>> decision. In fact, it adds the ability to determine effect at the 
    >>> policy level as well, which the current algorithms do not include 
    >>> which results in the ambiguous and contrary results as described by 
    >>> Erik in his original email:
    >>> http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
    >>> where a Rule with Effect="Permit" results in a parent Policy with 
    >>> decision = "Deny".
    >>>
    >>> If you follow the logic I described in detail, especially in the 3rd 
    >>> email (although it also exists in the first two as well):
    >>> http://lists.oasis-open.org/archives/xacml/200810/msg00044.html
    >>> I think you will find it to be the case that current effect logic is 
    >>> preserved, as well as all distinctions between errors and results.
    >>>
    >>> The main point is to define what "Effect" really means, which is 
    >>> that the contained logic can produce one and only one of the 
    >>> decision types: i.e. either Permit or Deny, but not both (obviously 
    >>> not "both" at the same time, but "both" in the sense that until 
    >>> evaluation it is not determisitic which can be produced, which 
    >>> becomes the case when multiple Rules are present within a Policy 
    >>> that have different "Effects".). Once characterized in this manner, 
    >>> it is straight-forward to carry it up along with rest of the 
    >>> combining information.
    >>>
    >>>     Thanks,
    >>>     Rich
    >>>
    >>>
    >>>
    >>> Daniel Engovatov wrote:
    >>>> I disagree with this assessment. I think it was important to 
    >>>> separate the ability to explicitly handle errors from results. So 
    >>>> effect and decision are distinct on purpose.
    >>>> What we really need is a normative and portable way to define and 
    >>>> exchange combining policies.
    >>>> Daniel. 


  • 5.  RE: [xacml] Combining algorithm combining orders

    Posted 10-30-2008 10:30
    
    
    
    
    
    All
     
    I agree that 2.0 should be left alone. Think that anything u do in 2.0 will also need to be corrected at the ITU.
    cheers


    From: Rich.Levinson [mailto:rich.levinson@oracle.com]
    Sent: Thursday, October 30, 2008 12:46 AM
    To: Erik Rissanen
    Cc: xacml
    Subject: Re: [xacml] Combining algorithm combining orders

    Hi Erik,

    Thanks for the detailed response. I think we are pretty much on the same wavelength and it is just a matter of identifying the key details and how to represent them in 2.0 and 3.0 (w no intent to change anything in 2.0 except possibly combining algorithm details if they are found to be inconsistent with what we perceive to be intended).

    Responses inline: (Note: I am still not 100% sure of the logic I am suggesting (i.e. I may be missing something), but am offering it as analysis, which appears to me at least to yield a possible simplification, which appears to remove the problem of Permits being converted into Denys, plus fairly simply also removes the need for separate rule and policy combining algorithms.)

    Erik Rissanen wrote:
    490886C9.6030003@axiomatics.com" type="cite">Rich, All,

    It's a very interesting discussion you have here with some good thoughts, but there are some things that I don't agree with.

    It's a long thread, so it's a bit hard to make responses, so I will just write up my comments here, in the hope that everybody can figure out what I mean. :-)

    1. You say that we don't need all of the levels PolicySet, Policy and Rule. I kind of agree. I have thought the same thing before. I don't see the need to differentiate between PolicySet and Policy. A Rule on the other hand is something entirely different, and should be distinct. (When you say that a Rule and Policy need not be separated, you are at the same time modifying the Policy to contain an Effect, essentially making it what a Rule is today.)
    Actually, all I am saying is that conceptually, based on the Effects of the Rules that a Policy contains that a Policy may or may not have a defined Effect. If all the Rules within a Policy are Deny, then the Policy cannot possibly produce a Permit, and vice versa. I am also saying that when the Policy processes the Rules it can keep track of the Effects and determine if it effectively has a Permit or Deny or no Effect. Then a PolicySet, with its policy combining algorithm can apply the same type of logic: i.e. if a Policy evaluates to Indeterminate, it can easily within the rule combining algorithm have retained the fact whether all the rules had the same Effect or not, and, if so, which value the Effect would have.

    What happens with the current combining algorithms is that in the rule combining deny overrides there is a built-in unbiased choice being made which passes up ambiguity which results in the PolicySet that is delivered this rule combining result is unable to determine whether or not the Policy could have possibly returned a Deny or not.

    That is an observation, not intended to say whether the algorithm is right or wrong, just that it appears to be unnecessarily removing information that might have been useful.

    The other obvious choice is to return a Deny, which is what I suggested, which is what I would call a "deny-biased deny overrides" rule combining algorithm. i.e. it would return deny if it found a deny could possibly be returned. This might be slightly less ambiguous than unbiased version, but also has the disadvantage of introducing ambiguity into whether the Deny was real or potential.

    Actually, given the asserted objective of the algorithm, I think both choices are bad and that a better choice is to calculate whether there is a game changer in the Indeterminates. This way the rule combining algorithm would return one of the following:
    • Permit
    • Deny
    • Indeterminate + (calculatedEffect = Permit, Deny, or None)
    • NotApplicable
    where the "calculatedEffect" is just an indicator as to whether all the applicable Rules were Permit or all Deny or a mix in which case the Policy has no implicit Effect.

    I believe this slight change would have two results:
    1. It would remove the distinction between rule combining and policy combining because both types of algorithm would now process definitive Deny's and Permits plus have a possible modifier indicating the character of an Indeterminate result that might have been obtained.
    2. With that distinction removed, the PolicySet and Policy no longer need to be distinct either.
    I think the net effect would be that the Indeterminates could be cut off at whatever level desired by simply inserting a "biased" combining algorithm wherever it was deemed to be needed.You could put it in the top level policy set and have a flag as to whether you had a biased PDP or not, and if not, pass it on up and leave the choice to the PEPs.

    But I think the net effect is that we could have a uniform structure of PolicySets containing Rules and PolicySets, just like a file system has directories that contains directories and files. Each PolicySet would have a "combining algorithm", which could be either a biased or un-biased flavor.

    For 2.0 we simply could define rule combining algorithms that return a calculatedEffect along with the result. For a biased algorithm, the calculatedEffect would be irrelevant since it is already embodied in the result, and for an unbiased algorithm it passes up the potentially useful information that the Policy could have produced only one possible Effect.
    490886C9.6030003@axiomatics.com" type="cite">
    However, I don't think this is important enough to motivate a change which complicates compatibility between 2.0 and 3.0.

    2. In your first email you suggest that the rule combining algorithm should be changed (around the test for a "potential deny"). I don't agree. It's the policy combining algorithm which is wrong, the rule combining algorithm is right and by changing it you would introduce the same kind of error in the rule combining algorithm as well.
    I believe this was answered above - basically the point I was making there was that by making the rule combining biased, that the policy combining would no longer be in a position to turn Permits into Deny because potential Denys would be pre-resolved and that if the policy combining had the calculatedPolicyEffect then it would be able to make its own decision in the unbiased case. Basically, at that point I was concerned with the fact that information was being screened out of the policy combining which caused it to be in the position you originally characterized of one where it reversed a Permit rule into a Deny. As indicated above, I think there are no "good" choices if you don't return the calculatedEffect. Either choice removes information, causing policy combining to be dealing with ambiguous results.
    490886C9.6030003@axiomatics.com" type="cite">
    3. You say that policies should be constrained by an Effect. I don't agree with this. Policies/PolicySets are not the leaf nodes in the policy tree, where the effect should be. Policy/PolicySet is for combining results from lower levels. This is completely right.
    I didn't say the policies "should be constrained by an Effect". I said that policies could calculate an Effect, which policy combining could use or not depending on the algorithm. Again the only "Effect" a Policy would have is "Permit" if all the applicable Rules were Permits, i.e. similar to a single Rule with Effect of Permit in a Policy should not be able to produce a Deny, I think one can argue that a collection of Rules, all whose Effects are Permit, should not be able to produce a Deny either. That is the only meaning to this calculatedPolicyEffect that I am considering.
    490886C9.6030003@axiomatics.com" type="cite">
    Instead, what you are kind of approaching here is something similar to what Olav Bandmann did at SICS when we did some formal analysis/modeling of XACML.

    He suggested to me that the concept of Indeterminate could be extended to include a set of "potential results". Currently an Inderminate means "There was an error, and it could have been a Deny, Permit or NA".

    Instead, we could extend Indeterminate so it also includes a more fine grained set of potential results. For instance, if a rule with Effect=Permit is evaluated to Indeterminate, we know that it could never have been a Deny, so we could say that the result is Indet{P/NA}, meaning that "there was an error, and it could have been eitther a Permit or a NA". There are two other possible versions of Indeterminate in this model: Indet{D/NA} and Indet{P/D/NA}. Under the old rules, every Indeterminate is equivalent to an Indet{P/D/NA}. (It's this model Olav used to analyze the current algorithms, and that was when he found the errors we are currently debating.)
    I believe that the "calculatedEffect" I describe above serves this same function. It is simply a byproduct of rule processing that can be factored into policy combining algorithmically rather than defining different classes of "Indeterminate".
    490886C9.6030003@axiomatics.com" type="cite">
    Now, if a deny overrides combining algorithm would have to combine a Permit and a Indet{P/NA}, it could see that the indeterminate could never be Deny, so it can safely return a Permit, despite the error.

    I think Rich you were looking for something similar. But it's the Indeterminate result which needs to be extended with the effect, not the Policy.

    Under this extended model, the extended set of the Indeterminate could be something entirely internal to the PDP, just for the combining algorithms to use, or it could also be exposed to the outside the response.

    Anyway, Olav made the suggestion a couple of years ago, but I never posted it to the list since we both thought it would be too controversial to be accepted by the TC.

    It is interesting to note that the rule combining algorithms already work like this. That's what the "potential-deny/permit" tests do in effect. If this analysis would have been followed also on the policy combining algorithms, they would not have been made the way they are today.
    I pretty much agree with all this. What I think happens with the current structure is that by removing the notion of "Effect" at the policy combining level, that we are introducing unnecessary complexity conceptually which results in all kinds of strange behavior such as the Permit becoming Deny that you originally described. By simply retaining the "notion" of "Effect" we are able to have uniform logic in the combining algorithms, which preserves information of a consistent character that is currently being thrown away plus removes the need to have distinct policy or rule combining algorithms.
    490886C9.6030003@axiomatics.com" type="cite">
    I guess that the reason the policy combining algorithms are wrong is the use case you are talking about Rich: sometimes policy authors want to specify in their policy that indeterminates should not be propagated upwards. To handle this, the end result in the design became the current algorithms. (I am just speculating here, I wasn't a member of the TC back then, so I don't know.)

    Sure, I agree that sometimes it is useful to not propagate errors, but in many (most?) cases it is not. We need to separate these two use cases into two different algorithms.
    I agree. I think this is the notion of biased (consumes errors) vs unbiased (propagates errors).
    490886C9.6030003@axiomatics.com" type="cite">
    So I propose that:

    A. For 2.0 we change nothing. This is is too big to be errata.
    I agree 2.0 should be left alone.
    490886C9.6030003@axiomatics.com" type="cite">
    B. For 3.0 we change the behavior of the currently defined permit/deny-overrides algorithms so that they always propagate Indeterminates upwards. (We do not change the identifiers.)
    This I would consider the "unbiased" set of algorithms, which, if they do not include a calculatedPolicyEffect, remove the fact of potentialDeny or potentialPermit that might have been encountered.
    490886C9.6030003@axiomatics.com" type="cite">
    C. For 3.0 we introduce new combining algorithms "permit-overrides-indeterminate" and "deny-overrides-indeterminate", which never propagate an Indeterminate upwards, rather they will default to Permit/Deny in case of an error.
    This I would consider to be the "biased" set of algorithms, which, regardless of whether they retain a calculatedPolicyEffect remove the information as to whether the Deny or Permit being reported was potential or real.
    490886C9.6030003@axiomatics.com" type="cite">
    (I think the concept of extended Indeterminate is a bit complex, and I am not sure if it's really worth so much, so I do not propose that we introduce it.)
    I believe the "calculatedPolicyEffect" very cheaply produces the same information as the "extended Indeterminate" and would remove the need to have separate rule and policy combining algorithms which I believe have the effect of removing information causing unnecessary ambiguity at the policy combining level.
    490886C9.6030003@axiomatics.com" type="cite">
    Best regards,
    Erik


    Rich.Levinson wrote:
    Hi Daniel,

    I do not understand your objection. My suggestion removes nothing from the existing logic in terms distinguishing between effect and decision. In fact, it adds the ability to determine effect at the policy level as well, which the current algorithms do not include which results in the ambiguous and contrary results as described by Erik in his original email:
    http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
    where a Rule with Effect="Permit" results in a parent Policy with decision = "Deny".

    If you follow the logic I described in detail, especially in the 3rd email (although it also exists in the first two as well):
    http://lists.oasis-open.org/archives/xacml/200810/msg00044.html
    I think you will find it to be the case that current effect logic is preserved, as well as all distinctions between errors and results.

    The main point is to define what "Effect" really means, which is that the contained logic can produce one and only one of the decision types: i.e. either Permit or Deny, but not both (obviously not "both" at the same time, but "both" in the sense that until evaluation it is not determisitic which can be produced, which becomes the case when multiple Rules are present within a Policy that have different "Effects".). Once characterized in this manner, it is straight-forward to carry it up along with rest of the combining information.

        Thanks,
        Rich



    Daniel Engovatov wrote:
    I disagree with this assessment. I think it was important to separate the ability to explicitly handle errors from results. So effect and decision are distinct on purpose.
    What we really need is a normative and portable way to define and exchange combining policies.
    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