Do I need an XML Firewall?

Ok, so you are building Web Services and putting them into production. Soon some external partners need to use your services and a question of Security comes up: how do I secure my services?

Whether you want to make the communication over SSL or just use basic http authentication or authentication through an LDAP server, there still needs to be an implementation of any of these security mechanisms. In this blog, I'll talk a little about what those options are and what the pros and cons are of each, regardless of which security type you need to use.

1. Adding security directly to the Web service.
In this option, the security for the Web Service is embedded into the code for the Web service. This is the most common way of implementing security. Although it might be a good option, if you are building a single Web service, there are many flaws with this approach.
The main issue with this approach is change management. In this case, the addition of security is the job of the developer who is building the service. So if there is an authentication of the user that needs to be done, it will be done by the service before the actual work the service is supposed to do. Now what if there is a new policy in which all the consumers of the service need to be authenticated through a different mechanism than the one that was originally designed? Well in this case, the developer would have to re-write the code and then send the service back into QA and so on. So this is far from an ideal implementation type.

2. Installing the Security in a handler agent.
In this case security is still owned by the developer of the service, but the code for security is not embedded in the code for Web Service. Instead the developer installs the security as part of the handler chain in J2EE environment or an extension in the .Net environment. Although this is a better choice than building the code directly into the Web Service, as you build more and more services this becomes a management nightmare, as you would have to modify configuration files on the application server hosting the service to install these agents, if there are any changes. Also in a lot of environments, if the handler chain code is modified, then everything needs to go through the QA process. In this way, you would still have the problem of adding security directly to the web service (number 1).

3. Use an XML Firewall
This is the best option available, to introduce a gateway or a proxy where all of the requests to the Web service will be authenticated. In this architecture, the consumer of the web service will send requests to an intermediary (XML Firewall) where authentication and authorization will take place. Then the intermediary will be able to route the messages to the web service, wait for a response, and then send the response back to the consumer. It essentially virtualizes the service. So as far as the consumer is concerned, the XML firewall is the web service.
This implementation allows you to externalize the security from the web service, therefore any changes to your security policies do not result in any code change at the service layer. All of the management of the security will be done at the firewall. You can perform encryption/decryption and authentication externally of the web service. It also removes all of that processing from the application server, as many of the processing done for security is very resource intensive.
Also it removes the security implementation from the hands of the developer and puts it in the hands of the operation folks, where security should be.

Most XML firewalls also include visibility and monitoring features, so you could also use the firewall to meter and manage your services.

Traditionally, it was thought that you need many services and a big budget to buy an XML Firewall. Not true! There are affordable options available now, starting at as little as 2k. This is cost effective solution, in respect to the amount of money this can save by just changing the management process of the QA cycle.
So even if you are putting a single Web service in production, you should think about using an XML Firewall.

AA

www.managedmethods.com