Hi Paul, David:
Thanks much for this further clarification.
Please do not think I'm not denigrating the implementation in any way.
I want to clearly articulate the alternatives to anyone who asks. And,
many people have asked.
Thanks again.
Have a great day.
Ruth
On 1/29/12 2:34 AM, David E Jones wrote:
Paul is correct, the multi-tenant stuff has nothing to do with code
deployment and tenants don't have access to code. If you use OFBiz in a
multi-tenant mode all tenants will be running on the same code base.
Whoever is managing that code base could write tenant-aware code so that
it only operates for one or more tenants, but that would not be the
tenant setting it up, it would be the group who controls the central
code base.
The confusion in your question, Ruth, seemed to be the the multi-tenant
functionality somehow gives each tenant the ability to add code, and it
does not.
-David
Paul Foxworthy wrote:
Hi Ruth,
Your bank does not provide you with your own personal mainframe and your own
personal database. Your bank balance is in a row in a table with other
customers' balances above and below, which you should not be able to
discover. We've been living with those risks for decades.
Of course, an OFBiz user with permissions to log on to OFBiz and use its
services should not have the rights to modify a classpath or upload a Groovy
script. An OFBiz user should not have write permission on anything that is
executable. That applies to single-tenant as well as multi-tenant
situations. It applies to web applications in general, not just OFBiz, not
just Java. If such an exploit were ever found, I would be willing to bet
that a single-tenant OFBiz would be vulnerable as much as a multi-tenant
OFBiz.
Any OFBiz site that is public-facing (for example, for e-commerce) might
have visitors who are hostile to the owner and seeking to exploit a security
flaw to do damage. That applies to single-tenant as well as multi-tenant
situations.
Multi-tenancy should not greatly increase the risk of these or other
exploits. You're running pretty well the same code, it's just a matter of
what database you're connected to.
So I don't see multi-tenant as a totally new or unique situation. It's a
difference of degree, not kind.
Cheers
Paul Foxworthy
Ruth Hoffman-2 wrote
Hans, Pierre and several others have been kind enough to outline the
OFBiz multi-tenant value proposition.
I appreciate this primarily because I can't even count the number of
times prospective OFBiz users have asked me about it. Now, with this
background information, I feel comfortable articulating the marketing
value proposition.
What I still have great angst about, is the security side of
multi-tenancy. Perhaps someone can clarify or answer this basic question:
What is to stop a hacker or otherwise malicious tenant from writing a
Groovy script (or Java program that is inserted on the classpath when
the system is rebooted) that acts as a "trojan horse"? For example, how
can you stop a savvy tenant from adding a program (or, I could even see
hacking the Mini-lang since all it is - is interpreted XML statements)
that monitors (JVM) memory and captures shopping cart objects or
usernames and passwords of the other tenants?
Really, I'd like to endorse multi-tenant implementations. But I am still
left with this one - very significant - security question.
Anyone care to respond? Am I missing something here?
Regards,
Ruth Hoffman
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Multi-tenant-Security-tp4336437p4337693.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
