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

[Michiharu Kudoh <KUDO@jp.ibm.com>]

Basically, I see what you mean that "the Target concept is convenience of
administration and efficiency of evaluation". But I thought that the
administration of policies were out of scope of XACML, as Ernest said the
same in the last concall. Since the way of improving efficiency of policy
evaluation varies, I thought we should not limit the way of improving the
policy applicability checking. But I agree to the concall discussion that
the applicability element specifies the scope of the policy. Actually, when
we implemented the XACL processor, we used DTD name of the requesting XML
document as "Target Value", and used the "Target Mapping" that maps each
DTD to the applicable rule. That truly corresponds to the resource
classification.

Best regards,
Michiharu Kudo


From: Hal Lockhart <hal.lockhart@entegrity.com> on 2001/12/04 01:45

Please respond to Hal Lockhart <hal.lockhart@entegrity.com>

To:   Michiharu Kudoh/Japan/IBM@IBMJP, "Tim Moses <tim.moses"
cc:   xacml@lists.oasis-open.org
Subject:  [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