Is OData intended for use within Government and Financial envrionments? What security precautions do I need?

Question

At first brush, OData seems like it will only appeal to "open" databases, and would never be used in envrionments where security is needed, especially with financial or government clients.

Is this the correct perspective to have with the current version of OData/WCF? If not, can you share whatever I would need to change that perspective?

Update

Examples of current concerns include:

• Increased possibility of SQL Injection
• Additional Data Validation (complicating business logic)
• Unauthorized Access to data
• Increased ability to do a "raw dump" of data
  
  • by this I mean it is easier to use OData to get to HR data, then it is to screen-scrape a traditional ASP.net page

Update 2

Is it also possible for me to enforce business rules? For example a properly formatted SSN, Phone, or Zip. How about ensuring all fields are filled in?

Answer 1

Sure you can use it in government solution. OData is just a way of accessing data, it has nothing to do with making the information secure. You have to implement the security at the transport level (SSL) and not at the application level (provide login and password to application).

There are many ways to go about this. One example is if you are using SSL, you can force your client to provide a client certificate and have that do the authentication. Once the person has authentication, you can use your application to limit what they can see (maybe they can only see their client information, so all queries automatically limit the person to seeing that.)

Answer 2

oData is just a way to expose structured data through an open API. It does not requre any particular form of security; it's possible to have fully open datasets (like a wiki database) or world-readable-but-private-writeable (such as a database of votes by members of Congress, so anyone can read it but only you can update it). It also supports more complex security structures (such as a video rental store allowing customers to query only their own history).

Regarding your specific concerns:

• SQL injection is simply not possible if you're using the ADO.NET Data Services as your oData server. The incoming oData request is parsed and then passed to an IQueryable, which properly escapes all values.
• The business layer / data layer validation remains the same. oData just provides an API for the data layer (or business layer, if it looks databaseish).
• Unauthorized access to data isn't possible unless you allow it. The default for ADO.NET Data Services is to not allow any access (even read-only access), so that forces you to explicitly authorize all access.
• The "raw dump" scenario is exactly why oData is so useful! It's a protocol that allows efficient querying of data sources over the web, instead of depending on fragile screen scraping "solutions". If you don't want someone to get the information, don't publish it.

Right now (to my knowledge), ADO.NET Data Services is the only oData provider available, and it's secure by default. I suppose that someone else could write an oData provider that wasn't secure by default or allowed SQL injection, but that would be foolish.

Also, remember that oData is completely divorced from the concept of authentication. It's up to you to use whatever authentication makes sense for your API. There's a great recent series of blog posts from the WCF team that address how oData works with various forms of authentication.

Answer 3

What's your business case for using OData? OData primarily exists to expose your data in a platform agnostic manner... so that .NET, Java, Php, Python, REST, etc clients can all access your data. Is that your use-case?

Or are you trying to expose your data via a service layer (kind of an SOA approach) so that your clients (which you control) are better decoupled from your data sources. In that case, OData may not be the right solution. I looked at OData as part of a data service layer and decided it is too slow. I'm now looking at Devforce which implements service-based access for Entity Framework models (via their BOS service)... full CRUD operations including LINQ to service-hosted model.

Security is to you desired level is possible either view OData or via DevForce. Pick the correct data-remoting solution, then research the correct security implementation.