Re: [xacml] Policy combining and delegation

[Erik Rissanen <mirty@sics.se>]

Oh, I forgot to say that if someone issues a policy set, rather than a 
policy, then he can of course specify any policy combining algorithm for 
the policies he included himself in that policy set. (Though I have not 
implemented delegation of policy sets, so I have not tried it.) The 
problems show up only when you are to combine effects "issued" by 
different authorities. As long you are within a single delegated policy 
or policy set, you are fine since it is clear who specifies the algorithm.

/Erik


Erik Rissanen wrote:

> 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
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. 
>