The Web Services Advisor
(To receive this column in your inbox,
click Edit your Profile and subscribe.).
Firewalls have long been a mainstay of corporate security - but when it comes to Web services, they may well provide no security at all, because they can only filter at the packet level, and can't examine the contents of messages. Considering that Web services traffic may account for 25 percent of all enterprise traffic by 2006 according to the ZapThink Web services consulting group, that is a serious problem for any business looking to use Web services.
But a new technology, XML firewalls, promises to protect corporations against the unique dangers and intrusions posed by Web services. These firewalls can examine SOAP headers and XML tags, and based on what they find, distinguish legitimate from unauthorized content. In this column, we'll take a look at how XML firewalls work, at which vendors make them, and whether they're right for you today.
How XML Firewalls work
To understand how XML firewalls differ from normal firewalls, we'll need to take a brief look at how firewalls normally work. Traditional firewalls protect a network's perimeter by blocking incoming Internet traffic using several different means. Some block all TCP ports except for port 80 (HTTP traffic); port 443 (HTTPS traffic); and port 25 (email traffic). Some ban traffic from specific IP addresses, or ban traffic based on the traffic's usage characteristics.
The problem with these firewalls when it comes to Web services, is that as a general rule, many Web services are designed to come in over port 80. So even if the service is a malicious one, the firewall will let it through. That's because traditional firewalls can't filter out traffic based on the traffic's underlying content – they can only filter on the packet level, not the content level. That's where XML firewalls come in. They are designed to examine the XML content of the incoming traffic, understand the content, and based on that understanding, take an action – for example, letting the traffic in or blocking it.
XML firewalls typically work by examining SOAP message headers. The header may have detailed information put there specifically for the firewall to examine, and if so, the firewall can take an action based on that information. Even if the header doesn't have this information, however, XML firewalls can still take actions based on what is in the header. The header, for example, might have information about the recipients of the message, about security of the overall message, or about the intermediaries through which the message has passed.
In addition, XML firewalls can look into the body of the message itself and examine it down to the tag level. It can tell if a message is an authorized one, or coming from an authorized recipient. If a federated ID system is involved, it can examine the SAML (Secure Assertion Markup Language ) security token, and see if it trusts the token's creator, and then take action based on that – for example, blocking traffic, sending it to a secure environment where it can be further examined, or allowing it to pass through.
XML firewalls have other methods of protection as well. They can understand metadata about the Web service's service requestor as well as metadata about the Web service operation itself. They can gather information about the service requestor, such as understanding what role the requestor plays in the current Web service request, for example. XML firewalls can also provide authentication, decryption, and real-time monitoring and reporting.
Who makes XML Firewalls today?
There are generally two types of XML firewalls – those that are hardware-based, and those that are software-based. According to Jason Bloomberg, Senior Analyst at ZapThink, the two work similarly, except that "hardware XML firewalls have the advantages of speed and manageability." As a rule, though, they cost more as well.
Bloomberg notes that XML firewalls are actually a subset of XML proxies, which provide other services in addition to security, such as XML transformation or acceleration. So in many instances, someone interested in an XML firewall will get firewall protection as part of an overall XML proxy server.
XML firewall vendors are a mix of startups, and older-line security companies looking to enter the market. For example, Westbridge Technology (www.westbridgetech.com) sells its XML Message Server that includes an XML firewall that provides authentication, authorization, encryption, digital signature support, and real-time monitoring. Quadrasis (www.quadrasis.com) offers the SOAP Content Inspector, which does authentication, authorizations, alerts, and auditing, and supports WS-Security, Microsoft Passport, and SAML (Secure Assertion Markup Language) standard. Other startup firms with XML firewalls include Vordel (www.vordel.com), Reactivity (www.reactivity.com), Forum Systems (www.forumsys.com), and Flamenco Networks (www.flamenconetworks.com). Established companies are entering the market as well – Check Point Software, for example, includes XML firewall functionality in its Check Point VPN-1/FireWall-1 product. In the long run, expect other established vendors to enter the market as well, including companies such as Cisco, says Bloomberg.
Advice for the Future
While vendors continue to enter the market, the number of paying customers right now is limited. "It's just getting started," Bloomberg says. "Companies are just rolling out products. There are a few early customers, but not a significant market for it today. It will get big in the future, but it might not be a separate market in the long run – the traditional firewall market will incorporate a lot of it." So is it worth it for you to buy an XML firewall today? If your company currently has a significant amount of Web service traffic, it's worth a look, although you'd do well to examine as many vendors as possible. Also, since there are no standard ways that XML firewalls work, make sure that the firewall meshes with the way you implement Web services, and in particular with the security standards, such as SAML, that you use.
Even if you don't need an XML firewall now, you will at some time in the future, so you'd do well to start investigating them today.
Continued from Part One
About the Author
Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at email@example.com.
For More Information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.
Dig Deeper on Development implications of microservices architecture