Guard Your Data Services Carefully

A common thing to do these days is to create data access web services directly on top of your databases to open up access to that data to other services and applications, essentially creating a data services layer for your SOA. I've even recommended such an approach before. While conceptually this may be a good idea, this also presents an increased security risk.

To be widely usable (or reusable), these data services tend to need to support a general querying interface. A lot of EII products will in fact let you create data services that will take XQuery to query the data source. This is in effect analogous to widely opening up a SQL interface into your database. There's a reason why direct connections to databases are not made widely available--either someone can issue malicious queries to the database or some inept developer can create some massive query that will bring the database to its knees.

Besides not widely opening up direct database connections, RDBMSes also have pretty fine-grained access control so that you can specify what users have what kind of access to specific tables and columns. The data services in your SOA will also need such fine-grained access control policies. In this case, they will be specifying access control on the specific operations and XML elements and attributes. The key is to be able to specify and enforce the policies down to the specific elements and attributes.

Ideally, this would be done through a tight integration between the service's policy enforcement point and the XQuery processor (assuming you're supporting XQuery on your data service) so that if your XQuery references attributes and elements you don't have access to, the query wouldn't even be processed. I don't know of any products that do this, but there are some other ways to do it.

Assuming the source of your data service is an RDBMS, you could set up an access control policy internal to the RDBMS that maps to the access control policy of the data service so that once the XQuery is translated to SQL and executed in the RDBMS you let the RDBMS's security mechanisms enforce the access control.

If maintaining two sets of mapped access control policies like this sounds like a pain in the ass, the other approach is to have a post processing step where you can strip out data from the XML using XSLT for the parts that the client does not have access to. With this approach, you need to make sure that you've designed the XML schema such that once you've stripped out those parts you still have a valid XML document. Also this approach may not be the most efficient--bringing back all the data as XML and then applying XSLT to filter stuff out. It would be much more efficient to do that in the RDBMS.

And then lastly, similar to how direct access to databases are not made widely available, you're going to have to be more restrictive about who you grant access to your data services. This will also prevent any Joe Schmoe developer in your enterprise from issuing some crazy XQuery that will bring down your data service and the database behind it. Such restrictiveness may be in direct conflict with one of your reasons for creating data services in the first place, but it's probably a necessary compromise.