Discussion of Issue 13

["Hal Lockhart" <hlockhar@bea.com>]

I added the following to the Issues List under Issue 13.

Because XACML policies can be quite complex and several policies may
apply to a given situation, users naturally desire tools to help them
understand and perhaps formally audit the effect of sets of XACML
policies. This is currently identified as Issue 13 (and perhaps 14).

However because of XACML's design, some features of this type are easy
to implement and others are hard. Often user's expectations in this area
have been unrealistic. The following analysis considers various kinds
features that analyze the effect of XACML policies and discusses their
implementation.

The easiest functionality for an XACML PDP to provide is a "what if"
capability. What this means is that the user specifies some set of
attributes that constitute a situation and the PDP reports if access is
allowed by current policies under that situation. Because an XACML PDP
bases its decisions entirely on the content of the Request Context, all
that is required is a user interface which allows the information to be
entered by the user.

Another feature that it is easy for an XACML PDP to provide is a list of
the policies which were used to make a decision. Implementing the
Reduction process which will be used in XACML 3.0 to evaluate chains of
administrative policies, actually requires this be done. But even an
XACML 2.0 PDP could easily report this information. It could even report
which rules were actually used in the evaluation. This information could
be provided while performing a "what if" evaluation or in the course of
normal access requests from a PEP. 

A limitation to this feature is that XACML PDPs are allowed to optimize
their processing by omitting the evaluation of policies and rules if it
can determine the Effect without them. A possible enhancement to the
XACML processing model would be a flag in the Request Context which
would require a PDP to evaluate all potentially applicable policies.
Presumably this would only be used for "what if" queries, but could also
be used to produce consistent Obligation results during normal access
requests.

Users have often asked for additional auditing capabilities in the form
of reverse queries. These are usually in the form of "What can Jack do?"
or "who can read this file?" Questions of this kind are difficult to
answer, given the XACML policy model. This is true for two different
kinds of reasons: the type of environments XACML can operate in and the
design of XACML itself.

First let us begin by noting that answering this kind of query requires
processing which is quite different from the policy evaluation process.
The capabilities discussed above only involve policy evaluation, plus
possibly keeping track of some additional information. Answering reverse
queries would at a minimum require implementing a whole new type of
processing engine.

However, the difficulties are much deeper than that. First, since XACML
Targets and Conditions are based on operations on Attributes, it is
necessary to do reverse queries against attributes. For example, if we
have a policy which applies to members of the HR department, we need to
find out which users that is. But many common sources of attribute info,
such as SAML and LDAP do not support reverse queries. They are quiet
willing to tell you the attributes of a user, but not everyone who has a
given attribute.

Also, truly large scale environments, like the Internet, make such
queries infeasible even if the primitive operations are available. By
the time all trusted sources have reported, the user has given up or the
answers have changed. It is also possible that there will be no known
way to contact all the authorities you trust. You may trust their
information if someone provides it, but not be able to fetch it. 

The second class of issues with reverse queries comes from the design of
XACML. XACML does not distinguish between attributes which uniquely
identify a Subject, Resource or Action and attributes which have the
same value for many. XACML does not have the notion of the "name" of a
thing, because its policies don't need it. They simply compare the
attribute values in the Request context with the values specified in the
policies. 

Therefore the idea of, for example, finding the all Subjects who have
the "auditor" role or all the documents which are classified "Top
Secret" is not even well defined in XACML. You and I might guess that an
attribute called SSN uniquely identifies a Subject and an attribute
called Job Title does not, but to XACML they are all the same. (we are
considering changing this slightly for 3.0, in the case of delegates,
but the general problem won't change.)

So if we can't do a reverse query, some people have suggested that
instead we define a partial evaluation of the applicable policies
corresponding to some set of attribute values. This may be possible, but
it raises a number of questions. The first is: how should the answer be
expressed? The obvious answer seems to be "in XACML." But how can we
decide if one form of policy is simpler than another and in particular,
what is the simplest form that we would reduce to? In other words, how
do we know of we have finished our partial evaluation?

Perhaps by producing a single policy. I believe, but cannot prove that
all possible combinations of Policy Sets, Policies and combining
algorithms can be represented as a single policy with the same effect.
If we assume this to be true, we could say that we will produce a single
policy, with potentially a large number of rules, that is equivalent to
all the policies that apply to the specified attribute values. One
problem is that I don't know how to calculate that deterministically.
Perhaps someone else can see what the algorithm is.

But an even more important problem is that I am not convinced that this
giant policy is going to be any clearer to the user in terms of its
effect than the multiple policies and policy sets it was produced from.
Remember that the purpose of this exercise was to understand the effect
of the policies in force (or soon to be in force). If the answer we get
is no clearer than what we started with, the exercise is pointless.

I don't know what the right answer is. I hope this will stimulate the
thinking of others, both in terms of what would be a useful thing for
XACML to do and how it might be done.

Hal