I'm developing an ASP.NET 2.0 web service that serves XML data from a database. Almost all data traffic is one-way, from server to client, and there is no user-specific data. All clients will receive the same data. But I only want approved clients to be able to consume the data. In this situation, what are the best options for encrypting the data produced by the web service?

  • I've looked at SSL, but I've been told by management to find another way, so that we can either avoid the hassle of setting up an SSL certificate on the site or implement both SSL and my solution.
  • SOAP encryption has been suggested, but I want to have good support for iOS clients, and there does not appear to be SOAP support built into the iOS SDK or available open-source.
  • Because no data is being modified server-side, and we have no user-specific data or user accounts, I don't think OAuth is necessary. It will become necessary in the future, but we'll cross that bridge when we come to it. Am I wrong here?
  • I've suggested encrypting the content of the XML data so that <Prop1>StringData</Prop1 becomes <Prop1>EncryptedGarbageHere</Prop1>, but I've been told that's not as secure an approach as SOAP encryption.

EDIT: In either case, I'm also planning on adding a sort of "password" parameter that is required by all WebMethods in the web service, and will be required of each unique client application.

  • Wait, you want transport layer security but you don't want to use Transport Layer Security? Commented Jun 1, 2011 at 22:23
  • I want my data protected, but setting up SSL is apparently a pain, so I've been told to find other options and find out how this is done elsewhere (i.e. banks) Commented Jun 1, 2011 at 22:40
  • 5
    @Mr. Jefferson: tell whoever made that ridiculous decision that the cost in programmer time to create and maintain your own encryption and key-management system which duplicates what SSL already does is orders of magnitude larger than the cost of buying a SSL certificate and learning how (or paying someone) to install it. Commented Jun 1, 2011 at 22:57
  • 6
    It's done elsewhere using SSL, which takes minutes to configure and costs less than $100 a year. Compare that to the man-weeks, unknown vulnerabilities and associated cost and risk of your NIH solution. Your managers are wrong, plain and simple. Commented Jun 1, 2011 at 23:04
  • 4
    Nothing happens at a bank without ssl . . . Commented Jun 2, 2011 at 2:32

3 Answers 3


You are going to want transport layer security -- SSL -- in any case. If for nothing else than to secure your login. Management is quite wrong-headed here; without SSL anything you do is pretty pointless unless you actually re-implement SSL. I'll add that legitimate SSL certs can be had for $50 or less a year.

As for the problem at hand, given you are stuck on 2.0 your options are limited. Frankly, the easiest thing would be to use a custom SOAP header to send an API key. You can then require and process the API key before processing the messaging.

All that said, if iOS is your key client, you should re-think your platform choices a bit -- why are you stuck on ASP.NET 2.0 Web Services? There really isn't a good reason to be stuck with tools that old in 2011.


From your edits and descriptions, you've got one big underlying problem -- lack of underlying resources to make this happen. Modern servers and SSL is relatively cheap, in the hundreds not thousands a year.

Getting past 2.0 should not be horribly hard -- anything newer can reference the 2.0 assemblies you've got on hand. If it has to stay 2.0, you can still do a few things. If you want to use a full-flavored stack, check out OpenRasta. If the service truly is read only, you can easily write your own service using custom IHttpHandler implementations. API key just becomes another GET parameter in either of those cases.

  • I want to avoid SOAP if possible, though. And is the concept of SOAP encryption useless if it's not already under SSL? My understanding of SOAP is that it's a fancier, more purposed XML structure. SOAP encryption just encrypts the meaningful data in the structure, as explained halfway down the page in the link I provided, under "Next comes the response:" Commented Jun 1, 2011 at 22:43
  • Also, I believe you mean "there really isn't a good reason to be so stuck in 2004", or whatever year ASP 2.0 came out in. And you're right, and I'd love to be using newer stuff if only for the cool new C# 3.0/3.5/4.0 language features, but that's the basis for the platform I'm building on top of. Commented Jun 1, 2011 at 22:46
  • Updated and tweaked per your comments . . . . Commented Jun 2, 2011 at 2:30
...I only want approved clients to be able to consume the data

This sounds more like an authentication problem than an encryption problem.

Give authorized clients unique access keys to embed in the web service URL; no key, no data.

  • You mean without also doing something like SSL? Requests are made via HTTP, so anyone can watch the traffic and see what parameters are being passed. If not, then see my edit to the question to clarify. Commented Jun 1, 2011 at 22:53
  • @Mr. Jefferson: yes - because if you're not willing to spend $50 on SSL then you clearly do not care about security. Note that if you use a secure connection and an authorization token, your problems are solved - without spending hours and hours coming up with your own encryption and key-management scheme. Commented Jun 1, 2011 at 22:56
  • The problem isn't as much the cost of buying the certificate as assigning the site a unique IP and the associated setup with that. Commented Jun 1, 2011 at 23:35
  • 2
    @Mr. Jefferson: you've got to be kidding. Unless you're using incredibly incompetent hosting services, that is a ten-minute change in the router and DNS settings. If that. Commented Jun 2, 2011 at 0:05

I only want approved clients to be able to consume the data.

This is an authentication issue. This means you want your clients to identify themselves to the server, so you can either have them use some sort of login (maybe a hashed license key instead of real username/password credentials), or some other sort of secret that only the approved clients have, such as an API key or certificate.

My recommendation is to switch to .NET 4 and use WCF with an API key.

An API key allows you to authenticate clients individually (or maybe just by release number). The video in the link gives an example of why you'd want an API key even if you have no login credentials.
With WCF, you have more options for message security.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.