[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: > Maybe an other example will help: > > 1. tim tries to read a file abc > 2. pdp evaluates all available policies with (tim,abc,read) request context > 3. pdp will only consider those decisions that evaluated explicitly to > permit/deny. > 4. suppose there is only one policy that rendered permit, and this > policy was issued by frank. > 5. the next step will be for the pdp to see if this issuer frank has > permission to access the resource - if frank does not, he clearly > doesn't have the right to say anything about tim's access rights to that > resource. So, we have to take the original request context > (tim,abc,read) and substitute frank in place of tim: (frank,abc,read), > which includes both the original resource, action and the whole > environment. With this new request context, we can find out whether the > issuer frank who allowed tim read access to abc, is himself allowed to > read abc. > 6. if we evaluate all the policies with that new request context, and > yield a permit decision for frank from a policy issued by PDP, then > we've ended up at the root issuer and don't have to recurse further. hmmm, me thinks this could get weird: let's suppose in step 4 ten policies were returned, 5 permit, 5 deny. let's also assume that there is some sort of 'root' policy (set the wabac machine to the metapolicy discussion from the very first XACML TC meeting :o) that allows for this aggregation of policies to resolve to 'deny overrides'. the PDP must then looks at the 5 policies returning a deny and performs step 5 (reprocess) for each of these--BTW how do you know someone has the right to *deny*? further assuming that you figure out who can 'issue a deny', and none of the 5 issuers issuing the aforementioned decisions can do so, the PDP would then have to process the 5 permit decisions per step 5 above (reprocess). so far so good? that's 20 possible evaluations on 10 policies. in a world where you may have thousands of policies that speak to a specific resource (in a delegated topology that seems possible), it seems that this could get pretty ugly if policies that exist in the PDP have to be evaluated twice each. i would think that optimization of evaluation would be kinda tough, especially when policysets--which i would assume would have issuers (and may contain policysets)--are thrown into the mix. yeah, i know the latter point is an implementational gripe, but it seems like it is large enough to threaten operational viability. on the other hand, the issue of figuring out if someone can deny (without some sort of ancillary policy) seems to be a logic hole. since i have not signed up with the cult-of-haskell (yet) perhaps someone can help me out there. b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]