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

[Guido van Rossum]

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

Very cool indeed.

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

Hm, IMO too many permissions makes the screen unmanageable too, and
that hasn't stopped anybody... :-( / :-)

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

Where's the role here?  Oh, anonymous is a role, not a user.  I see.

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

Hm, but this isn't the product's responsibility.  Ken was talking
about a product twiddling the role-to-perm mapping.  How would the
product know what you wanted?

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

Why not?  I just figured out that roles are similar to Unix groups...

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

Yes!

--Guido van Rossum (home page: http://www.python.org/~guido/)