Re: AW: [xacml] three questions: string-not-equal & valid FulfillOnattributevalues & placement of variableDefintions

Hi Jan,

    

    The string-not-equal function does not work if you have something
    like this:

    

    <Request>

      role = employee

      role = manager

    ...

    

    If you then have target like this:

    

    <Target>

      role string-not-equal "manager"

    ....

    

    This target would match the above request, although the subject in
    this case does have the manager role. This is because the target
    match element is looking for at least one value which gives "true"
    on the matching function. "employee" will in this case do so.

    

    Best regards,

    Erik

    

    

    On 2011-05-30 21:18, Jan Herrmann wrote:
    
      
      
      
        
          
          
          

            
Hi Erik, Bill, all

            
thanks a lot for all
                  your
                  feedback mails.

            
 

            
regarding your
                  comments
                  on the string-not-equal Matchfunction issue: 

            
The string-not-equal
                  function
                  is the inverse of the string-equal. Instead of
                  checking whether an attribute equals
                  some of the values of its domain one can always do the
                  inverse - if that’s
                  easier.

            
Further there are
                  use
                  cases were you want to explicitly express that all
                  rules in policy shall not be
                  applicable if some attribute is not equal with a
                  certain value. 

            
E.g. Having a
                  predefined
                  and unmodifiable root PolicySet element that says,
                  resource-id != Service-A
                  will guarantee that the children of this
                  <PolicySet> Element will never apply
                  to ADRs that refer to an access request on the
                  resource Service-A.

            
 

            
However the
                  circumstances
                  and requirements are the mentioned string-not-equal
                  function can avoid the need
                  to shift rule-semantics down in the Rule/Condition
                  element. As you said this applies
                  to other functions too and I totally agree that
                  support of <Condition> elements
                  in <Policy> and <PolicySet> elements might
                  greatly enhance
                  flexibility.

            
Maybe we should add
                  this
                  topic on the TC-agenda items list.

            
 

            
Regarding you
                  feedback on
                  the FulfillOn=Indeterminate attributevalue for
                  Obligations:

            
As mentioned in a
                  previous mail thread one great use case for
                  obligations is to use them as a
                  generic way to define IndeterminateHandlers and
                  internalStateHandlers.

            
E.g. if an
                  AttributeSelector
                  or AttributeDesignator is evaluating to Indeterminate,
                  a new XML Attribute in
                  these two elements – let’s call it
                  IndeterminateHandler- could
                  refer to an Obligation that instructs the PIP to add
                  additional data to the “incomplete”
                  ADR. Thus a mechanism is strongly required when
                  protecting transactional
                  services and is additionally at least a very
                  appropriate solution for the BreakTheGlas
                  Problem. If we have time I would like to discuss the
                  proposal in Boston.
                  

            
@Bill: As far as I
                  know Obligation
                  combining and obligation conflict resolution is not
                  yet defined and so the Indeterminate
                  case will not make things worse.

            
 

            
Regarding you
                  feedback on
                  the VariableDefinition placement:

            
The principle of
                  visibility
                  of variables could be applied in the XACML world.
                  Can’t we treat a
                  <R>, <P> and <PS> as a Java-Block
                  equivalent?

            
 

            
All the Best

            
Jan 

            
 

            
 

            
 

            
 

            

              
--

              
Jan
                    Herrmann

              
Dipl.-Inform.,
                    Dipl.-Geogr.

              
Scientific
                    Assistant

              
Chair
                    for Applied
                    Informatics / Cooperative Systems

              
Technische
                    Universität München

              
Boltzmannstr.
                    3

              
85748
                    Garching

              
Germany

              
T: +49 89 289
                    18692

              
F: +49 89 289
                    18657

              
W:
                    www11.in.tum.de

            

            

              

                

                      
                    

                
Von: Erik Rissanen
                      [mailto:] 

                      Gesendet:
                      Montag, 30. Mai 2011
                      18:36

                      An:
                      

                      Betreff:
                      Re: [xacml] three
                      questions: string-not-equal & valid FulfillOn
                      attributevalues &
                      placement of variableDefintions

              

              
 

              
Hi Jan,

                    

                    On second thought, I don't think the
                    string-not-equals would be useful. It
                    won't do what you want in a target in case of
                    multiple values. The target would
                    match if at least one of the values in the request
                    causes string-not-equal to
                    return true. That's not what you would want to.

                    

                    So you would need to use a condition.

                    

                    Best regards,

                    Erik

                    

                    On 05/30/2011 05:14 PM, Erik Rissanen wrote: 

              
Hi Jan,

                    

                    See inline.

                    

                    On 2011-05-30 16:38, Jan Herrmann wrote: 

              
Hi all,

              
three little questions:

              
1. Would it not be useful to
                    allow a
                    sting-not-equal Match-function?

              

                    Yes, it would since it's not possible to use a "not"
                    function in a
                    target. However, my opinion is that the fault is not
                    that there is no
                    string-not-equal function, but the problem is that
                    one cannot use a condition
                    in a policy or policy set. There are lots of cases
                    where one has to use weird
                    constructs to work around that, and your case is
                    just one such example.

                    

                    

                    

              
2. Is there a
                    reason
                    why one can not define an ObligationExpression with
                    a
                    FulfillOn=”Indeterminate” value?

              

                    Maybe someone from the XACML 1.0 era here could
                    respond better, but it seems a
                    bit weird to put enforcement actions in an error,
                    meaning that we don't even
                    know whether a policy applied or not. I don't have
                    done a formal analysis of a
                    the matter though.

                    

                    

                    

              
3. Why do
                    VariableDefinitions have to be bound to a
                    <Policy> element and not to
                    e.g. the root <PolicySet> element?

              

                    Again, others would know better, but I guess this
                    was simply a design choice. I
                    guess since conditions can appear only in rules, the
                    need for variable
                    definitions was most urgent in a Policy. Of course,
                    now
                    AttributeAssignmentExpression changes that.

                    

                    Best regards,

                    Erik

                    

                    

                    

              
 

              
Best Regards

                    Jan

              
 

              
--

              
Jan Herrmann

              
Dipl.-Inform.,
                    Dipl.-Geogr.

              
Scientific
                    Assistant

              
              
Chair
                    for Applied
                    Informatics / Cooperative Systems

              
              
Technische
                    Universität
                    München

              
Boltzmannstr.
                    3

              
85748
                    Garching

              
Germany

              
T: +49 89 289
                    18692

              
F: +49 89 289
                    18657

              
W:
                    www11.in.tum.de