Saturday, May 26, 2012

Wcf.js message level signature? Check.


This is a very exciting moment for Wcf.js. It now supports one of the WS-Security most common scenarios - x.509 digital signatures. This is the first WS-Security implementation ever in javascript to support this. This implementation relies on xml-crypto on which I told you last time.

Look at any of the following Wcf bindings:

Assume only signatures are used (no encryption):

Then a soap request would look like this:

You can now interoperate with such services from javascript using Wcf.js with this code:

Note that a pem formatted certificate needs to be used. Wcf likes pfx formats more, so check out the instructions here on how to do the conversion.

You should also be aware that Wcf.js by default does no validate incoming signatures from the server. If you wish to validate them check out the sample here.


What's next? get this blog rss updates or register for mail updates!

Sunday, May 20, 2012

Xml-Crypto: An Xml digital signature library for Node.js


Get xml-crypto on github

Node.js does not always have the right libraries for Xml operations. When such libraries exist they are not always cross platform (read: work on windows). I've just published xml-crypto, the first xml digital signature library for node. As a bonus this library is written in pure javascript so it is cross platform.

What is Xml Digital signature?
There's a tl;dr version here. The essence is that dig-sig allows to protect content from unauthorized modification by telling us who created that content and if anyone had altered it since. Xml dig-sig is a special flavour which has some interesting implementation aspects.

A typical xml signature looks like this:

Installing Xml-Crypto

Install with npm:

npm install xml-crypto

A pre requisite it to have openssl installed and its /bin to be on the system path. I used version 1.0.1c but it should work on older versions too.

Signing an xml document

Use this code:

The result wil be:


sig.getSignedXml() returns the original xml document with the signature pushed as the last child of the root node (as above). This assumes you are not signing the root node but only sub node(s) otherwise this is not valid. If you do sign the root node call sig.getSignatureXml() to get just the signature part and sig.getOriginalXmlWithIds() to get the original xml with Id attributes added on relevant elements (required for validation).

Verifying a signed document

You can use any dom parser you want in your code (or none, depending on your usage). This sample uses xmldom so you should install it first:

npm install xmldom

Then run:


The xml-crypto api requires you to supply it separately the xml signature ("<Signature>...</Signature>", in loadSignature) and the signed xml (in checkSignature). The signed xml may or may not contain the signature in it, but you are still required to supply the signature separately.

Supported Algorithms

The first release always uses the following algorithems:

  • Exclusive Canonicalization
  • SHA1 digests
  • RSA-SHA1 signature algorithm

    you are able to extend xml-crypto with further algorithms. I will author a post about it soon.

    Key formats

    You need to use .pem formatted certificates for both signing and validation. If you have pfx x.509 certificates there's an easy way to convert them to pem. I will author a post about this soon.

    The code

    Get xml-crypto on github


    What's next? get this blog rss updates or register for mail updates!
  • Saturday, May 5, 2012

    How to fix Wcf cache of dynamic Wsdls


    One of the least used Wcf extension points is IWsdlExportExtension. This extension allows to customize the wsdl document which Wcf emits. Since you rarely want to do that, this extension is not commonly used. When it is already used it is usually in the context of flattening the wsdl. A different use case I have recently seen is to push dynamic content into the wsdl. More specifically a user was trying to generate xsd schemas from a live database table and to put it to the wsdl so clients would always get the latest schema. The Wcf service itself was treating the request as Xml anyway so it did not care for such changes. The requirement was for the wsdl to reflect the latest db changes at any time. Our problem was that once the wsdl was generated for the first time it would not be regenerated. This resulted in a stale schema.

    This is how we created the wsdl exporter:

    When we run this service and open the wsdl we get this:

    When we refresh the wsdl after a few seconds we still get this:

    This is not a browser or proxy cache. Wcf does not recreate the wsdl - which can also be seen by putting a breakpoint (which is only called once) on the exporter.

    This behavior makes since when you consider the case where there is no importer extension - then the wsdl is generated based on the data contract assembly, and as long as that assembly does not change the wsdl will not also. However we have chose to put dynamic logic in ExportEndpoint method so that default behavior did not work well for us.

    One way to fix that is to use a message inspector to update the wsdl before it is sent to the client. In this case IWsdlExportExtension is not required at all. This approach is described here.
    An alternative could be to build a Wcf rest endpoint in the same service to act as a proxy to the real wsdl.


    What's next? get this blog rss updates or register for mail updates!

    Tweets of the week: It's DevOps Borat


    Borat likes DevOps:

    Soap / Rest / Wsdl still a hot topic:


    What's next? get this blog rss updates or register for mail updates!