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