Open issues in delegation

[Erik Rissanen <mirty@sics.se>]

Hello,

Here are some issues with delegation that I have thought about that
still need to be resolved in the current draft. Some of them might be
topics at the F2F.

* Are there such things as negative administrative rights? At the access
level currently XACML makes it possible to define a deny effect, which
depending on the combining algorithm may ovverride a permit effect of
another rule/policy. Should we in the same spirit support negative
administrative rights? In other words, should it be possible to say
something as "X may not create a policy for situation Z". I doubt that
this is useful, but should we consider this before we lay it at rest?

* What about administrative policies for creating policies which have a
deny effect at the access level? I think this is also not very useful
but we may want to support in general.

* Related to this is that we need to formally define the environment in
which policies from different issuers are combined. An XACML access
request always starts with a single policy or policy set (correct me if
I am mistaken). If we have policies from multiple sources, they need to
be collected into policy sets, so their results can be combined. The
processing model in the current proposal (draft 02) is really about
defining a particular policy combining algorithm that uses issuer
information.

Briefly, the processing model in general for XACML 3.0 should be defined
something like this:

Every policy has an issuer, either explicitly by definition by the
issuer element, or if the issuer element is not present, the issuer is
implicitly the "PDP" (or "root") issuer.

- Rule evaluation happens like in previous versions of XACML.
- Policy evaluation happens like in previous versions XACML, except the
resulting policy value is associated with the policy issuer.
- Policy set evaluation happens mostly like in previous versions of
XACML, except that a policy combining algorithm MAY take the issuer of a
policy result into account when combining the policy results. The result
of the policy set is associated with the policy set issuer.

Within this general processing model we should define a combining
algorithm called "permit-overrides-authorize-issuer" or the like. This
is a policy combining algorithm that evaluates the policies at the level
of the current request. Now, depending on the results, several things
may happen (I haven't thought about all the possible cases yet):

- A deny result with a non "PDP" issuer is dropped.
- A permit result with a non "PDP" issuer is reevaluated as an
administrative request, and the result of that recursive result replaces
the result when combining the policies. The recursion happens only
within the current policy set, not from the top level policy set in the
PDP. (I am not 100% certain about this.)
- A PDP issued result is kept as it is.

This process, when finished, leads to a number of PDP issued results. If
at least one of them is permit, the result of the policy set is a
permit, otherwise a deny. (Or perhaps a not applicable. We should define
a table of all possible combinations.)

This is essentially the processing model that is in the current draft,
though I don't use the "pool" terminology. Another difference is that I
define that the repeated requests should be evaluated only in the
current policy set, not at the top level in the PDP, since the end
result of the policy combining should be a result that is associated
with the issuer of the current policy set only. This processing model
permits nesting of policy sets with different issuers and allows for the
definition of new combining algorithms in the future.

The above combining algorithm does not allow anything negative at the
administrative level, but the general processing model would support
combining algorithms that define different semantics, leaving it open in
the future to include negative rights.

What I basically say is when a policy or a policy set is evaluated, the
result is associated with the issuer of the policy or policy set. If the
policy or policy set is a part of another policy set, then the combining
algorithm in that policy set has to define what the significance of the
issuer is. The "permit-overrides-authorize-issuer" algorithm ignores any
negative results at the policy level and authorizes any positive
results. Other algorithms may define different semantics.

My suggestion is that we for now ignore negative stuff at the
administrative level by defining only the
"permit-overrides-authorize-issuer" algorithm. Once we undestand that
simpler case, we can consider more complex ones.

Now to something completely different. Some other issues that still need
to be defined:

* We need to define what to do with obligations when policies are
combined at different levels of administration.

* As Tim already pointed out at the last focus group meeting, we need ot
define a new element in the request context which will hold the
issuer/administrative subject.

There are also a couple of issues that are perhaps not quite in the
scope of XACML. I am thinking about the relation to attributes.
Attributes matter for access control since we define policies in terms
of them. If we are to consider administration of access control in an
application, then we cannot really consider it in isolation without
considering administration of attributes. I think the delegation model
in the current proposal is good and is not affected by this issue, but
the use of it is affected by the relation to attributes. One important
such influence is the use of attributes in root policies. This in effect
delegates (in a different fashion) power to those who control the
attribute, in which case the PDP may want to approve all administration
of that attribute. This may or may not be an issue depending on how
distributed and decentralized the application is.

There is one issue with attributes that may be something for the XACML
TC to consider. Should we define any temporal semantics for attributes
with respect of delegation? Consider a regular access request. An access
permission says that a person that satisfies the attribute constraints
in the permission may access the resource. At the time of acceess, we
collect the attributes of the subject and compare them with the
constraints in the permission.

An adminstrative permission is a permission about the act of changing
policy. When we verify the right to issue a given policy, we will
compare the attributes of the issuer of the policy with the attributes
in the administrative permission. Now, the question is, when we look for
the attributes of the issuer, at what point in time should we do that?
At the time of the access request, or at the time when the policy was
issued?

If the administrative permission is the right to issue a policy, the
right was really exercised at the time the policy was issued, not when
the end user requests for access. On the other hand, it may difficult to
verify at what time a given policy was issued. We may want to leave this
for the application to define.