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

[Tim Hoffman]

Hi

Just a few comments here.  I think using standard Unix permissions here 
(whilst is familiar to a lot of people) as an analog is probably a bit
misleading, acl's (access control lists) or even the NT security model
may be better analogs.

I have found the explosion of permissions has been a major problem for 

1. clarity in defining and understanding what you security setup is
trying to do.
2. difficulty in managing accurately.

example a recent CMF site we built has in the default security page
at the root of the portal in excess of 100 permissions. This is just
unmanageable. I need to about 8-10 roles to define sufficient level of
granularity to allow different designated groups of people to author
content in different areas of the site. This two combined means accurate
understanding of what is my security definition, is impactical to
manage.

I spent many years building and configuring firewalls with products like
Firewall-1 and SunScreen. The single biggest problem with these products
was the explosion of rules (analog here with permissions and roles) and
this meant it became very easy for people to make mistakes.

I like the ideas outlined here earlier with regard to local roles.

As mentioned earlier there are some obvious permissions (recurring
security patterns if you like) of view, view folder contents, create,
edit, delete, publish, ... which most people from a day to day point of
view need to interact with. Maybe products could have a standard way of
inquiry/requesting the permission definitions to use. Then there are
very specific Product or Service related permissions and for that matter
roles that are needed to enable and control specific funtionality. 

Possibly the registration of a new permission is actually seperate from
the Product registration. 

Products then requests certain permission definitions be assigned to it
from a security manager  tool. If a certain permissions didn't exist
then maybe that functionality is not available (ie no permission)

The site administrator could then organise permissions into views
ie general permissions, product based permissions etc..


Just some rambling thoughts.

Regards

Tim

On Tue, 2001-12-11 at 07:11, Guido van Rossum wrote:
> > 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/)
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev