XML Firewall: Not the Keystone of Your SOA

Interoperability is key to communicating with your partners' and clients' systems. It's therefore important to remember that building a SOA can greatly impact these groups. As this worst practice – involving the implementation of an XML firewall – demonstrates, sometimes the best of intentions can backfire on a business. And ignorance is not bliss in the SOA world.

The Idea: "Hackers Can't Harm Us: We Have an XML Firewall"

Dane Foods prided itself on delivering quality customer service, in addition to quality baked and frozen goods. Its customer service department was a pure Oracle shop, from backend databases, to Web and Oracle Forms front ends. The system had its quirks, but had been working well for years.

The customer service department was self-contained, except for limited interactions with external customers and partners to gather complaints. Complaints were accepted in virtually any format, since the department didn't want formatting requirements to prevent it from obtaining valuable data. No other business process in the department depended on interactions with external partners.

The CIO of Dane Foods decided that the company needed a SOA. He did not know a lot about SOA, but he had heard people talking about it. And it sounded like a good idea.

As a next step, the IT team intended to purchase an XML firewall to protect two services that would perform schema validation on dozens of transactions per second. The CIO then created an RFP, which listed improved performance and improved UI as the main goals of the SOA.

After installing the XML firewall, the IT team encountered communication problems, which frustrated customers and partners. They then had to turn off several firewall features, as they worked to resolve the problems.

Why It Wasn't So Smart

Dane Foods' idea failed for three reasons:

• The RFP confused performance and UI requirements of the firewall with the objectives of the SOA. Not only are these requirements not typical SOA security objectives, but they also are not considered to be strengths of firewalls.
• The department needed to secure the interoperability it had with external users.
• The IT team permitted different data schemas from various sources, which created issues for the IT department and later forced partners and customers to change their schema. This generated unexpected work and costs for those organizations.

A Better Approach

Is this a SOA pilot program? Make sure that you are building a SOA for the right reasons. These reasons should be based on your business goals as well as your IT objectives: IT and business requirements must be aligned.

Second, devise a strategy for your SOA, plus a way to communicate your SOA plans to partners, customers, and anyone else that it impacts.

Third, be aware that interoperability is a requirement of a SOA, but it does not happen magically. Web services often have numerous suppliers and consumers. Before you patch or update a service, you will want to know all the Web services dependencies—the consumers downstream and the providers upstream—as well as the potential business impact. (You can automatically detect and discover these with Actional solutions.)

In the case of Dana Foods, the XML firewall turned out to be almost irrelevant. What the company should have done first was to obtain a better understanding of why they were implementing a SOA – which would have highlighted their real security needs up front. This approach would have prevented them from turning off the firewall features that ended up opening their network to hackers.

For More Information

Why you shouldn't depend on an XML firewall for SOA security. These answers and more in the free white paper, Web Services Risks: Threats and Security