Running Management Interface on Separate HTTP Port
My company is commited to implementing Zope for use on the extranet, and I'm kind of leading this new endeavour. One thing I stumbled across today was the issue of SECURITY. The Zope web app server and accompanying Oracle database will be run off the same machine on the extranet, so there's no security issue with our itnranet there. However, the consultant from the firewall company recommended that we use different HTTP ports for the customer interface/application and the management interface. I couldn't find anything that could relate to that issue in the Zope documentation, and a search through egroups.com only showed some message from someone who thought the management screens could be shielded off by only allowing HTTPS, but that's a different solution. Does this mean it simply isn't possible (yet), or did I gloss over some obscure functionality that could pull it off for me? Roland Reumerman ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
Roland Reumerman wrote:
My company is commited to implementing Zope for use on the extranet, and I'm kind of leading this new endeavour. One thing I stumbled across today was the issue of SECURITY. The Zope web app server and accompanying Oracle database will be run off the same machine on the extranet, so there's no security issue with our itnranet there. However, the consultant from the firewall company recommended that we use different HTTP ports for the customer interface/application and the management interface.
I couldn't find anything that could relate to that issue in the Zope documentation, and a search through egroups.com only showed some message from someone who thought the management screens could be shielded off by only allowing HTTPS, but that's a different solution. Does this mean it simply isn't possible (yet), or did I gloss over some obscure functionality that could pull it off for me
Zope does not differentiate between managment methods and, say, DTML methods that are public (other than authenticating them against Zope's security system, of course). They are all just objects in an object space. I would suggest using Apache and rewrite rules to ensure that only those you know can get to /manage anything. Also, Apache introduces another process 'layer' between your Zope and the world; thus, there may be some yet unknown Apache buffer overflow bug, but that doesn't mean they've broken directly into your Zope (in fact, they've only won half the battle at that point...) also, Apache has years and years of millions of sites beating on it. It's pretty secure. -Michel
Michel Pelletier wrote:
Roland Reumerman wrote:
My company is commited to implementing Zope for use on the extranet, and I'm kind of leading this new endeavour. One thing I stumbled across today was the issue of SECURITY. The Zope web app server and accompanying Oracle database will be run off the same machine on the extranet, so there's no security issue with our itnranet there. However, the consultant from the firewall company recommended that we use different HTTP ports for the customer interface/application and the management interface.
I couldn't find anything that could relate to that issue in the Zope documentation, and a search through egroups.com only showed some message from someone who thought the management screens could be shielded off by only allowing HTTPS, but that's a different solution. Does this mean it simply isn't possible (yet), or did I gloss over some obscure functionality that could pull it off for me
Zope does not differentiate between managment methods and, say, DTML methods that are public (other than authenticating them against Zope's security system, of course). They are all just objects in an object space.
Putting management interface on a different port has the added benefit thet browser automatically sends different authentication for management interface and 'user' pages.
I would suggest using Apache and rewrite rules to ensure that only those you know can get to /manage anything. Also, Apache introduces another process 'layer' between your Zope and the world; thus, there may be some yet unknown Apache buffer overflow bug, but that doesn't mean they've broken directly into your Zope (in fact, they've only won half the battle at that point...) also, Apache has years and years of millions of sites beating on it. It's pretty secure.
I think that you can 1. set up rewrite rule that redirects anything with /manage at the end to a different port and set up a different rewrite-rule on a virtual host running on that port. You could actually use straight zope (usually on port 8080 for this) additionally (to be absolutely sure) you can 2. Use GUF (generic user folder) or something similar that lets in only peaple from the "management-enabled" port if they have the Manage priviege. ----------------- Hannu
On Fri, 25 Feb 2000, Hannu Krosing wrote:
Michel Pelletier wrote:
Zope does not differentiate between managment methods and, say, DTML methods that are public (other than authenticating them against Zope's security system, of course). They are all just objects in an object space.
Putting management interface on a different port has the added benefit thet browser automatically sends different authentication for management interface and 'user' pages.
And it has the disadvantage, IMO, that Zope not only does not make a distinction between management and non-management methods, it also does not make a distinction between managers and non-managers. Or, rather, management is distributed, subtree-specific, and finely tailorable. The only distinction it would be easy to make is between methods that start with "manage" and ones that don't, *in the URL*. But there are other ways to access management methods, under control of Zope's security mechanisms. Your security model gets a little muddy and ambiguous in that event, it seems to me. Personally, I don't think trying to shoehorn a split management/access interface on top of Zope's fine grained security model is a good idea. The nice thing about Open Source, though, is that if you want to take a hack at it, you can <grin>. --RDM
participants (4)
-
Hannu Krosing -
Michel Pelletier -
R. David Murray -
Roland Reumerman