Navigation

Search

Categories

On this page

WCF Compression Filter
WSE: Another Compression Filters Update!
WS-Addressing makes its way to W3C
WSE: Compression Filters Update
WSE and Plumbwork Orange
Consolidating some WSE efforts
WSE: Compression Filters
WSE: Compression, Security and Performance
WSE and Attributes Evolved
WSE and Attributes
WSE, Secure Conversation and Performance
WSE and the Next Generation of Security
Work, WSE and Indigo

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 83
This Year: 0
This Month: 0
This Week: 0
Comments: 20

Sign In

# Wednesday, 19 April 2006
WCF Compression Filter
Wednesday, 19 April 2006 20:48:04 UTC ( Indigo | Tools | WSE )

Some time back a coworker and I released a sample compression filter for WSE 2.0 nicknamed “WS-Compression”, this sample was later enhanced and finally converted to a WSE 3.0 compliant filter.

As it turns it has further evolved into a WCF compression filter available from this blog post.

Interesting how things work out!

Comments [0] | | # 
# Thursday, 16 September 2004
WSE: Another Compression Filters Update!
Thursday, 16 September 2004 19:55:39 UTC ( Security | Tools | WSE )

It is great to see that someone has a taken an interest in the WSE compression filters I’ve been working on. Rodolfo Finochietti has added several new features to the code base.

  • Compress attachments
  • More algorithms (Deflate, Zip)
  • Compression level (set through compression context)
  • Threshold. Compresses according to the minimum message size (body size plus all attachments size)
  • Several other improvements and code cleaning.

    This is really exciting news. Great work Rodolfo!

    You find a list of download links here, or you can download it directly from this link.

  • Comments [0] | | # 
    # Tuesday, 10 August 2004
    WS-Addressing makes its way to W3C
    Tuesday, 10 August 2004 20:23:12 UTC ( Architecture | Indigo | Security | WSE )

    WS-Addressing, a vital piece of XML Web Services infrastructure, has just been submitted to the W3C.

    With WS-Security being an official OASIS standard, and WS-Addressing entering the W3C standardization process, we may soon be looking at the first stable set of advanced web services infrastructure.

    These two specifications form the foundation of the Microsoft Web Services Enhancements toolkit's functionality. Perhaps we will soon say goodbye to backwards incompatibility and short support lifecycles in this particular area.

    As always, it is great fun to follow the advances.

    Comments [0] | | # 
    # Wednesday, 28 July 2004
    WSE: Compression Filters Update
    Wednesday, 28 July 2004 18:21:46 UTC ( Tools | WSE )

    I released some sample code for a WSE compression filter a few months back, and I have recently updated the code to be more in tune with the look and feel of the WSE extension model.

    Since the initial release, I have submitted the code to the Plumbwork Orange project on GotDotNet. If you are looking for the most up-to-date version then that is definitely the place you would want to look. I have also made a snapshot of just the compression code available for download here.

    Enjoy.

    This SOAP compression extension is an implementation of an idea by Martin Valland and me, and it is in no way an official specification controlled by a standards body.

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

    Comments [0] | | # 
    # Saturday, 10 July 2004
    WSE and Plumbwork Orange
    Saturday, 10 July 2004 08:31:29 UTC ( WSE )

    For those of you using the Microsoft Web Services Enhancements 2.0 or my WSE “WS-Compression” filters it is time to look at some very interesting developments in that area.

    Over the last few months, I have been participation in a GotDotNet project aimed to provide free implementations of important WSE based infrastructure. You will find everything from WS-protocol implementations to helper classes, examples of WSE extensibility features and prototypes if some interesting ideas

    With strong WSE personalities like John Bristowe and Christian Weyer heading up the project this is definitely something that carries a lot of potential.

    Drop by the project workspace at GotDotNet!

    Comments [0] | | # 
    # Friday, 05 March 2004
    Consolidating some WSE efforts
    Friday, 05 March 2004 22:54:47 UTC ( WSE )

    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 ;)

    Comments [0] | | # 
    # Wednesday, 03 March 2004
    WSE: Compression Filters
    Wednesday, 03 March 2004 19:08:59 UTC ( Tools | WSE )

    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.

    Comments [0] | | # 
    # Sunday, 15 February 2004
    WSE: Compression, Security and Performance
    Sunday, 15 February 2004 20:16:33 UTC ( Security | WSE )

    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 ;)

    Comments [0] | | # 
    # Tuesday, 10 February 2004
    WSE and Attributes Evolved
    Tuesday, 10 February 2004 17:48:26 UTC ( WSE )

    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)
    {
      ...
    }
    
    Comments [0] | | # 
    # Tuesday, 27 January 2004
    WSE and Attributes
    Tuesday, 27 January 2004 21:15:53 UTC ( WSE )

    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)
    {
       ...
    }
    Comments [0] | | # 
    # Tuesday, 13 January 2004
    WSE, Secure Conversation and Performance
    Tuesday, 13 January 2004 15:04:42 UTC ( Security | WSE )

    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.

    Comments [0] | | # 
    # Wednesday, 31 December 2003
    WSE and the Next Generation of Security
    Wednesday, 31 December 2003 01:38:20 UTC ( Security | WSE )

    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.

    Comments [0] | | # 
    Work, WSE and Indigo
    Wednesday, 31 December 2003 00:16:37 UTC ( General | WSE )

    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.

    Comments [0] | | #