Truth in SOA

Sys-Con has just put up a link to Joshua Painter's presentation on Enterprise SOA and governance that was given at SOA World 2008.

The video is interesting in that it highlights Intel's SOA Expressway product in terms of the Enterprise Service Router concept, which tries to consolidate islands of integration with scalable software rather than a plethora of non-interoperable ESBs and custom built hardware appliances. The software scales on Intel Multi-Core such as the new i7 platform and uses standard servers rather than custom chips for XML message acceleration.

A friend of mine forwarded me this DoS attack against the IBM DataPower XS40 SOA Security Appliance using only the standard OpenSSL command line client. Apparently you can cause the box to reboot by sending a random string over an SSL-enabled socket connection.

I got in touch with a friend with access to an IBM DataPower XI50 and they were unable to reproduce the issue on the integration device, but that doesn't mean similar issues like this one aren't going to crop up, especially in a closed-off hardended device like this. I also wonder if this attack was an accident or if it was the result of a concentrated security analysis on the device itself.

I think this is where it makes sense to reexamine closed-off products in light of well known design principles like security through obscurity and ask if it makes sense to protect enterprise and SaaS applications with this type of device as contrasted with a software solution that runs on an open-source with a known risk profile.

It looks like a new binding for SAML v2.0 is soon to be ratified, the HTTP POST "SimpleSign" Binding . The "SimpleSign" binding was originally crafted by Jeff Hodges and Scott Cantor relaxes the XML Signature requirements on the SAML Protocol, making it easier for scripting environments to send signed SAML requests and verify signed SAML responses. The main problem with XML Signature is performance - very few people know that the cryptography involved in XML Signature is often dwarfed many times over by the extensive XML processing requirements including parsing, transformation and XML canonicalization (e.g. c14n).

The situation only gets worse as the size of the XML document increases or the number of references to be signed increases. This profile takes a less sophisticated approach and interprets the XML content of the SAML request or response as an octet stream and then represents the signature as a base-64 encoded blob. While I think that this type of profile will do wonders to help scripting environments support signed SAML requests, this specification does not replace the signature on the actual SAML assertion - it just applies to the and messages.

This means that for persistent message level security on SAML assertions, XML Signature is still required. Other solutions to this problem are to decouple the XML signature processing from the scripting environment and moves it to the network with a SOA software appliance. This approach uses the original XML Signature as specified in the original spec (you will likely have to use it anyway if you want signed SAML assertions) and avoids having to implement and test a new profile.