Securing JBoss EJBs on a desktop?

[thetaoofphil]

Hi,

I am considering using JBoss to deploy an application that is fundamentally distributed across n hardware tiers, but will also have to be deployed for a significant number of customers in a desktop configuration. I have test driven JBoss on my desktop so I know that it will work. But I am concerned about security.

My understanding is that the EAR contains an EJB's desployment descriptor, which sets security policy for the EJB. Since the EAR can be edited with emacs (there's a posting around here on that!), theoretically someone could modify security it as long as they can write to the the file in the file system.

Also, the authentication mechanism configuration is done in jboss-service.xml. If someone could write to that file, couldn't he mess around with authentication (e.g., substitute his own authentication mechanism)?

It seems to me that security of both the EJB's descriptor and the jboss-service.xml file are entirely dependent on file-system security. In a pure n-tier situation this works fine because your client shouldn't be able to get to the file system. But if a server were deployed on a desktop, it lives in a filesystem to which the end-user has direct access.

Is this really a problem? Is there a way of ensuring that security settings cannot be changed by a user who has full access to the file system on which JBoss is deployed?

Thanks!

--Phil

[mlindhout]

If your desktop environment is NT/2000/Linux, you can set the file permission to readonly.

B.T.W. What kind of application is this, in that you deploy the EJB's in the client? This is a really 'fat' client.

Martijn

[thetaoofphil]

Hi Martijn,

> B.T.W. What kind of application is this, in that you
> deploy the EJB's in the client? This is a really
> 'fat' client.

Our situation is that we are building an application that we wish to deploy in several different configurations: as a traditional distributed n-tier application, as a desktop only application, and as as desktop application that is accessed by multiple users (i.e., same as a traditional n-tier application, but the middle and data tiers are housed on a desktop box, which also happens to have a client accessing the application).

I've been struggling with the question of whether J2EE is the right technology to use for this project. It seems to me that J2EE is fundamentally intended to be deployed on servers. Some specific concerns, besides those I already raised in this posting, are: Perhaps JBoss would require more processing power than could be provided by the typical desktop configuration. Also, perhaps there are peculiarities and idiosyncrasies in deploying a complex J2EE application that would make it hard to create a smooth experience for end-users configuring and installing a shrink-wrapped application on a desktop.
Indeed, I cannot find any precedent for building a shrink-wrapped desktop application (with a turn-key installation process) with J2EE.

I'm afraid to say that our alternative may be .NET.

Any suggestions you have would be greatly appreciated.

Many thanks!

--Phil

[j.hedin]

As far as I know there is no way to securing any application deployed on a file system that the user has write access to. The user can not only modify the EJB permissions but also the code. This is true given any technology. (You could imagine signed ears and the core JBoss secured though, but then you can as well secure the deploy directory as well). The securing must be in the next lower layer in your application. I think that what you really want is to install and deploy JBoss as a different user than the user working at the desktop. Easy with Unix. Windows I don't know (thats why we only run Unix servers).

If you look in the real world, there are many horrifying examples distributed systems with the access checks only in the client. These are by default hackable by the user of the client.

[juhalindfors]

You can deploy the applications from across the network. So when you distribute all those JBoss instances to client hosts, put your applications into a central server which you can secure from writes rather than deploying them from a local file system. Modify the jboss-service.xml to add the additional deploy URL.

[juhalindfors]

As for smooth configuration experience on client machines, netboot is also an excellent option (which downloads a preconfigured instance from the network to the user's machine).

CPU processing power: I run and often develop JBoss on my 800Mhz laptop. If the desktop machines have that much power it is enough.