Pelle Braendgaard: XML

IBM, MS and Verisign announce new Web Service Security Architecture

I haven't had time to read the full whitepaper yet. This Whitepaper describes their new WS-Security proposal.

This document describes a proposed strategy for addressing security within a Web service environment. It defines a comprehensive Web service security model that supports, integrates and unifies several popular security models, mechanisms, and technologies (including both symmetric and public key technologies) in a way that enables a variety of systems to securely interoperate in a platform- and language-neutral manner. It also describes a set of specifications and scenarios that show how these specifications might be used together.

I'll have a quick read and come back with any comments.

SOAP security and external underwear.

Jon Udell discusses the SOAPAction header and its uses for filtering SOAP requests through a firewall. The concept of the header is that the client making the SOAP Request, places a SOAPAction header in the HTTP request describing what it is they are going to be doing. For example what method they will be invoking. When I first read this a few years back it did send question marks buzzing up through my head, as you cant really on an external description of what is going to happen. Jon put's it great with his analogy of External Underwear:

Did the notion advanced in DevelopMentor's FAQ -- that SOAP packets would declare intent by publishing interface and method names in the HTTP header -- make sense? At the time it seemed reasonable to me. But now, I wonder if a SOAPaction policy isn't rather like the scene in Bananas where the newly-installed dictator declares that "everybody must wear their underwear on the outside, so we can check." The interfaces that a company chooses to expose to the world are, in the end, a policy that will or won't be enforced, regardless of the SOAP toolkits in use or the translations performed in a request pipeline. Enforcement will always require more than checking for underwear on the outside. [Jon's Radio]

Those of us who were writing perl CGI apps way back in the early days of the Web learnt that you can't rely on the format of a request. You really do need to verify all data before you make any assumptions about it, so a http SOAPAction header specifying a Stock ticker lookup interface, can just as easily have a Stock trading message within.

All of this discussion though assumes that you only have one single SOAP gateway/router on your web server. This strikes me as a bit naive from a security standpoint. I think that only interfaces with the EXACT same security properties should be exposed in the same router. This way you can use the underlying web servers security as well as external firewall's to provide access control and authentication. Lets not reinvent the wheel here.

Exploring XML Encryption

IBM Developer Works are running a good article on XML Encryption. Over the last year or so almost all the new feeds and systems I've linked in with on projects have used XML for interop. XML Security is going to be extremely important over the next year or two. It is particularly useful, because you can encrypt and sign individual elements rather than only full messages. The signatures will ofcourse verify the integrity of a message or element and the element by element encryption is useful for only allowing access to the part of the message you need in your subsystem.

Liberty: betting on SAML?.

Prior suspect that Liberty will be looking to the Security Assertation Markup Language (SAML), a proposed standard from the OASIS Security Services technical committee, now seems definitive.
I have three independant confirmations from Alliance founders, that SAML indeed is the security information protocol of choice. It is, however, also quite safe to bet that Liberty's specific requirements of operating a shared public identity space with specific focus on merchants, will force extensions upon the standard.

[Digital Identity]

The Liberty Alliance Project counts several Prominent US Financial Services companies such as: American Express, Fidelity, Bank of America and CitiBank (Hmm, what about todays announcement regarding Passport?? Betting on two horses I guess.). The project aims to setup a large federated Identity Service to compete with MS Passport. So far little is concrete, but it sounds like they might be using SAML, which certainly would make sense.

I've seen plenty of anti microsoft alliances before and I must admit I'm a bit sceptical if they actually will get past the vapour ware stage. But I do hope they do, as no one wants to see MS own that market. (Of course they are probably the one company suited to do so).

Financial companies will primarily be interested in Liberty for retail apps. There is little sense in using them for internal applications. I can see larger banks creating SAML interfaces into existing authentication frameworks. Data providers will probably eventually look into using it as well for authentication of their services.

Security Assertion Markup Language

As a follow up to the CitiBank story below, I had a look at what alternatives are available that would be of interest to the Financial Services Industry. The Oasis Consortium who work on various Business related XML formats have proposed a standard called Security Assertion Markup Language (SAML). The Standard is nearing completion and we should be seeing a V1.0 within the next month or so.

SAML looks particularly useful to Investment Banks. It handles everything from End User Authentication to Service to Service Authentication. Which would be useful for various kinds of feeds. A Standard Java extension will be released from Sun that contains a Java API, hopefully making it easy to plug into existing systems.

I'll post a more detailed analysis of SAML later on.