[Zope3-dev] Initial thoughts on the Zope3 security framework

[Martijn Faassen]

Ken Manheimer wrote:
> On Mon, 10 Dec 2001, Guido van Rossum wrote:
[snip]
> > Yes.  Unfortunately that screen suffers from too many checkboxes and
> > not enough information.  But I believe that's a well-known fact. :-)
> 
> Yes!
> 
> In fact, i believe that the things we're discussing here begin to
> approach the real issues behind that clutter.  The questions are not
> about presenting the myriad choices in a palatable way, but rather,
> they're about rationalizing the system so fewer, more intuitive (or at
> least, more self evident) choices are offered.

Very much agreed. That's why good use cases are so important. I offered
one involving authoring rights previously in the thread.

My view on this seems to be slightly different from things like the CMF,
where I believe there's a user folder where users can create and manage
their objects, and then the objects are gathered through the catalog and
presented using catalog queries.

I think of sites more as trees of documents (for instance structured
in some publication, like a book with chapters, say), with some users
having local roles to edit some areas of the tree (may be multiple branches).
I may want to give users permissions (or take them away), for things like
reading and writing and accessing for certain branches of the tree. Sometimes
I want to do this for groups of users. I don't think roles work here; 
I want to, say, give the same authoring role to one group of users in one
place, and to another group in another place. (for document in the above
you can also read 'content object').

[snip]
> Permissions correspond to authority for specific actions in an object
> - it exposes a policy handle on the actions.  This handle enables both
> product developers and site administrators to dictate which roles can
> do which actions, by adjusting the mappings of permissions to roles.
> 
> My read is that, since the permissions expose product-specific actions,
> they need to be unique, in as much as the actions are unique.  When
> viewed with respect to a product where they pertain, they're not so
> overwhelming.

Perhaps then an UI should allow different options; group permissions per
product, group them per operation (add, change, delete, etc).

[snip]
> I'm not sure.  One possibility that makes some sense to me is for zope
> to provide a more canonical collection of roles to build on.  Product
> implementers and site administrators would then have a predictable,
> shared range of things to target - aiming the functionality, on the
> developer side, and policy, on the adminstrator side, at that more
> clearly defined set.  This set could still be extensible, for those
> occasions when something truly new is truly needed, but people would
> want to create new ones only with good reason, because they'd be
> sacrificing the generality of the canonical ones.

[more on this]

This is a very interesting line of thinking. I think we should flesh this
out further. What would be canonical roles Zope would support out of the
box? Let's call them 'core roles', just like we're now not saying 'core
services'. :)

Regards,

Martijn