All,
our first Magma/Seaside just got live for beta testing. Currently we use a local connect and a single image. However I think we might need to switch to one image hosting a Magma Server and several seaside frontend images connecting to it. As all this will be hosted on hosted root servers I'm a bit concerned about security.
Is there any way to force the server to only accept connections with some kind of credentials? Otherwise (at least as far as I understood it) the server will happily allow any client which knows the correct port.
Any pointers?
CU,
Udo
Udo Schneider wrote:
Udo Schneider schrieb:
Any pointers?
Even a way to restrict the server to only accept (somhow authenticated) clients would help.
Any pointers?
CU,
Udo
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
I think that Magma doesn't have this functionality (yet). But you could work around the problem in the OS layer, that is, you can use a firewall that filters IP for you. At least this would let you work until magma can filter source IP from clients. BTW, the IP can be faked, without your server noticing it. The right way to filter clients it is using client certificates.
Cheers, Miguel Cobá
Miguel Enrique Cobá Martínez schrieb:
Thank for your help.
I think that Magma doesn't have this functionality (yet). But you could work around the problem in the OS layer, that is, you can use a firewall that filters IP for you. At least this would let you work until magma can filter source IP from clients.
That's what I'm doing right now. However we plan to seperate the seaside frontends from the magma backend(s). The current idea is to run the seaside frontends on dynamically allocated amazon EC2 instances - so we won't know the allowed IP. Maybe I have to patch our iptables script to include the EC2 instance IP dynamically.
BTW, the IP can be faked, without your server noticing it. The right way to filter clients it is using client certificates.
The word "security" seems to open a whole can of problems :-)
Thanks.
CU,
Udo
Hi Udo, I don't know what your security requirements are, but
- protection of sensitive information? - protection from modification of objects?
Given the end-to-end argument, these things can sometimes be handled well in the domain level. We did this for a commercial application I'm using, serialzing and encrypting sensitive objects into the persistent model. That way, even if the disk-packs get stolen (often we hear of "stolen laptops with personal information") is still secure.
Unfortunately, Magma does not provide its own authentication mechanism. I attempted a super-secure version of Magma a couple of years ago by way of integration of the KryptOn crypto facade. Unfortunately, after a year of working on it I got side-tracked to do the multi-attribute queries. Before I could return to the security, I went to C5 and got fairly demoralized from comments regarding the difficulty of implementing security. That, and other priorities put the security seriously on the back burner.
BUT, the issue is not dead by any means. The ultimate goal for Magma is to be able to run naked on the Net.
Until then, there are some simple password things that could be done to take Magma from "completely open" to at least an illusory level of security. But I'm not willing to put anything into the base that won't be a complete, water-tight, solution.
- Chris
On Mon, Feb 23, 2009 at 11:14 AM, Udo Schneider Udo.Schneider@homeaddress.de wrote:
Miguel Enrique Cobá Martínez schrieb:
Thank for your help.
I think that Magma doesn't have this functionality (yet). But you could work around the problem in the OS layer, that is, you can use a firewall that filters IP for you. At least this would let you work until magma can filter source IP from clients.
That's what I'm doing right now. However we plan to seperate the seaside frontends from the magma backend(s). The current idea is to run the seaside frontends on dynamically allocated amazon EC2 instances - so we won't know the allowed IP. Maybe I have to patch our iptables script to include the EC2 instance IP dynamically.
BTW, the IP can be faked, without your server noticing it. The right way to filter clients it is using client certificates.
The word "security" seems to open a whole can of problems :-)
Thanks.
CU,
Udo
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org