xacml — archive

[Bill Parducci <bill.parducci@overxeer.com>]

 MHonArc v2.5.0b2 -->






















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








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




From: bill parducci <bill.parducci@overxeer.com>
To: "'XACML TC'" <xacml@lists.oasis-open.org>
Date: Fri, 21 Nov 2003 13:30:46 -0800






Frank Siebenlist wrote:

> 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>

hmmm, maybe i didn't explain this correctly. lemme try this, how would 
you handle this policy combination (from the issuer viability decision):

<policy issuer=bill>
  <rule>
   if the sun is up deny frank create on uri:/ABC/
  </rule>
  <rule>
   if the moon is up deny frank read on uri:/ABC/XYZ
  </rule>
</policy>

<policy issue=sue>
  <rule>
   if it is thursday deny bill read on uri:/ABC/XYZ
  </rule>
</policy>

it is thursday, both the sun and moon are out, frank tries to rename 
(recreate) uri:/ABC/XYZ. i read this to mean that the PDP must evaluate 
this as one policy four times:

can frank read uri:/ABC/XYZ
can frank create uri:/ABC/XYZ'
can bill read uri:/ABC/XYZ (implied authority derived from sue's policy)
can bill create uri:/ABC/XYZ'(ditto)

> 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).

yes and no. what i am suggesting is that at the very least we experience 
a doubling of evaluation effort over the current model and i fear that 
once the model is extended to policysets (they will have issuers as 
well, correct?), etc. we may face combinatorial explosion in the number 
of evaluations.

b









References:

RE: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell
From: Tim Moses <tim.moses@entrust.com>
Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell
From: Frank Siebenlist <franks@mcs.anl.gov>
Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell
From: bill parducci <bill.parducci@overxeer.com>
Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell
From: Frank Siebenlist <franks@mcs.anl.gov>
Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell
From: Bill Parducci <bill.parducci@overxeer.com>
Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell
From: Frank Siebenlist <franks@mcs.anl.gov>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]