DataPower does not support NTLM (NT Lan Manager) Microsoft protocol (but it does support its successor Kerberos). Long ago I did start to work on enabling DataPower to access an NTLM secured web page. Find more information on this, and why I will not publish ntlm.xsl at the bottom of this posting.
Since DataPower did not support NTLM, adding support for that was only possible by implementing it in stylesheets.
NTLM algorithm required "md4", and "md5 hashing", as well as "des in ecb mode" (Electronic codebook, encryption).
DataPower does supports md5 hashing (http://www.w3.org/2001/04/xmldsig-more#md5), and it supports "des in cbc mode" (Cipher-block chaining, more secure).
So md4 hashing and des in ecb mode needed to be implemented as basis. Both algorithms do a lot of transformations on bit-level. So the implementations md4.xsl and des.xsl make use of function library hsw.xsl providing those bit-level functions in XSLT (as long 0/1 strings) as well as from/to binary conversion functions.
des.xsl and even more md4.xsl make use of DataPower extension functions. But I wanted both to be executable on other XSLT 1.0(+EXSLT) processors. The one I used for making that sure is Saxon 6.5.5 (yes, a very backlevel version, but the last XSLT 1.0 Saxon XSLT processor). Therefore I had to implement the needed DataPower extension functions in stylesheets (DataPower will use much more performant firmware implementations, and the others the stylesheet implementations).
hsw.xsl may provide the one or other useful function for your work, even if you do not need md4.xsl/des.xsl. md4.xsl and des.xsl might give some ideas on what can be done in XSLT which normally cannot (more than 2000 lines of XSLT in total). All files can be found under:
The nice thing with md4 spec http://tools.ietf.org/html/rfc1320 is that it does not only provide a specification of the hashing algorithm. In addtion it does provide a small test suite, as well as a complete implementation in C(!). In the stylesheet you can find a comment with "gdb" output (from a C implementation debug session) I did use for comparison while implementing md4.xsl. My implementation is restricted to "less than 56 byte" length strings, which may be even less characters (UTF-8 encoding), and can be enhanced easily.
Here you can see sample output as well as testsuite execution (on DataPower t1-t0 will output execution time in "ms"):
$ java -jar ~/Desktop/saxon6-5-5/saxon.jar dummy.xml md4.xsl
test 1 passed
test 2 passed
test 3 passed
test 4 passed
test 5 passed
And here is http://www.stamm-wilbrandt.de/datapower/functions/md4.xsl pretty-printed:
des in ecb mode
Sample (and algorithm) taken from "The DES Algorithm Illustrated": http://orlingrabbe.com/des.htm.
I did prepublish a standalone demo version of des.xsl while answering a forum thread in this developerWorks posting. I really like the "Stylesheet tracing" output by the DES sample execution, you can find here, a 7.2MB HTML page of 35175 lines debug output .
Here you can see sample output (on DataPower t1-t0 will output execution time in "ms"):
$ java -jar ~/Desktop/saxon6-5-5/saxon.jar dummy.xml des.xsl
The last line demonstrates that DES on 56 bit values (without the 8 parity bits) as required by NTLM works, too.
And here is http://www.stamm-wilbrandt.de/datapower/functions/des.xsl pretty-printed:
hsw.xsl function library
The first group of "hsw" prefixed functions are those used by md4.xsl and des.xsl. Folloing that are 6 "dp" prefixed functions as implementation for Non-DataPower XSLT processors. Especially having dp:encode(_,'base-64) and dp:radix-convert() may be useful in off-box stylesheet development if needed (eg. with Saxon 6.5.5). Finally a big group of functions needed to implement the DataPower extension functions in a stylesheet follows. Interesting is hsw:codepoint() needed to implement hsw:encode(), and definitely the many functions needed to implement dp:radix-convert() outside of DataPower.
Here you can see sample output:
$ java -jar ~/Desktop/saxon6-5-5/saxon.jar dummy.xml hsw.xsl
The only difference between DataPower and Saxon execution is this:
E282AC | 00
The reason is, that '€' is unicode character 0x20AC above 0x07FF, the implementation limit for hsw:codepoint() (which can be easily increased). Therefore "0" is returned, and "dp:radix-convert(dp:encode(.,'base-64'),64,16)" does return "00" on Saxon because dp:encode() makes use of hsw:codepoint().
On DataPower the firmware version of dp:encode() will be used, returning the correct result (hexadecimal UTF-8 code of '€').
And here is http://www.stamm-wilbrandt.de/datapower/functions/hsw.xsl pretty-printed:
First I started to implement NTLM based on "NTLM Authentication Scheme for HTTP" webpage:
Later I did realize, that Microsoft was forced to publish a big bunch of its specifications in 2007 by US government and European Union.
In 2010 Microsoft Microsoft no longer recommended NTLM in applications.
My implementation had to do several calls on a persistant connection, by <dp:url-open>s. But each execution of <dp:url-open> did choose its own new outgoing local port, avoiding persistent connections. I did overcome this by accessing the NTLM secured backend through a TCP Proxy service on 127.0.0.1. While this worked, it only allowed me to complete the handshake and retrieve one secured webpage from a Windows XP IIS webserver with NTLM enforced. And that not really reliably.
So given Microsoft says "don't use", and the problems I experianced, there will be no ntlm.xsl posting from me.
But all in all it was fun to make it access at least one secured page, and having to develop hsw/des/md4 stylesheets. And some of the functions can be used for other applications as well.