OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Reduction of deny

    Posted 10-31-2005 13:03
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Reduction of deny


    All,
    
    I have been working on the reduction of deny issue. Here is what I think
    so far.
    
    If we want to support deny at the access level we probably need to make
    the effect a part of the situation when reducing access policies. This
    is because if not, an administrative right for a situation would always
    give the right to both deny and permit the access. This is probably not
    what is wanted in all cases. By making the effect a part of the
    situation, we solve that problem. It will be possible to separate
    between the right to permit and the right to deny access.
    
    If we want to support deny in administrative rights, the same problem
    appears at the administrative level. This would mean that we have to add
    the effect of the administrative decision in the Delegates element of
    the Target. Bringing in this would mean that the model becomes more
    complex. I am not sure whether there are use cases for negative
    administrative rights or whether how complex people would think they
    would be. Personally I do not like negative rights, but I don’t feel
    that it complicates extremely much either.
    
    If we choose to not differentiate between reducing deny and permit in
    administrative policies, we still need to define what to do in case an
    administrative policy evaluates to deny.
    
    There are basically two alternatives:
    
    1. Do not support deny in administrative policies at all and drop any
    administrative policy that evaluates to deny.
    2. Reduce both deny and permit using the same administrative request.
    This means that negative administrative policies are supported, but
    anyone with a right to issue a positive administrative policy, could
    also issue a negative one.
    
    The first alternative has the benefit of being simpler.
    
    The second alternative has the benefit that it would still allow for
    negative administrative policies in case people would like to use them.
    If we choose the second alternative, people who would like to not have
    any negative administrative rights would have to choose a permit
    overrides policy combining algorithm. This in turn leads to another
    issue: if someone wants to support negative access rights, but not
    negative administrative rights, he may want to use different combining
    algorithms for administrative and for access policies. For
    administrative rights he would have to use permit overrides in order to
    “disable” negative administrative policies. However, in general, he
    might want to use something else for access policies. This could of
    course be done with a custom combining algorithm which takes two other
    algorithms as parameters, and will apply either depending on whether it
    is an administrative or an access request. If we choose the second
    alternative, we might want to define this “combined” combining algorithm.
    
    Personally I am inclined to drop support for negative administrative
    rights altogether, that is, alternative 1. I am worried that we have not
    thought them through properly and I am not sure people would like to
    have them. In that case it would be better to wait with them for post
    3.0, until there is a clear need and it is well understood how to handle
    them.
    
    To clarify: I propose that we use alternative 2 of the options at
    http://wiki.oasis-open.org/xacml/ReductionOfDeny and discard any
    administrative policy which evaluates to deny.
    
    Erik
    
    
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]