OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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]