(Links to former posts that I refer to in this post: 1, 2, 3)

Hey, I ain’t no plumber. I think by now anyone who reads my blog is well aware of this.

Yet, I needed to act like one last month when I had to use WSE1.0 to encrypt some super secret data that was being sent out from a web service. I followed some samples because I didn’t *really* understand what I was doing and achieved my goal. WSE2 is not quite available for production which is why I had to use WSE1.0.

Now I am looking at WSE2 and trying to understand what’s new and improved about it.

One new thing is security. So I needed to go back to my original solution and dissect it and TRULY understand it so taht I could compare it to what I was about to learn in the new WSE.

Here is how to encrypt data in WSE1.0. Better take a very comfortable seat. This is not code, but an explanation. Don’t worry about memorizing this stuff, because my point is how complicated it is.

I encrypted the data using symmetric key encryption. Very complicated and for the most part followed some samples that I found. (see my previous posts for those references). It is all done through HTTPFiltering. If you haven’t used HTTPFiltering, what it does is grab a web call or a web response when it’s on it’s way by, and do something to it first then send it on it’s way. For example you can create a filter that says, “if you see a response going by, grab it and make everything upper case”. (This is probably close enough though not a technically perfect explanation.)

First you have to create an object that helps better introduce your web response to the HTTPFilter. It is a SoapContext — and in constructing this object you will define it as a ResponseContext. You are going to be attaching this soapcontext to your web service response and then it will get read by the HTTPFilter.

The super secret keys (byte arrays that you make up) are hard coded into the client code and into the web service. There are two keys, the key and something called an initial vector key which is also a byte array.

Then you create an algorithm class and attach those byte arrays to it through a “key” and an “IV” property. I happen to be using the cryptography class for doing TripleDES Encryption. There are others and they may not use keys in this way. I did not choose this type of encryption for any educated reason other than this is what the samples I was using leveraged.

Then you create an encryption key object that is based on this algorithm object.

Then you need to name this key object with a URI.

Then you take a deep breath. 🙂

Now you take the whole key that you just created and use it to construct a WSE object called an EncryptionData “element”.

Lastly, you add this new element to the collection of security elements that are part of the soapContext object that you created at the beginning.

Once this is all done, what happens is as the soap response is on it’s way out of the web server, it hits the httpfilter, the filter reads the context that was attached and inside of the context is an instruction to encrypt the soap response using the keys that you created.

Then there’s the client. Find, download and install the WSE Settings Tool.

Then, the biggest PIA. You need to manually modify the proxy class that is created when you make a reference in your project to the webservice. If you modify the webservice and update the reference you have to remember to first force your proxy to show the new code (right click on the reference file and run “custom tool”  that you get when you install the wse settings tool). Then you will see that the proxy changed back to the original reference which needs to be changed. (I’m not going into details, again, just explaining the drudgery).

In your client code, you need to create a decryption class and hard code your two super secret byte arrays and create a decryption object. When the soap message is returned from the web service, the proxy will recognize the soapcontext and go find your decrypting class and decrypt the data.

Now you see why a) not many people were using this and b) Microsoft needed to re-write this stuff!

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!