Reduction of deny

[Erik Rissanen <mirty@sics.se>]

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