OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
Expand all | Collapse all

RE: Additional Combining Algorithms Profile V1.0 and some notes on combining algorithms

  • 1.  RE: Additional Combining Algorithms Profile V1.0 and some notes on combining algorithms

    Posted 02-07-2013 17:57
      |   view attached
    Hi, I think the last "if" block is not necessary and can be removed (check the last table in the attached PDF). Which made me think that probably pseudo-code is not the best way to explain the policy/rule combining behavior, because we are somehow mixing the "what" and "how". I suggest the policy/rule combining should be described as a "function" and then, if necessary, a (non-normative) algorithm be proposed for computing it --leaving it up to developer to perhaps find other ways to compute it more efficiently in the specific context. Please see the attached PDF in which I discussed this briefly. Also, we must be aware that the combing algorithm of this profile is different from the others we have seen so far, since not only does it care about the order of the children*, it also depends on the number of children. I think this is a bit counter-intuitive and somehow stretching the meaning of "combining algorithm" for implementing something that is not inherently/semantically a combining algorithm's job. Maybe a cleaner approach is to support conditions on Policy/PolicySets to avoid complicated workarounds like this. [*] Sensitivity to the order of children (as it also exists in the standard "first-applicable" combining algorithm) is generally undesirable. It makes the policy more difficult to understand and maintain, since the rules/policies will no longer be independent of each other and adding a rule/policy requires going through the entire collection to analyze its implicit effects on the others which is an administrative nightmare --remember iptables. Regards, Mohammad Jafari Security Architect, Edmond Scientific Company

    Attachment(s)

    pdf
    comb-alg.pdf   138 KB 1 version


  • 2.  Re: Additional Combining Algorithms Profile V1.0 and some notes on combining algorithms

    Posted 02-07-2013 20:07
    Hi, See inline. On 02/07/2013 06:56 PM, Mohammad Jafari wrote: > Hi, > > I think the last "if" block is not necessary and can be removed (check the last table in the attached PDF). I know. Pablo here at Axiomatics told me that after we had voted it up, but since it does not change the normative meaning, I did not want to pull it back to make changes. > Which made me think that probably pseudo-code is not the best way to explain the policy/rule combining behavior, because we are somehow mixing the "what" and "how". I suggest the policy/rule combining should be described as a "function" and then, if necessary, a (non-normative) algorithm be proposed for computing it --leaving it up to developer to perhaps find other ways to compute it more efficiently in the specific context. > > Please see the attached PDF in which I discussed this briefly. Yes, that's an alternative way to define them. But the pseudo code works too and that's how it has been done in the past, so I figured for sake of familiarity it's good to do so now too. I would be fine with either, but I suspect most techies with less formal training are more comfortable reading pseudo code than logical notation. ;-) > Also, we must be aware that the combing algorithm of this profile is different from the others we have seen so far, since not only does it care about the order of the children*, it also depends on the number of children. I think this is a bit counter-intuitive and somehow stretching the meaning of "combining algorithm" for implementing something that is not inherently/semantically a combining algorithm's job. Maybe a cleaner approach is to support conditions on Policy/PolicySets to avoid complicated workarounds like this. Yes that would have been cleaner, but given the time frame of the standard, and the controversial nature of this topic (some implementations depend on restricted form of targets for optimizations, if I have understood it correctly from the email archives), this was a more pragmatic approach to get this in there for those who find it useful. > > [*] Sensitivity to the order of children (as it also exists in the standard "first-applicable" combining algorithm) is generally undesirable. It makes the policy more difficult to understand and maintain, since the rules/policies will no longer be independent of each other and adding a rule/policy requires going through the entire collection to analyze its implicit effects on the others which is an administrative nightmare --remember iptables. I would think that there are situations where people like to express "rules and exceptions" in this manner. If someone does not like ordered algorithms, then can choose to not use them. I think they serve a practical purpose. Best regards, Erik > Regards, > Mohammad Jafari > Security Architect, Edmond Scientific Company > > >