Re: [xacml] Comment on issue 8? "choice element" or "Policy w no Rules"

From
rich levinson <>
Date
2012-02-24T17:07:05+00:00
ID
Thread
Re: [xacml] Comment on issue 8? "choice element" or "Policy w no Rules"
Hi Erik,

    

    It looks to me like there has been a subtle shift of emphasis from

    the contents of the Policy determining the Decision to the combining

    algorithm becoming more active in coming to a Decision regardless

    of what's contained in the Policy. This is not necessarily a bad
    thing,

    but it is a shift of emphasis when considering Policy evaluation. In
    fact,

    it is probably a good thing, because the algorithm can clearly state

    what all the special cases are and we don't have to rely on a bottom

    up analysis of the individual Rules.

    

    So, the bottom line is that the value of a Policy is equal to either

    a value of NotApplicable or Indeterminate returned from Target

    evaluation, or a value determined by the rule-combining algorithm

    applied to a set of Rule nodes, which may have length 0->n.

    

    Personally, I think it is important in this situation that each

    combining algorithm explicitly state its intent wrt to 0-length

    arrays, or at least there should be an introductory section

    to the combining algorithm section that makes this situation

    clear. i.e. there is a specific argument passed to the combining

    algorithm (Node[] children, where Node can be either Rule or

    Policy) and the details of what this argument can contain

    and how the algorithm behaves based on that should be clear.

    

        Thanks,

        Rich

    

    

    

    On 2/24/2012 4:12 AM, Erik Rissanen wrote:
    
      
      Rich,

      

      You are reading an old version of the spec. The current table
      looks like this:

      

      
      
      
      
      
      
      
      Target    Rule values     Policy Value

      “Match”    Don’t care    Specified by the rule-combining algorithm

      “No-match”    Don’t care    “NotApplicable”

      “Indeterminate”    See Table 7 See Table 7

      

      The change was introduced in wd 20 in order to make sure the new
      combining algorithms were always invoked. It would be confusing if
      a policy with permit-unless-deny could return not-applicable since
      this algorithm was specifically introduced to guarantee that N/A
      or Indeterminate are never returned.

      

      Best regards,

      Erik

      

      

      

      On 2012-02-23 21:58, rich levinson wrote:
      
        
        To TC:

        

        To collect the info from today's discussion, which was ref'd in
        the

        Feb 9 minutes:

        

        the "latest email" I thought Erik and I had agreement that a
        statement

        would be made in the "implementor's guide" that a Policy w no
        Rules

        may be ignored  by developers:

        http://lists.oasis-open.org/archives/xacml/201202/msg00000.html

        "It would seem to me that at a minimum, we
            could include

            an advisory note to developers that a PDP may ignore

            a Policy that contains no Rules, since there is no point

            from a XACML functional perspective to provide any logic

            to do anything specific with such Policies.

            

            Such an approach would remove any questions from developers,

            and could leave the schema unchanged."

        
        During today's discussion, the notion was introduced that
        somehow a

        combining algorithm could effectively introduce a decision
        despite the

        fact that there were no Rules in the Policy.

        

        However, I think that interpretation is wrong for the following
        reason.

        For Policy evaluation, we have to refer to section 7.11 "Policy
        Evaluation".

        According to Table 5 there, the following is normative behavior:

        The policy truth table is shown in Table 5.

          
            
              

                Target 
                Rule values
                 Policy Value
              

              

                “Match”
                At least one rule value is its Effect
                Specified by the rule-combining
                  algorithm
              

              

                “Match”
                All rule values are “NotApplicable”

                
                “NotApplicable”
              

              

                “Match”
                At least one rule value is
                  “Indeterminate”
                Specified by the rule-combining
                  algorithm
              

              

                “No-match”
                Don‟t care
                “NotApplicable”
              

              

                “Indeterminate”
                Don‟t care
                “Indeterminate”
              

            
          
          Table 5 Policy truth table

        
        I think we can agree that the Target is a "Match", since, by
        section 7.7, even 

        an empty Target matches any request.

        

        Also, I think that rows 1 and 3 that begin with "At least one
        rule ..." do

        not apply since there are "zero Rules" in the use case we are
        discussing.

        Since those rows are the only places that cause the
        rule-combining

        algorithm to  be invoked, I think we can assume that even
        combining

        algorithms, such as "Deny-unless -permit" (section C.6) or

        "Permit-unless-deny" (section C.7) will not get invoked.

        

        Therefore, the only thing that is left is row 2, which states:

        "All Rule values are "NotApplicable"". I believe this statement

        is TRUE, because in order to be false there must be at least

        one Rule which has a value other than "NotApplicable", which

        is FALSE, and therefore the statement is TRUE.

        

        Therefore, a Policy w no Rules must evaluate to NotApplicable.

        QED. :)

        

            Thanks,

            Rich