Hash: SHA1

Hi Bruno,

If you're using a central LDAP for all the instances you can restrict
the access from the different instances using either
LDAPUserGroupsFolder or CPSUserFolder.

Discrimination are done by LDAP branches (users or groups). If you can't
control the LDAP and thus the way the branches are designed, for
whatever reasons, then you can use CPSUserFolder and set the
discrimination on the UF within each instance by setting custom CPS
directories (which is what CPSUserFolder uses as proxy for
authentication sources).

To sum up it's a matter of configuration.

We'll be glad to discuss your use case on cps-users list.



bruno modulix wrote:
> Hello hi
> I have a little problem with aquisition and security. We have a project
> using multiple CPS instances (for those that don't know CPS, it's a CMF
> based groupware/CMS) running in the same Zope instance, and being
> siblings of each others [1]. One of these instances is the main entry
> point for the portal (I'll all it the 'portal'), the others are acting
> as workspaces for dedicated communities (I'll call them CPMs).
> Each CPS instance has its own UserFolder. All users exists in the
> portal's UserFolder, but only exists in some CPMs UserFolders. Now the
> problem is that, due to acquisition, a member existing in the Portal but
> not in a given CPM can gain access to this CPM by faking the url - ie:
> going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have
> a potential (err...) security hole here, that I would like to address ASAP.
> We've been thinking of using apache's rewrite rules, but since the
> customer will have the possibilitie to create new CPMs at will, this
> won't do. Idem for using subdomains, or anything implying the
> modification of apache conf.
> So we must fix the problem inside Zope itself. I searched the doc, this
> list's archive and the source code, and it seems that possible solutions
> involve playing with __bobo_traverse__ or
> __before_publishing_traverse__, but my (very naive) try didn't make it,
> so I'd really enjoy any hint and/or pointers about howtos, do's and
> don't, or any other resource concerning these hooks.
> Another thing I've been thinking of, reading BasicUserFolder's source,
> would be to subclass it and redefine the _isTop() method so users
> wouldn't been looked up for in a UserFolder placed in the context by
> acquisition, but I don't know enough about the whole mechanism to be
> sure it would'nt have unwanted side-effects and drawbacks.
> It's also very possible that I missed another simpler and better
> solution, so here again, any hint, pointer etc is *very* welcome.
> [1] don't tell me, I know this is far from the best possible
> architecture, but that's the only one that we could think of that would
> let us meet the deadline. CPS Workspaces did not offer enough
> functionalities to be used for CPMs, and we need a tight integration
> between the Portal and CPMs.

- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to