Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell

[Frank Siebenlist <franks@mcs.anl.gov>]

Bill Parducci wrote:

> Frank Siebenlist wrote:
> 
>> In the presented model, anyone can can issue a "deny-policy", which 
>> becomes only valid if that person was issued a permit him/herself.
>>
>> In other words, having the right to access some resource gives me the 
>> right to delegate those rights to someone or to explicitly deny those 
>> rights of someone.
>> (I can think of schemes that would treat deny differently from permit, 
>> but I hope we can stay away from the associated additional 
>> complication...)
> 
> 
> ok, so if i can only READ a resource i can issue denies only to READ it?

Correct.

> then if i read your earlier proposal correctly, does that mean that if i 
> attempt to issue a deny on WRITE and READ to that resource, the policy 
> is discarded from the overall decision because i am not allowed to 
> 'issue a policy re:WRITE' (even though as part of the same policy i have 
> a rule re:READ')?

I don't believe so, because the delegation tree is build up of decisions and not 
policies. So if you someone come in with a request for the action read, the 
policies will be evaluated to match that action. If you issued a deny on read 
and write, that will yield a deny on a reqest for read. The policy that give you 
the read permit access will yield permit resulting in a overall deny. If a write 
request came in, then your policy will initially yield a deny on the write 
action, but the previous policy that delegated you the read action doesn't give 
you a permit on write and therefor yields NA, which also invalidates your 
initial deny on write in a NA.

Bill's policy for frank: {denyEffect if (action==read or action==write}
PDP's policy for bill:   {permitEffect if (action==read)}

if i come in with a read request the decisions combination will be:

<frank|D|bill><bill|P|PDP> => <frank|P|PDP>

if i come in with a write the decisions combination is:

<frank|D|bill><bill|N|PDP> => <frank|N|PDP>

> personally, i don't think we can stay away from schemes that don't 
> address an issuers explicit capabilities (e.g. 'frank can issue policies 
> on xyz of scope READ/WRITE/DELETE/CREATE').

I believe we have that capability in the model.

>> When you talk about a delegated topology of thousands, what kind of a 
>> scary use case do you have in mind?
> 
> 
> oh i dunno, let's pick some sort of multi-tiered sales approach (phone 
> cards) where you could have hundreds of individuals who have the ability 
> to grant access to a virtual phone card system from their website.  it 
> would seem that any time were you have a large number of entity pools (i 
> don't want to get into federation at this point ;o) where you can't 
> simply stick someone in a group to provide access, but have to treat 
> them independently this situation could arise.

We may have the same issue in the current xacml (or any authorization system), 
when the number of policy statements explode because you either need unique 
policies per subject or per resource. You normally throw in the towel and force 
the subjects or resources to keep their own policies with them (like data 
labeling) and try to find other abstraction mechanisms to keep the policy 
manageable (like matching clearance levels to labels).

It would become more difficult if we have thousands who feel it is important to 
say something about tim's access rights to file abc - i just hope that tim is 
not that important or that there only very, very few of him ;-)

So far, we have ignored DoS like attacks. What can you do if some joker decides 
to burrow you with thousands of his policy statements that will never contribute 
to any real permission but you will only find that out when you do the actual 
evaluations. That's maybe where a more restricted policy language could help 
where you can build-up policy trees in advance and detect policies that will 
never be able to contribute and can thus be discarded. We talked about that 
briefly during the call yesterday and Tim mentioned it in the minutes. Note that 
we may be able to leverage on wspl for this restricted language as it has a very 
  similar goal for combining policies.

Thanks for the scrutiny.

Regards, Frank.

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory