OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

[xacml] Policy combining and delegation

  • 1.  [xacml] Policy combining and delegation

    Posted 02-11-2005 08:40
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: [xacml] Policy combining and delegation


    During the focus group meeting there was a discussion about how 
    delegation would affect the combining algorithms. I will try to explain 
    my thoughts on that issue in this email.
    
    In the experimental delegation implementation I made, rule combining 
    happens the same way as in regular XACML. There is no need to change 
    this, since delegation is done at the policy level, that is, an 
    administrator will issue policies (or policy sets, though I haven't 
    tried that myself), not rules. This means all the rules in a policy are 
    defined by the same person, and that person, the issuer of the policy, 
    can specify which combining algorithm to use. He knows how he designed 
    the rules and how he wants conflicts to be resolved.
    
    Policy combining is affected in two ways. First, I used the public 
    extension points only, which limits what I can do. The problem is that 
    if a policy is not a "root policy", we need to verify the authority of 
    the issuer to issue a policy that would permit the access in question. 
    Before that verification is done, we don't know what the policy really 
    evaluates to. The way I implemented the verification is to return an 
    obligation to perform a repeated request to authorize the issuer. This 
    criples the policy combining algorithm since it does not have the 
    information to combine the policies. What I did is that I defined a new 
    policy combining algorithm which simply collects all the obligations 
    into a single result, and then a component external to the PDP will run 
    the repeated requests and combine the final results. This problem is 
    purely because I chose to use the public extension points only. If the 
    core of XACML would be extended with delegation, we could deal with this.
    
    The second problem with combining algorithms and delegation is more 
    fundamental. If you have a number of different people who have issued 
    policies which conflict, who of them gets priority? How do you define 
    that? Who defines it?
    
    Perhaps one way to do is to let the PDP "owner" define how "external" 
    policies are collected into policy sets and what combining algorithm to 
    use. Some combining algorithms may be nonsensical to use, for instance 
    if the order of the policies in the policy set is nondeterministic, but 
    there are probably some that make sense, for instance both deny and 
    permit override algorithms could be useful.
    
    What I have done so far does not support delegation of negative rights, 
    so I have not thought of different options for policy combining, but I 
    don't think delegation of negative rights would be a problem.
    
    I think that the ideas presented by Tim and Bill could prove to be very 
    useful for delegation. I haven't really thought it through, but I think 
    the generalization of the conclusion could be used to implement more 
    expressive combining algorithms, so you could probably define many more 
    ways to resolve conflicts between delegated policies than with the 
    current combining algorithms.
    
    /Erik
    
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]