Exposing EJB's externally

[AlistairMonkeyFinger]

Hi,

i'm looking at security issues when exposing our internal web start app (which communicates with EJB's on an app server) to external clients over the net. My concern is that i don't want to expose the whole application server to the outside world but rather have another layer which would contain just an application proxy. In this way the external client could connect to our internal exposed app proxy which would in turn communicate with the real EJB's on the internal (secure) app server.

So, does this seem like a sensible / possible ? What is the proper way to do this ? Is it possible to put the EJB interfaces file on a different server to the bean file or do i have to write my own proxy ?

Thanks for any advice you may have


Alistair

 

[sedj]

If you implement the "protected" EJBs as local objects, then you can have some remote EJBs which act as the proxy between the web and your business logic.

Are you using EJB1.1 or 2.0?

 

[AlistairMonkeyFinger]

Currently using EJB1.1 (using the Oracle OC4J server).

So basically i set up another EJB server on my public server and have all the methods point to the protected EJB's on my private server ? Sounds good. I was hoping that maybe that there was a way i could just publish a remote interface to the beans on the public server but i don't know enough yet about distributing EJBs.

Thanks

Alistair

 

[sedj]

Yes, this is one solution, but I have to say, it seems somewhat overkill, and will I expect, be extremely expensive in terms of memory footprint and CPU time. If you were running EJB2.0, then you could have all your EJBs as local ones on the LAN server, and then have a select few methods for your DMZ server as remote EJB. But, if you are using a remote EJB to communicate with another remote EJB - this seems a bit daft. The problem with remote EJBs is that every single lookup , and data communication, must be run over the RMI protocol which is really, really expensive to use interms of memory and time. Local EJBs don't use RMI because they all run, and can only be accessed from the same EJB container.

I would think carefully about what security issues you are worried about, and what, in reality EJB really compomises if you access your main EJBs using the remote interface from your DMZ web server. All EJBs running on EJB1.1 use RMI as their communication protocol, which is a lot tighter, and has much less security issues than, say http. If you are really worried about EJB security, then why not talk to your System's team about tying the RMI/EJB comm ports tightly ...

 

[AlistairMonkeyFinger]

Sedj,

thanks for you reply, very useful. The main thought behind running proxy EJB's on the DMZ is that the DMZ could be used as a general DMZ for multiple different applications wether they be Java based or otherwise. In this way we have a single entry point and the DMZ is only interested in security and not application processing, then the individual application servers do the bulk of the work. I have had a chat with the systems guys as and they suggested locking down the DMZ to only allow access through specifc ports, we are also thinking of only allowing access from specific host IP's (this isn't a publicly available app but rather something we may sell to a small number of licensed users).

If we were only exposing one application then i think i would put the EJB's directly on the DMZ server. I see your points though, and i am very worried about the performance hit when a client has to go through 2 EJB's servers and associated RMI lookups just to get a bit of data. Maybe i should do some experiments and see how much of a hit there is. Using EJB1.1 can EJBs not comminicate with other remote EJBs - do i need to use EJB2.0 to do this ?

Thanks

Alistair

 

[sedj]

In 1.1, remote EJBs can communicate with other remote EJBs fine. But with EJB2.0, you can expose a few "proxy" remote EJBs which would talk to the much less expensive local EJBs which would do the business logic. But, if you are using a bought EJB container, it can often be very expensive to upgrade to EJB2.0 ...

Now, how about this as a compromise solution :

DMZ - This captures your requests, and sends them via HTTP to ...

... PROXY BOX - which as some servlets listening for requests from the DMZ - which, then implements the client calls to your EJB container ....

... EJB BOX - which does the daat processing, and sends the data back to PROXY BOX - which then fires the data back over HTTP to the DMZ.

Because you are missing out the loop of another EJB container, you may see considerable savings ...