[Proposal] RuleDispatch for the Identity framework
Simon Belak
I am looking into using RuleDispatch via peak.security for Identity
framework (ticket #313). Unfortunately the two approaches seem to differ
quite substantially. I see 3 possibilities:
1) use peak.security for security modelling and keep Identity just as a
default implementation. This would be a backward-incompatible change.
Considering the way peak.security.context is constructed it would
probably be best to move all security modelling to either model.py or a
separate file (e.g. security.py).
2) retain identety.require() but use it to build peak.security.context
on the fly. peak.security would than be a middle-layer and Identity
offered as a default implementation.
3) just make peak.security an option.
---
To me the best course of action seems 1) + security.py.
References:
http://peak.telecommunity.com/DevCenter/SecurityRules
http://trac.turbogears.org/turbogears/wiki/IdentityManagement
Cheers,
Simon
Jeff Watkins
you're trying to accomplish with RuleDispatch (which is *really*
cool, by the way) with regard to security. I don't dispute that the
PEAK security code is *incredibly* powerful, but it is also rather
confusing -- at least to language newcomers like me and I suspect
many of the TurboGears target audience.
Can you give me a couple examples of functionality that Identity is
missing? Besides ownership testing, which is problematic but not
impossible using introspection.
Additionally, while the technique is different than that used in
PEAK, you can always create a new predicate for the Identity system.
--
Jeff Watkins
http://newburyportion.com/
In the USDA study [of the meat packing industry conducted in 1996]
78.6 percent of the ground beef contained microbes that are spread
primarily by fecal material. The medical literature on the causes of
food poisoning is full of euphemisms and dry scientific terms:
coliform levels, aerobic plate counts, sorbitol, MacConkey agar, and
so on. Behind them lies a simple explanation for why eating a
hamburger can now make you seriously ill: There is shit in the meat.
-- Eric Schlosser, Fast Food Nation
Simon Belak
like to investigate the possibility of using RuleDispatch.
To be honest, your current work (I do hope I did not come of as trying
to put it down too harshly. If I did, I am truly sorry.) covers well
over 90% of use-cases, I simply like generic functions (to put it
bluntly, I am just as biassed as you :)). It has to be said however that
some things could be solved more elegantly. Here peak.security shines.
Embedding it would also be appealing to all who are already using PEAK.
I am aware generic functions can be a bit confusing at times, but we can
always provide an additional layer covering most of the cases (see my
proposition #2) while retaining full power of generic functions.
Cheers,
Simon
Jeff Watkins
> Kevin mentioned on several occasions (see ticket #313) that he
> would like to investigate the possibility of using RuleDispatch.
Yup. And I'm keen to investigate using it. I just need to have some
use cases where adding RuleDispatch enables functionality that
doesn't already exist and which couldn't be added easily without
RuleDispatch.
> To be honest, your current work (I do hope I did not come of as
> trying to put it down too harshly. If I did, I am truly sorry.)
> covers well over 90% of use-cases,
No you didn't sound harsh at all. I'm just trying to get a grasp on
what's desired. I *really* want Identity to solve the majority of the
use cases, and if I'm missing some, I want to know. What exists now
is everything that leapt to mind when I was first writing it.
> I simply like generic functions (to put it bluntly, I am just as
> biassed as you :)).
I like generic functions too. I think they're cool. One of the things
I'm looking at is using generics to handle ownership. Because
ownership is *so* model dependant, it makes sense to have:
is_owner.when( 'isinstance(obj, MyObj) and identity.user in
obj.owners' )
Although it might be nice to discover a cleaner syntax for us mere
mortals.
> It has to be said however that some things could be solved more
> elegantly. Here peak.security shines.
Exactly. But what things? Which things need cleaning up? I can't tell
because I'm too close to the code.
--
Jeff Watkins
http://newburyportion.com/
"Advertising directed at children is inherently deceptive and
exploits children under eight years of age."
-- American Academy of Pediatrics
Kevin Dangoor
>
> Simon, first let me admit I'm biased, but I'm really not certain what
> you're trying to accomplish with RuleDispatch (which is *really*
> cool, by the way) with regard to security. I don't dispute that the
> PEAK security code is *incredibly* powerful, but it is also rather
> confusing -- at least to language newcomers like me and I suspect
> many of the TurboGears target audience.
The reason I'm looking at RuleDispatch and peak.security is as a way to provide
1) a path to handling the ownership question
2) a means to make identity more flexible without requiring completely
new IdentityProviders
That said, I'm 100% in agreement that the current identity API is
considerably easier than peak.security for a large chunk of
applications. My hope is to blend the flexibility of peak.security
with the ease of identity.
> Can you give me a couple examples of functionality that Identity is
> missing? Besides ownership testing, which is problematic but not
> impossible using introspection.
I'm actually not sure that introspection will be the way to handle
ownership. My guess is that the most reliable thing to do will be for
the controller method to directly ask the (in peak.security terms)
Context if the user is permitted to access that object.
There are a couple of things about switching to RuleDispatch:
1) the stuff in quotes is standard Python...
@identity.require("user.has_group('foo')")
2) ...which allows you to do more sophisticated checks
@identity.require("user.has_group('subscriber') and user.paid_in_full")
Using Contexts, you can have a variety of rules that succeed or, if
they fail, provide an appropriate message to the user about why they
can't do what they're trying to do.
I should note that I'm not trying to provide everything out-of-the-box
or solve all of the questions now. The key is that if RuleDispatch
does fit nicely here, I'd like to see its syntax show up *now*.
I'm also envisioning that identity.require *could* take a Context
object directly instead of a string, which provides a super simple
extension point for people when it comes to authorization: just define
your own context and use it wherever you need to.
I haven't figured out or run experiments in code to see how Contexts
get used in the identity.require(<some string>) case. RuleDispatch is
not very exciting when there's only one rule :)
But, I'm definitely not in favor of losing the simplicity that
identity.require has.
> Additionally, while the technique is different than that used in
> PEAK, you can always create a new predicate for the Identity system.
The thing that RuleDispatch does (and probably better than anything
else in Python) is evaluate rules (surprise!). It's super-efficient
and I think it's a superset of the predicate setup in functionality.
Simon Belak
>> It has to be said however that some things could be solved more
>> elegantly. Here peak.security shines.
>
> Exactly. But what things? Which things need cleaning up? I can't tell
> because I'm too close to the code.
>
1) Predicates make Identity essentially a DSL for Boolean algebra which
is already covered quite nicely in Python itself. Mixing infix and
prefix notations is not all that aesthetical either.
One possible solution (besides RuleDispatch) would be to make all
relations monads.
2) In most cases there tends to be just a few sets of rules applied to
many methods. The way Identity currently works this makes for a lot of
code multiplication and opens a new frontier for bugs.
3) If Paste and WSGI applications mixing gain a foothold in TG it would
be nice to have the security model decoupled as much as possible.
Ideally it would be a separate layer altogether. My gripe #2 becomes
even more pressing here as using Identity in current form means
spreading security declarations throughout not just methods but
applications.
Kevin Dangoor wrote:
> I'm also envisioning that identity.require *could* take a Context
> object directly instead of a string, which provides a super simple
> extension point for people when it comes to authorization: just define
> your own context and use it wherever you need to.
Context and optionally a binding for user, perm or subject. This way we
retain the flexibility of peak.security's loosely defined symbols.
Cheers,
Simon