MHonArc v2.5.0b2 -->
xacml message
[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]