Design guidelines for secure Java EE web applications and Seam

Question

I attend in process of designing Java EE web application. It consist of:

• backend module (EJB 3.0)
• 3 web modules (JSF)

Our application must be secure, so some colleagues claim that it must be splitted into two or more separate servers - backend in one server, webapps in other(s). In our case performance isn't a problem but this architecure demands using remote interfaces in EJB layer.

We are planning also to incorporate Seam to simplify development, but there is one drawback . So we miss out some really cool features of Seam eg - extended persistence context in SFSB

Does the use of an architecture with two or more separate servers/machines for each layer of Java EE web application is really a must in aspects of high security? I didn't find resources explaining pros and cons of this configuration. What are other project configuration options/security patterns that I should consider that facilitate using Seam? In others words should we stick with this architecture and add Seam as it is or apply another solution?

If it helps we can use Spring instead of EJB, but EJB is more preferable.

Answer 1

Here's a simple answer to you're question.... Is it more secure to have your data hop across 3 network connections (Web->Web server is 1, Web server ->remote EJB is 2, and remote EJB->DB is 3), or 2 network connections? The 2 network connection is inherently safer, since there is less exposure to hostile listening on the wire. If you're attacker is able to read the memory Java uses to scrape the data from your web server, you have far far bigger problems that a separate server just won't help with.