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


bill parducci wrote:

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

In the presented model, anyone can can issue a "deny-policy", which becomes only 
valid if that person was issued a permit him/herself.

In other words, having the right to access some resource gives me the right to 
delegate those rights to someone or to explicitly deny those rights of someone.
(I can think of schemes that would treat deny differently from permit, but I 
hope we can stay away from the associated additional complication...)


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

Somehow, i believe or hope (or pray ;-) that the explosion of individuals who 
all want to state something about tim's right to read file abc is fairly 
"limited"... and would reflect the great majority of use cases that we will face.

When you talk about a delegated topology of thousands, what kind of a scary use 
case do you have in mind?

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

As stated above: i can only explicitly deny tim the right to read abc, if and 
only if I myself have been granted the explicit permission to read abc. The 
latter yields either by a direct decision of the root issuer, or by a decision 
chain of only permit decisions that end at the root issuer (and doesn't violate 
any maximum delegation depth policies along the way)

Furthermore, if i have been explicitly denied the right to read abc, then no one 
should care whether i state that tim should be denied or permitted to read abc: 
my policy should evaluate to a NotApplicable.

I hope that this truth table holds for all the different scenarios that we can 
think off, and that it makes sense from an administrator's point of view.

And about that cult-of-haskell, i believe there is space enough for all of you 
to join our happy crowd,... world peace, ...solved world hunger...;-)

Regards, Frank.


-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]