[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]