[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Policy combining and delegation
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]