[OGo-Developer] SOPE security

Helge Hess developer@opengroupware.org
Tue, 21 Nov 2006 22:01:25 +0100


Hi,

  "Security is hard."
     Jim Fulton.

On Nov 21, 2006, at 21:20, Wolfgang Sourdeau wrote:
> Is there any documentation about the SOPE security model? I am  
> wandering in sope.opengroupware.org/en/docs/ and can't find  
> anything besides the reference to SOPE security...

Well, the Zope texts are quite good. We do not implement everything  
they do (eg object based security is missing), but in general its  
designed after this:

http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Security.stx
http://www.zope.org/Documentation/Books/ZDG/current/Security.stx

Notably in current applications we do not make a lot of use of the  
SOPE security system. Eg ZideStore declares most stuff as <public>  
because the backend being accesses (OGo) already has its own security  
system.


> My questions in particular are related to the security declarations  
> in the product.plist files. What is the "protectedBy" for

Assign a permission to an operation or object. Eg:
   methods = {
     viewScheduler = {
       protectedBy = "View";
     };
   };

Says that the logged in user must have the 'View' permission to be  
able to invoke the 'viewScheduler' method.

> , wrt defaultAccess

Well, thats the default access :-) Private, public or protected. Used  
if the object is not protected otherwise.

> and defaultRoles?

To quote the Zope manual:
"There is an exception to the "developers should not try to define  
roles" rule inasmuch as Zope allows developers to assign "default  
roles" to a permission. This is primarily for the convenience of the  
Zope administrator, as default roles for a permission cause the Zope  
security machinery to provide a permission to a role by default when  
instances of a Product class are encountered during security  
operations. For example, if your Product defines a permission "Add  
Poll Objects", this permission may be associated with a set of  
default roles, perhaps "Manager". Default roles in Products should  
not be used against roles other than "Manager", "Anonymous", "Owner",  
and "Authenticated" (the four default Zope roles), as other roles are  
not guaranteed to exist in every Zope installation."


> Also, I would like you to confirm something regarding the security  
> mechanism:
> we have 4 entities: users, permissions, roles and objects.

The 'objects' somewhat split up. They have classes / superclass and  
SoMethods also can have permissions assigned.
In Zope methods can even run with special execution roles (very  
similiar to the 's' bit in Unix).

> Each users is assigned certain roles,

Yes.

> each roles has a set of one or more permissions

Yes.

> and each objects is assigned one or more roles, is that it?

Hm, no. Objects / "operations" / SoClasses are assigned permissions.  
Roles bring together users and permissions.

If a method like 'addEvent' runs, it asks the security system whether  
the current context has the 'add' permission assigned. To do that the  
security system looks whether the user belongs to a role which has  
the permission assigned.


> Or has each role specific permissions per objets?

No. But in Zope an object can have 'local roles'. And an object can  
have specific 'local' permissions (not really in SOPE yet).


> Could a username be a role?

No. But there are special builtin roles:
   'Anonymous'
   'Authenticated'
   'Owner'
which are dynamically assigned (I think Owner is not assigned, but  
object centric and maintained by the security system).


> Also, on a totally different subject, is the source code of your  
> snsd available under the GNU GPL?

No, at least not yet. But using RAM sessions doesn't scale well anyways.

Greets,
   Helge
-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/