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 <>
To: "'XACML TC'" <>
Date: Thu, 20 Nov 2003 17:36:30 -0800
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
