views:

120

answers:

3

We’ve got a back office CRM application that exposes some of the data in a public ASP.NET site. Currently the ASP.NET site sits on top of a separate cut down version of the back office database (we call this the web database). Daily synchronisation routines keep the databases up-to-date (hosted in the back office). The problem is that the synchronisation logic is very complex and time consuming to change. I was wondering whether using a SOAP service could simply things? The ASP.NET web pages would call the SOAP service which in tern would do the database calls. There would be no need for a separate web database or synchronisation routines. My main concern with the SOAP approach is security because the SOAP service would be exposed to the internet.

Should we stick with our current architecture? Or would the SOAP approach be an improvement?

A: 

The short answer is yes, web service calls would be better and would remove the need for synchronization.

The long answer is that you need to understand the technology available for you in terms of web services. I would highly recommend looking into WCF which will allow you to do exactly what you want to do and also you will be able to only expose your services to the ASP.NET web server and not to the entire internet.

Andrew Hare
hythlodayr
If the web server is broken into then a SOAP call is going to be the least of your worries.
Andrew Hare
It depends. The DMZ and LAN networks are (or should be) segregated by another firewall, with data only allowed to be PUSHED from the LAN to the DMZ. This means even if the firewall is broken into, I can't send and create a connection from the DMZ Web Server to the LAN. The firewall, correctly configured, should prevent that and largely shield the LAN DBMS from the outside. But once you expose a SOAP method and allow a request to go through, you're effectively allowing the outside world to affect the LAN DBMS.
hythlodayr
Sorry, I meant "...this means even if the DMZ webserver is broken into..." and not "...the firewall is broken into...".
hythlodayr
I guess that is why the most secure computer is the unplugged one :)
Andrew Hare
Security is hard and makes everyday life harder. But still, relaxing the architecture's security to make the development team's life easier is the wrong move in my opinion.
hythlodayr
Very true but I would contend that using a secured messaging system (like WCF) is not a relaxation of architectural security.
Andrew Hare
WCF can guarantee authentication--I suppose--and prevent man-in-the-middle attacks, but that's not enough. First, a messaging system won't help you to filter the subset of data that's allowed. It just shifts the logic from the webdb build to a different framework. Second, exposing a database--even indirectly--means the outside world can affect it; with the potential to slow-down or even crash the DBMS server(s). This doesn't even have to be malicious. A separate DMZ DB neatly consolidates these issues into one problem, imho.
hythlodayr
I guess I am a bit confused - are you saying that the database should not have *any* link to the outside world? I think a DMZ for the webserver is a good idea in addition to a WCF solution. I don't however think that completely severing the database from the outside world makes sense.
Andrew Hare
If it can be helped, no, because some (or many) business units depend on the database irrespective of the the web app. Unless I've misunderstood, the data in the webdb is a snapshot of the backoffice database and so there doesn't seem to be a particular need to expose the "real" DB. If synchronization goes both ways, then I agree it doesn't make sense to keep the webdb.
hythlodayr
A: 

There would be no security problem. Simply use one of the secure bindings, like wsHttpBinding.

John Saunders
A: 

I'd look at making the web database build process more maintainable

Since security is obviously a concern, this means you need to add logic to limit the types of data & requests and that logic has to live SOMEWHERE.

hythlodayr