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