Re: [xacml] New algorithm proposal

Hi Rich,

    

    I don't want to change the core schema at this point. Also, there
    are much more you can do in a condition than just comparing a
    subject attribute against a resource attribute. I was using a very
    simple example. Your proposal does not address any of tho other
    requirements.

    

    And this does not change the way "targets are used to filter down to
    rules", since we already have combining algorithms and you can get
    almost the same effect already, as I showed in my examples. The only
    difference is that you don't need to handle the Denys which pop up
    in that structure.

    

    Anyway, I will implement this algorithm in the Axiomatics product
    using our own identifier so our customers can benefit from it, but
    it would be nice if it would be standardized instead since many
    customers are concerned about interoperability.

    

    Best regards,

    Erik

    

    On 2011-12-12 18:06, rich levinson wrote:
    
      
      Hi Erik,

      

      I am concerned that the change you are proposing could be
      disruptive

      to the overall structure of the PolicySet/Policy/Rule hierarchy,
      where

      Target is used to filter down to the Rules.

      

      In order to meet the requirements that your example implies:

      "For instance, someone may want to write a policy

           which applies only to the internal users of a sub
        organization,

           which requires matching the users organization attribute

           to the organization of the resource.

         This cannot currently be done at the policy or policy set
        levels. "

      
      namely that a Match in a Target be able to compare a Subject
      attribute

      with a Resource attribute, I think this could be easily done with
      a simple

      extension to the Match schema. 

      

      For example, the existing schema says:

        <xs:element name="Match"
        type="xacml:MatchType"/> 

          <xs:complexType name="MatchType"> 

            <xs:sequence>

              <xs:element ref="xacml:AttributeValue"/> 

              <xs:choice> 

                 <xs:element ref="xacml:AttributeDesignator"/> 

                 <xs:element ref="xacml:AttributeSelector"/> 

               </xs:choice> 

             </xs:sequence> 

             <xs:attribute name="MatchId" type="xs:anyURI"
        use="required"/> 

            </xs:complexType>

      
      I think the following change would enable the capability you have
      described:

        <xs:element name="Match"
        type="xacml:MatchType"/> 

          <xs:complexType name="MatchType"> 

            <xs:sequence>

              <xs:choice> 

                 <xs:element ref="xacml:AttributeValue"/> 

                 <xs:element ref="xacml:AttributeDesignator"/>
          

                   <xs:element ref="xacml:AttributeSelector"/> 

               </xs:choice> 

              <xs:choice> 

                 <xs:element ref="xacml:AttributeDesignator"/> 

                 <xs:element ref="xacml:AttributeSelector"/> 

               </xs:choice> 

             </xs:sequence> 

             <xs:attribute name="MatchId" type="xs:anyURI"
        use="required"/> 

            </xs:complexType>
      This change should allow comparing, using Target/Match, attribute
      values

      from different entities, such as comparing a Resource attr value w
      a Subject

      attr value.

      

      The 3.0 changes already allow ANDing a Subject attr val w a
      Resource attr val,

      which I think is very narrow functionality, however the proposed
      change

      above would sort of fill in the "missing piece" that the I think
      was implied

      by the intent of the 3.0 changes, but missing from the realization
      of the

      explicit mechanisms that made it into 3.0.

      

        Thanks,

        Rich

      

      On 12/12/2011 2:57 AM, Erik Rissanen wrote:
      All,

        

        

        I have a proposal for a new combining algorithm. I don't want to
        change the core spec at this point, so I suggest we do this
        algorithm as a separate profile. 

        

        The background to this algorithm is that XACML does not allow
        <Condition> elements at the policy or policy set levels.
        This turns out to be a significant restriction in practice. I
        meet it time after time in the real world. 

        

        Typically an XACML policy is written by subdividing the request
        space into recursively smaller policies and rules. The targets
        at the policy and policy set levels allow matching against
        constant values, but not matching between two attributes or
        other more complex expressions. 

        

        This is a problem since it is not unusual to require something
        like that. For instance, someone may want to write a policy
        which applies only to the internal users of a sub organization,
        which requires matching the users organization attribute to the
        organization of the resource. This cannot currently be done at
        the policy or policy set levels. 

        

        For instance, assume that someone wants to write Policy A, which
        should contain condition A. Ideally the user would like to
        define this policy: 

        

        Policy A: 

          Target A 

          Condition A 

          Children of A... 

        

        This is not possible. It would be possible to push down the
        condition A into all rules within Policy A, but that introduces
        complexity, and also worsens performance since the condition
        will not be applied at the higher level in the tree, where it
        could eliminate a subsection of the policy tree. (Agreed, a
        smart XACML implementation might find this redundancy and
        optimize for it, but that complicates implementations.) 

        

        Another option is to work around this is to put the desired
        condition _expression_ in a rule in a policy next to where one
        would like pu the condition, and use a combining algorithm to
        deny access if the condition in the rule does not apply. 

        

        PolicySet C, deny-overrides 

          Policy B 

            Rule B2 deny 

              Condition NOT A 

          Policy A 

            Target A 

            Children of A... 

        

        There are two problems with this. Firstly, the whole is more
        complex, but that can be managed by a tool. The second problem,
        which cannot be solved by a tool is that this is not fully
        equivalent to what the user actually wants to do. 

        

        The problem is that if the condition A does not apply, the
        latter approach returns a Deny instead of a NotApplicable, which
        the former would do. The problem of this is that the deny will
        propagate towards the root of the policy tree, putting
        restrictions on what the other policies can be like since they
        might be overridden by the Deny. This complicates policy
        authoring. 

        

        So I suggest that we define a new combining algorithm. The id
        should be: 

        

        urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:on-permit-apply-second

        

        

        This combining algorithm accepts only two children, and will
        return Indeterminate otherwise. If the first child is a Permit,
        then the result of the combining algorithm is the result of the
        second child. If the first policy is NotApplicable, then the
        whole is NotApplicable. Otherwise the result is Indeterminate. 

        

        The normative pseudo code looks like this: 

        

        Decision onPermitApplySecondCombiningAlgorithm(Node[] children)
        

        { 

          if (lengthOf(children) != 2) { 

            return Indeterminate{DP} 

          } 

          Decision decision0 = children[0].evaluate(); 

          if (decision0 == NotApplicable) { 

            return NotApplicable; 

          } 

          Decision decision1 = children[1].evaluate(); 

          if (decision0 == Permit) { 

            return decision1; 

          } 

          if (decision1 == Permit) { 

            return Indeterminate{P}; 

          } 

          if (decision1 == Deny) { 

            return Indeterminate{D}; 

          } 

          if (decision1 == Indeterminate) { 

            // Return the same flavor of Indeterminate as decision1. 

            // If decision0 == Indeterminate, use status code 

            // from decision0. 

            return decision1; 

          } 

          if (decision1 == NotApplicable) { 

            return NotApplicable; 

          } 

        } 

        

        Note that for simplicity I chose to return Indeterminate{DP} in
        case of an incorrect number of children. We could instead have
        evaluated the second child to figure out what the possible value
        from the second policy would have been and adjust the
        Indeterminate accordingly. But since we are checking for the
        number of children, it's not sure that there is a second policy.
        And this is an obvious error that tools or the PDP can check for
        statically, so it's not worth introducing complexity for. 

        

        Also note that the last if statement is a bit interesting. In
        this case there was an error in the application of the combining
        algorithm when evaluating the first child, but the second child
        is NotApplicable. I chose to return the NotApplicable in this
        case because the whole could never be anything than
        NotApplicable in any case. But this is a bit different from how
        for instance a target is evaluated. If a target becomes
        NotApplicable, the whole is Indeterminate, even if the children
        in theory could be all NotApplicable. But I figured that since
        we have the information available, we can as well use it.
        Alternatively we could skip the whole processing of different
        flavors of Indeterminate, but since the other algorithms do it,
        we may as well do it here. 

        

        Using this combining algorithm it will be possible to write
        policy structures which are equivalent to a <Condition> in
        either a policy or a policy set, without us having to change the
        core spec. Authoring tools can hide this extra structure from
        users if desired. 

        

        Best regards, 

        Erik 

        

        ---------------------------------------------------------------------

        

        To unsubscribe, e-mail: 
        

        For additional commands, e-mail: