[xacml] Principals in Applicability - was RE: [xacml] Version 0.7

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: [xacml] Principals in Applicability - was RE: [xacml] Version 0.7

Michiharu wrote:
> Line 131-136 - Are resource classification and the requested
> action enough
> to identify the applicable policy? I agree that in most cases
> the resource
> classification and the requested action are used. But there
> is the case
> that the applicable policies are classified by subject attribute, for
> example, the policy for US citizens and the policy for not US
> citizens. In
> that case, there may be no need for specifying any resource
> classification.
> Thus , my suggestion is to add something like
> "principalClassification" to
> the "applicability" element and changes minOccurs attribute
> to "0" for all
> element under "applicability".

I do not believe this is a good idea.

First terminology. A long time ago, I wanted to call this thing we are talking about the Policy Target. This was not accepted, for reasons I never understood and we are now using Tim's term "Applicability" which seems extremely cumbersome to me.

However, whichever term is used, there are actually two concepts:

1) the actual runtime values which are obtained from the request. e.g. http://www.example.com/index.html & GET

2) a mapping function that specifies the set of applicabilities (targets) to which a given rule applies. I assume this mapping function will be something like a wildcard, regular expression or simple list (or combination of these).

I propose to call these the Target Values and the Target Mapping. If people prefer, we can call the the Applicability Values and the Applicability Mapping.

Now on to Michiharu's proposal. First let us observer that the decision of what goes into the Target Mapping has no impact whatsoever on the ability to express policies in XACML. Anything not in the Target can be referenced in the pre-conditions. In fact we could eliminate the Target notion entirely and still express all possible policies.

The only reason for the Target concept is convenience of administration and efficiency of evaluation. If we had no target, we would have to evaluate all policies on every request, in order determine if the access should be allowed.

My assumption about the world is that principals can use their identity in the course of accessing resources located all around the network. In contrast, resources are physically instantiated at particular locations. The PDPs that know about the policies controlling access to specific resources will usually be located "near" those resources. The individuals who administer policies are likely to be responsible for protecting a set of resources that are physically grouped together. In cases where the resources move around the network, e.g. XML documents, the proposed scheme is to have the applicable policies move with them, which leads to exactly the same result -- physical propinquity between the policy and the resource.

Therefore, it makes sense for the Target to consist of only items directly relating to Resources, such as the requested name of the resource, the requested action and other attributes of the resource. Then these related policies can be physically grouped so as to make administering them more convenient and the policy applicability step much more efficient because it is easy to know where to look to find all the policies that apply to a given request. In contrast, if policies were associed with the subject, they might logically be located anywhere in the network (world).

In fact, even if all the policies for an security domain were centralized, they would still be localized in the sense that each security domain most likely represents resources in physical proximity. There is no chance that there will be a single Global policy store.

I have also argued that the Target Mapping function must be restricted to be much simpler than the nested boolean logic allowed for in rule predicates. The reason for this is to make the policy applicability step very fast and possibly implementable by code that is much simpler than a PDP. I suspect when we generate rules about principals, we will want to allow for the more generalized processing as proposed by Tim and seperately by Bill.

Therefore I suggest that we limit the Target (Applicability) to items related to resources, because:

1. It is not needed to create policies about principals.
2. It interferes with the ability to efficiently administer policies and to perform the applicability step.
3. It may actually restrict our ability to create complex rules about principals.

-------------------------------------------------

Point 3 raises a new ISSUE I had not thought about. Should it be possible to create rule predicates containing the same items as the Target Values?

This is required if we feel that we need the full generality of logic to deal with these items. The problems created include:

1. User confusion. It will be possible to specify the same thing in two places, which people will find unintuitive.

2. Inconsistent rules. It will be fairly easy to create a rule which can never evaluate to TRUE, by having some predicate that contradicts the Target Mapping, but this may not be that obvious from looking at the rule.

3. Special provision will have to be made for indexical reference. For example, it is my understanding that when an XML document carries its own policy with it, the resource will not be a file name, but by implication will refer to the associated document. (We will have to do this or else invent a globally unique file naming scheme and prohibit renaming.) If we also allow predicates, we will at least need some kind of reserved word like "this" to refer to the associated document.

Hal