[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Discussion of Issue 13
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]