Pelle Braendgaard: Middle Tier Technlogies

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.

Open for Business (Identity management & open networks).

Nikolaj at Digital Identity mentions Consult Hyperion's whitepaper on identity management. Big points to him for also posting a link in the same article to Carl Ellison and Bruce Schneiers classic: What You're not Being Told about Public Key Infrastructure. Nice one.

[Digital Identity]

Quick 5 minute intro to JCE for Developers

All enterprise java developers should have at least a passing knowledge of JCE. If you've never tried it before try this quick little intro to sample it: Master the basics of Java Cryptography Extension (JCE). [builder.com]

Does Open Source Software Really Work?

This article is about the use of Open Source software (primarily Linux) in the Enterprise. It has some good absolutely valid points about the lack of enterprise monitoring tools and scalability of Linux. But when it comes to the support issue, I just had to comment:

"There are different reasons why people advocate open source. One reason for enterprise is, 'You have the source code; if it doesn't work, you can fix it.' But the fact is, if I'm an enterprise, I don't want to fix it. I want somebody else to fix it," Goldman said.
"Who are you going to call when it doesn't work?" he asked. [NewsFactor]

Most companies who sell highend appservers etc. have very expensive support contracts that they virtually require you to take out. With an exception of a few companies, it is my belief that these contracts are useless. Over the last 6 years, I have on almost every occasion known more than the support guy on the other end, because whoever developed the part that's causing an issue left 7 months ago.

We will use good commercial packages when the budget is there for it and if required by architecture boards. But in many areas the opensource varieties are better written, better supported and fixable when who ever wrote the original code disappeared off the face of the planet. Serveral of my clients have paid $50k annual support contracts for nothing but frustration.

Just look at Apache. IBM and Oracle stopped developing their own webservers and now ship Apache as standard with their appservers. Apache Tomcat has virtually become a defacto standard for small to midsize JSP/Servlet apps in banks and JBoss is starting to do the same for EJBs. Offering a complete J2EE Appserver in an opensource package.

The moral? Just because a software package is Commercial, doesn't mean the support is any good.