Security issues with calling web services from within Oracle?

Question

I'd like to use a trigger to initiate pushing data to a web service, so I thought we should call the web service from PL/SQL in a DBMS job, or perhaps create a .NET stored proc to call the service. Our DB Lead is concerned about security, since the standard model is for clients to call the database, and not for the database to function as a client.
Does this pose any security risk? Can you refer me to any best practices or articles on this?
Thanks in advance.
Edited by: Kit.net on Nov 9, 2010 11:28 AM

Answer 1

First, a trigger is there to for a single sole purpose - guaranteeing the integrity of the data and the transaction. It is not there to interact with external services and processes (like mail, web and other services). Doing that exposes the transaction to those other processes/services. The transaction can now fail. not because of a business rule validation, but because of a network error when the trigger accesses an external service. How on earth can a business transaction fail when the transaction is valid, but a the transaction's trigger hit an external access error!?
And what happens do that event you have fired off in the trigger, when the transaction is rolled back? How do you undo that event you have created in the trigger that was based on uncommitted data?
So using a trigger like this is simply stupid (and yes, I have seen it too often in practice with horrible results to sugarcoat such an idiotic approach).
As for calling a web service from the database, using the database as the client in such a case. This is not a security risk. This is not unusual. In fact, it is very common in my experience. We have a lot of databases, ranging from SE to EE and several RAC clusters. All of them function as a client at some stage during processing. Some use a db link - and as a client fire off a SQL via that db link to a database server to obtain data. Some use ftp and act as a ftp clients, transferring processed data (XML format) to a server. Some call web services to extract data from 3rd party systems to reconcile the differences between local data sets and 3rd party data sets..
This is common between server and server. I do not see anything unusual in the database server using another server (and acting as a client when it does). Security between servers should not be a major problem (in fact, it can easily be done in a very robust way using trusted and encrypted communication).
The problem occurs when a client connects to the server and client and server roles are swapped at some stage (like the server "writing" a file directly to the client's filesystem). This very seldom makes any sense. And this is where authentication and security become an issue.