Split deployments and security
Ant
were hoping to use Seam, but it doesn't seem to be set up for running
a split deployment (i.e. web tier running on one server, ejb tier on
another).
The split deployment approach was recommended to us by our security
consultants, citing the 'defence in depth' argument: namely if the web
tier is compromised somehow, then there is still another tier before
the database layer. The data we deal with is highly confidential so
security is very important.
From my limited understanding, it seems that the split tier approach
was being suggested by Sun a few years back, but seems to have gone
out of fashion in the last few years, as the issues with remote
programming (DTO hell) and J2EE entity beans have become apparent. I
think we should go to single tier to simplify development but I need a
strong security case.
Does anyone in the group have an opinion on single / split
deployment,? Is the split tier a common approach? Anyone know of any
papers / discussion that support the single tier approach, especially
from a security perspective?
Any advice appreciated,
Ant
Steve Loughran
EJB has 'issues'; the whole distributed object idea is sort of
unfashonable, though of course it is still disguised as Web Services.
you could have a WS-* layer doing the work. Or you have a set of
servlets/reslets and have a second RESTy layer.
One issue is that regardless of how you split the layers, if you want
security, you need to lock down the communications, by adding distrust
of the layers in front. Theres no point having a web service or
session bean layer if that code constructs database operations through
unescaped string concatenation. Similarly, the database shouldn't give
the session bean layer admin rights to the database; it should be a
restricted user with its rights rolled back to only those that it
needs for its day to day work.
-steve
tom.g...@gmail.com
Here is my view:
Out of the box seam examples don't encourage layering your
application. They have EJB3 Session beans acting as action handlers
in your JSF page (doing HQL etc.). This is fine for small
applications and it does demonstrate a very feature rich application
with a small amount of code.
I think the sample booking app is under 10 classes.
My view on layering is that is important in more enterprise
applications. For example to allow other clients to connect to your
service tie (via WS or remoting). Also it promotes good separation of
concerns.
Regarding split deployment (front end servlet based web client <->
back end services) I don't really see the point.
If your worried about performance you just cluster the whole
enterprise app.
If your worried about security you just lock down your EJB3 service
layer with Role based access.
I'm not sure it's true that you can't have a split deployment seam
app.
I just don't see why you would want to go down that route.
Good debate though!
On 9 Nov, 14:21, "Steve Loughran" <steve.lough...@gmail.com> wrote:
Dave Patterson
This server side post covers some of the support for using remote
interfaces in the latest seam release.
http://www.theserverside.com/news/thread.tss?thread_id=47478#242261
It looks like this has been a bit of an afterthought but there is
clearly an audience for this kind of topology.
In general the tradeoff is this - is the perceived improvement in
security worth the performance and configuration/admin costs? Your
SLA, budget and some rigorous performance tests will give you part of
the answer.
At first sight it seems logical that a service layer on remote
hardware would add a layer of complexity that would help with security
(assuming Steve's observations about interface distrust are applied).
I wonder if exposing some of the finer grained aspects of the
application over the network could actually constitute a greater
security risk? (Do people configure a separate NIC on a secure local
network for EJB comms?)
BTW - We use weblogic with the apache plugin to redirect app requests.
You could present apache as your "web tier" thus meeting the concerns
of your consultants while keeping the application logic in one place.
I'll leave that one to your conscience.
Dave Patterson.