There seems to be quite a few WSE extension projects out there. Some of them implement custom transports, some implement custom filters and some implement public specifications.

Perhaps we should consolidate our efforts and set up a project on a public server like the GotDotNet workspaces. Create a Genghis for WSE if you will.

Just a thought ;)

Matthew Lynn asked for the WSE compression filter code, and here it is.

My colleague Martin Valland and I wrote this code based on an idea we had for a compression specification for web services. This implementation as well as the SOAP extensions it relies upon is proprietary. As far as I know there is currently no publicly available specification that addresses this particular subject.

The code relies upon #ziplib for the compression algorithms.

This is a prototype implementation and it comes without warranty of any kind.

We have been doing a lot of WSE testing at work while developing our new integration infrastructure. As a part of this project we have built a filter for message level compression in WSE.

One of the interesting things we found out while performance testing the solution was the speed increase resulting from message compression. The system we are building transfers sensitive data across the internet and we are using X509 certificates for integrity and confidentiality. Naturally, we had to apply the compression before the security mechanisms were invoked, as compressing encrypted data isn’t efficient at all. However compressing xml data is very efficient; often resulting in 80% smaller message bodies.

Having a smaller message body means that the encryption and signing process has a lot less data to deal with, and this reduced the processing time significantly. We did of course consider that the smaller payload would increase transfer performance, but on our test-setup this was not a issue.

The bottom line is that our initial testing shows that the gzip compression algorithm is faster than the encryption and signing process used by WSE. This came as a surprise to us as signing involves hashing and the encryption implementation uses a block cipher, and neither of these should have performance issues with large amounts of data; at least not compared to a compression algorithm!

This topic requires a bit more research before I can reach a conclusion, but so far I am a bit surprised. On the other hand, the results we are seeing could be related to some other part of the process like the normalization algorithm.

Having fun ;)

Work continues on my little WSE project. Here is a more evolved piece of sample code...

           [WebMethod] [WseProfile("Default")] [WseX509Security] [WseCompression(CompressionMode.GZip)]
[WseMessageBodyValidator("MyMessage.xsd")] public void MySecureMethod(int x, int y)
{ ... } 
        

I’ve been playing around with some ideas for WSE and attributes lately. This is how my WSE enabled method looks right now. And before you start screaming about policy; there we’ll be some rationale coming.

           [WebMethod] [WseProfile(“Default”), WseX509Security] public
void MySecureMethod(int x, int y) { ... }
        

I read and hear that increased performance is one of the primary reasons for employing secure conversation instead of PKI and X509 certificates. Usually these statements are based upon the fact that PKI encryption is relatively slow. This becomes a problem when large amounts of data are involved because the encryption algorithm used with X509 certificates is not a block cipher.

I am not going to give an exhaustive explanation of how block ciphers work, but just note that they scale very well as it’s usually just the first block that is encrypted and then a chaining algorithm is applied to transform the next blocks based on the encrypted output of the first block. The asymmetric algorithm used by X509 certificates splits the data up into chunks of the maximum allowed size and then encrypts each one of them before chaining the encrypted blocks together. Moving back to the topic at hand I would like to shed some light on the statement about performance and secure conversation.

If you use an X509 certificate to encrypt a message using WSE a symmetric key is generated. This symmetric key is then used to encrypt the specified parts of the message. Finally, it is this session key that is encrypted with the X509 certificate. This means that the asymmetric PKI encryption is only used to encrypt a small key, and never the entire document. As a result, the scalability of the asymmetric PKI encryption isn’t really a big performance issue when used in this way.

There is an overhead involved in generating and encrypting a new symmetric key for each message, but how this affects the overall performance of your system depends upon your architecture and distribution. I would think it would be a non-issue for most internet-based applications.

There is of course also an overhead involved when initiating a secure conversation as trust must be validated and the session key must be generated and distributed. As a result, the amount of messages exchanged within each conversation becomes an important factor when deciding on the performance impact.

If you don’t need client authentication you may also use the secure conversation session key to ensure integrity, and that will shave some cycles off using X509 certificates for digital signatures.

There are in other words performance concerns when using either one of these security strategies, and which one is the fastest depends upon your architecture and usage patterns.

I have spent a lot time with WSE 2.0 in the last few weeks, and as both my code and my mindset moves from testing and research to building production quality systems, I am beginning to think about how hard it is to get the security choices right with WSE 2.0.

From a practical point of view, the move from plain ASP.NET Web Services to WSE and WS-Security is about moving from the SSL checkbox in IIS to a fairly imperative and challenging programming model in WSE 2.0. While the SSL-checkbox is inflexible and does not provide you with a lot of room for configuration, it is reasonably simple to get right. The WSE toolkit on the other hand provides you with a lot of room for mistakes and bad decisions. Throw a bit of WS-SecureConversation and WS-Trust into the mix and things really start to get interesting.

Even though WSE is an advanced toolkit for early adopters, it is still being marketed and generally perceived as the technology that will ensure secure web services. In the real world, it needs to be easy to build secure services. This is not because security is a simple concept to grasp, as it in fact is hugely complex, but because it is a basic requirement in any software project. We need to be practical and provide solutions that by default are as close to bulletproof as we can get them.

Looking at the samples in the WSE 2.0 TP distribution, I fail to find one that ensures integrity and confidentially for both the request and the response in a message exchange, but I have not done an exhaustive search. Given the affection that exists for copy and paste development, I am scared of what will travel from and to web services in the next couple of years.

I know that making the move to WSE is about a lot more than just migrating from SSL/ TLS to the WS-x family, but I think that it will be one of the most common scenarios.

My current thinking is that I would not recommend using WSE unless you have a very strong understanding of security and you have a dire need for the functionality it provides.

This entry seems a bit negative towards WSE, but I assure you that it is a great toolkit with a lot of good stuff in it. My concern is with whether or not the migration from SSL checkbox security to WSE-security is an evolution that will increase security or be a great source for error and confusion. Simple end-to-end samples together with practical prescriptive guidance may be a viable path towards solving this problem.

I am just in the beginning of forming my opinions on this topic; perhaps they will change.

I’ve been quiet lately, mostly because I have been very busy with work. These last couple of months has been intense and filled with SOAP, web services and the SOA paradigm.

After digging into Indigo and preparing for my overview presentation, I went strait on to designing and building a new version of our integration infrastructure. The solution relies heavily upon on WSE 2.0 and this has provided me with some interesting challenges. Naturally, it also borrows some concepts and ideas from Indigo.

Expect more details on my WSE 2.0 experience as I get both them and my mind organized.