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

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

Hal - 
I had promoted the term "applicability", not because I felt it was 
preferable to your proposed term: "target", but because we needed a 
term for this concept, and I did not understand that "target" was 
intended to serve exactly this purpose.  Personally, I would be happy to 
switch to "target".

 

I 
agree with the points you make in this message.

 

I was, 
however, thinking that (to pick up your very final point) XML documents, to 
which these policies control access, would have fully qualified namespaces to 
identify their type.  Then the policy (even if it is attached) would 
"target" that namespace.  This approach, of course, means that 
the policy applies uniformly to all instances of the type.  We should 
probably debate the use of the reserved word 
"this".

 

All 
the best.  Tim.

 

-----------------------------------------
Tim Moses
Tel: 
613.270.3183

 

    
-----Original Message-----
From: Hal Lockhart 
    [mailto:]
Sent: Monday, December 03, 
    2001 11:45 AM
To: 'Michiharu Kudoh'; Tim Moses 
    <tim.moses
Cc: 
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