views:

45

answers:

1

I have an internal web service that exposes what rate to pay for a given task. Currently there is a single service that exposes:

  • Currencies - Add, Edit, Delete, SelectById
  • Countries - Add, Edit, Delete, SelectById
  • Tasks - Add, Edit, Delete, SelectById
  • Rates - Add, Edit, Delete, SelectAll, SelectById - (*1) Search
  • Reference data (Currencies, Countries, Users, Tasks...) - SelectAll
  • Users - Add, Edit, Delete, SelectById

(*1) This just takes and executes SQL query (I know this is a SQL injection nightmare! I didn't write this)

I was asked to review the service before someone decides to expose it across our firewalls into the DMZ and even though they are telling me the firewall rules will prevent attack I am refusing to allow this service to be exposed.

The application that wants the information wants only read-only access to the data and I am going to suggest that we produce a facade that is much more secure (probably using WCF) that exposes only the required information and schedule a complete overhaul of the system.

My suggestion is to decompose the service into a series of specific interfaces for:

  • Currencies
  • Countries
  • Tasks
  • Rates
  • Users

However, given that I require only read-only data within the DMZ would it make sense to decompose each service into a read-only service contract and a writeable-service contrac, e.g. for currencies:

public interface ReadOnlyCurrencyService
{
    IEnumerable<Currency>GetAll();
    Currency GetById(int id);
}

public interface CurrencyService : ReadOnlyCurrencyService
{
    void Add(Currency currency);
    void Update(Currency currency);
    void Delete(Currency currency);
}

public class CurrencyServiceLAN : CurrencyService
{
}

That way we can expose only the read-only parts of the currency service as an endpoint across the DMZ-LAN boundary but using the same service expose the writeable parts of the service inside the LAN.

Just wondered if anyone had any thoughts/comments/different approaches

+1  A: 

Without knowing what the underlying data model looks like or how it's constructed, one suggestion I have is to perhaps consider WCF Data Services. If you're looking to build a series of CRUD and search services on top of your entity model, WCF-DS may be a useful approach.

Creating the read-only services is pretty straight-forward, as you would have to create a data context that exposes your entities as IQueryable's, which isn't too hard to roll on your own. If you're using the Entity Framework, it's much easier as that's taken care of for you. You could even create those IQueryable-exposed entities as one data service (.svc) and configure it such that those entities are only read-only.

You could create a second service that handles the updates (and the reads) for internal purposes. The updateable service would require you to implement IUpdateable, which is a bit more involved than implementing IQueryable (unless you're using the EF, then you get it for free - so to speak).

The nice thing I've found with WCF-DS is that the plumbing for the CRUD operations is in place for you, and you then get to more quicly focus on security and one-off service methods instead of dealing with basic CRUD code. Also, the data returned is in a standard format (OData) and it can returned as XML or JSON.

Overall, I've liked this framework and consider it for new CRUD-like projects. Please also note that I'm primarily using .NET 4.

Hopefully this perspective helps. Let me know if you have other questions. Good luck!

David Hoerster
Thanks for the response. Certainly WCF DS is useful for the simple CRUD operations that I have, will have to take a look at this and see whether it fits to the data model.
Ian Johnson