(add: as per this and this, I modified my webservice to return a plain old dataset in the encrypted soap header – as I would for any other dataset returned by a web service – rather than turning it into an xmldocument first. Actually, also check out this from Sean Wildermuth, which is what convinced me over a year ago that it is a-o-k to return datasets from webservices)
Well! That was educational!
I now have a web service that grabs a dataset of super-secret information from sql server, converts it to an xmldocument and returns it to my client as the body of an encypted Soap message. It’s possible to encrypt different pieces of the soap message. And I had to deal with that p.i.a. transformation of an xmldoc to an xmlnode on it’s way through the pipe. But at least I remembered that from the last time I encountered it!
My smart client retrieves this encrypted message (thanks to the last key of remembering to modify the web service proxy by replacing
Inherits System.Web.Services.Protocols.SoapHttpClientProtocol
with
Inherits Microsoft.Web.Services.WebServicesClientProtocol)
I was able to pull this part off with both Bill’s book and Jeannine’s article (see previous blog for details) close at hand.
Once I had the data safely in my client’s clutches I still had another task which was to persist the data for off-line use. Of course, if the data is sensitive enough to need to encrypt it on the way through the pipe, I didn’t want to just create a little xml file that could be opened up in notepad! So I used a System.Security.CryptoStream (and a little help from this article) to encrypt the data, yet again, along with WriteXML to persist the data. The application that needs the data offline then got a reverse engineering job to do a dataset readxml and decrypt the data.
Phew! I am whooped. Now on to WSE2 where I have been promised I’ll be hitting my head wondering why I wasted all of that time with this WSE solution. Though the true answer is that I needed to use it in production and the WSE2 tech preview is not licensed for production use. That’s why.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!