How do I lock down a .net 4.0 WCF Data Service

I've had a WCF Data service published for about 2 months. It's 100% been hacked already. I even noticed the service published on twitter!

Luckily my site was under development and the user entity was only about 80 beta testers.

Still this is a pretty big problem. With the power of E.F. Navigation properties anyone can easily write a script to download all my user data and my valuable domain da开发者_高级运维ta that no-one else has. I want to provide non-authenticated access and do things like:

1. Limit what columns get exposed (e.g. a users emails)
2. Limit number of requests possible per day (e.g. 10 per request host address)
3. Be notified when someone is misusing the service
4. Limit the results set and expand options on different entity sets
5. Stuff I haven't yet thought about

Does this make sense or should I drop WCF Data Services - which in theory sounded great, but now that I've got experience with them I'm wondering if they are just good for development and not production (they're kind of fatter than I was expecting).

Thoughts that go beyond my knowledge and suggestions here will be greatly appreciated.

Also posting any links to thorough blog post examples or video presentation that cover ground would be excellent!

I think you need to implement some authentication. There is no other way I can think of to "lock down" a web service. This is one of the advantages of WCF -- it makes implementing complex authentication easy.

On my WCF service, I require a UserContext object, simply comprised of two strings, username and password.

Every method on the service requires that context, and if I haven't added the username/password to the database, it denies the request.

This also makes it simple to track who is abusing the service, as you will have their username/password tied to every request.

You should also run it over SSL so other users' credentials will not be easily compromised.

1 - WCF Data Services currently doesn't allow you to easily filter columns on per request basis. You could have two EF models (one "public", and one "private") and expose them as two services. The public one accessible to anybody, the private one behind full auth.

2 - This you will have to implement yourself. But for this to work you need some way to identify the user. So it's pretty close to authentication (Even if it doesn't require password or something like that). There's a series of posts about auth over WCF Data Services here: http://blogs.msdn.com/b/astoriateam/archive/tags/authentication/

3 - If you can identify the user as per #2, you can for example count the number or frequence or requests he/she makes and setup a notification based on that. Again the techniques used for auth should provide you the right hooks.

4 - This is reasonably simple. WCF Data Service allows you to set hard limit on the size of the response (DataServiceConfiguration.MaxResultsPerCollection) or a soft limit, which means paging. Paging is usually better, since it limits the size of a single response but still allows clients to get all the data with multiple requests. This can be done through DataServiceConfiguration.SetEntitySetPageSize. The exand behavior can be limited by usage of DataServiceConfiguration.MaxExpandCount and MaxExpandDepth properties.

Some other possible techniques to use

• Query interceptors (http://msdn.microsoft.com/en-us/library/dd744842.aspx) - this allows you to filter rows on per request bases. Typically used to limit rows based on the user making the request (note that this only allows you to filter rows, not columns).

• Service operations - if you define a service operation which returns IQueryable the client can still compose queries on top of it, but it gives you the ability to filter the data before the query is applied. Or you can make certain pieces of information accessible only through service operations (not as easy to use and not queryable, but it gives you full control). (http://msdn.microsoft.com/en-us/library/cc668788.aspx)