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

[Martijn Faassen]

Guido van Rossum wrote:
> > There's a benefit in having common role names across a site, so that
> > someone can be assigned a role high up to get privileges accorded
> > that role within many different contexts.  A prime example is the
> > "manager" role.
> 
> Hm, everybody always seems to use the manager as a prime example of
> the userfulness of roles.  Since in practice the manager role is
> almost omnipotent (as I found out when I wanted to create a PSF Board
> Wiki that the PSF webmaster couldn't read), I'm not sure that it's
> such a great example.

I have a site where there is an 'author' role. This is a
site-wide role, and people with the role can use an authoring tool
to change the content of web pages, and add new documents as well. They
can't do anything else (well, that'd be a security problem).

Even though the author role is global, people are only assigned the
author role locally (in some folders). They can only use their
authoring abilities in those areas.

Is that a better example?

[snip]
> Also it suggests that maybe it's too hard to create new roles -- just as it is
> too easy to create new permissions...

I think the permission space definitely needs to be more structured.
Perhaps it would help if objects can have 'create/delete' and 'change'
permissions created for them automatically.

With roles..currently you don't create many different roles in a site,
as that would become completely unmanageable. This is definitely in part
a UI issue; the management screens just don't support many different
roles. I don't know if it's a UI issue completely, however.

But this whole area could definitely use some thought. We need more
use cases.
 
> > Role-to-permission mappings associate the privileges with the roles,
> > and are generally twiddled programatically by the product across its
> > instances.  Role-to-account mappings - using local roles - are
> > adjusted by the product as role-assignments shift within the
> > instance.
> 
> Is it common (or even possible) for the role-to-permission mapping to
> differ for two instances of the same class (not counting subclasses)?

Hm, yes. Imagine for instance that I want most of my site viewable by
anonymous, but some areas should be closed for anonymous. I can then
remove the 'view' permission from anonymous in the folder I want to
be closed. In other folders this is however not the case.

Note that this is unwieldy and hard to manage, especially because there
are *so many* permissions. If permissions were somehow sensibily grouped
it might help, but perhaps there's a better solution. You can of course
add 'twiddle programmatically' systems to objects as well to make this
easier. Does the CMF have a framework for this? We could definitely do
with somekind of framework. Common types of permissions people think in
are 'read' and 'write' for instance ('authors should be able to write
here', 'anonymous should only be able to read here', 'anonymous can't
read here, but people authenticated as employees (this could be a group
instead of a role..this is also unclear) can')

> "Twiddled programatically" sounds like this is done at run-time.  I
> would hope that in practice this is part of a class definition or
> something (which in Python *is* runtime, but doesn't always feels like
> it), and products don't typically engage in changing the mappings
> dynamically?

How else do you close a certain section of your site for view or edit
for a set of users? If we had concept of a 'group of users' that might help;
right now you can do that with roles but that doesn't scale too well..

I think the important thing now is to come up with a number of good use cases.
 
Regards,

Martijn