[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Negative Policies
Here is a reason why negative policies are generally avoided: the algebra for aggregating them is rarely understood and/or amazingly complex. If authorization is only governed by "positive" policies, it's easy to understand: if any of the policies allow it, then the requested action is authorized. Negative policies add several complications. First, they add a new concept: ordering. Look at the Apache documentation for .htaccess, for example. Second, a client can now gain privileges by omitting information, which is counter-intuitive. Imagine a cross-realm policy that says "everyone can, but john@foo cant". If John does an "anonymous login" to the local realm, he can do more than if he did an authenticated login from his "foo" realm. (That's an almost-contrived Kerberos-like example, but I hope it makes the point clear.) The third complication is that policies now need the concept of a default, either explicit in the policy or implicit in the processing. An all-positive policy that says "all lawyers can" has a clear default: if you're not a lawyer, you can't. A negative policy "fred can't" has a clear default: permission granted. Changing the default on the basis of the content doesn't seem like a good thing to do; it also raises the question "waht's the default for empty policy?" I appreciate the simplicity of letting operations type just say "fred cant," and in isolation there seems to be no reason to disallow that. The problem comes when you start to work out all the details, resulting in a system so complex that you scare off customers or (worse) leave them confused such that they're inadvertantly exposing resources they didn't intend to. I believe that's why relatively few authorization systems support negative rights. I'm new to the group, so I apologize if this is all old news. But I hope it's helpful. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC