1 Reply Latest reply on Feb 1, 2011 9:29 PM by pgmjsd

Embedded JBoss and running on a workstation

asacamano Jan 21, 2011 1:33 PM

Hi,

I'm working on a project were JBoss is being considered as something that will run on hardware which is not 100% trusted - i.e. the admin of that hardware might be interested in maliciously tinkering with or reverse engineering the JBoss distribution and the apps and configuration delivered with it.

As someone with only a very beginners understanding of Embedded JBoss, it seems that it might be a useful part of a larger package of security measures (AOT compilers, obfuscation, JVM Security Manager, code signing, dongles, virtualized OSes, etc.). The ability to run JBoss in our own classloader with some security contraints built-in seems quite helpful, for instance. I'm also imaginging the possibilty of packaging up the JBoss environment in a much tighter package - 1 big jar, including configuration files and deployed applications maybe.

I would be very grateful if the members of this group could:

1) Tell me if I'm completely missing the point of Embedded JBoss

2) Share their experience with similar scenarios

3) Share any thoughts they might have on ways to do what we're trying to do.

Thanks in advance,

Andrew

1. Embedded JBoss and running on a workstation

pgmjsd Feb 1, 2011 9:29 PM (in response to asacamano)
Andrew,

Given the current direction of JBoss Embedded, I'd say that it's unlikely to be packaged up as "one big jar".   The new design is basically a few jars that "launch" an unpacked JBoss distribution, and that expects the JBoss filesystem (./conf, ./server, ./lib, etc.).   As a JBoss AS user, I find that to be a good thing: my 'real' app server and my embedded app server (for unit tests) are basically the same thing.

Regarding running JBoss AS on an untrusted machine... JBoss AS is Open Source, so anyone can see the source code, but your app? That might be a different story.   IMHO...

Any obfuscation or other type of protection will be cracked given time, so deploying any sensitive or proprietary code is probably not the best idea.   Deploying an OSS app is basically a non-issue, since the source code is available anyway.
Typically people use JBoss to implement a software service (that's what my company does with it), so we run it in a trusted environment.   If you have sensitive or proprietary code, why not do it that way?
Running in a trusted an known environment makes development much easier because you don't have to deal with all kinds of strange configurations (except for browsers).

So, seems like you'd want to release whatever this is with an open source license and then figure out a way to deal with supporting different environments.
1 of 1 people found this helpful
Actions