Securing SOAP/XML
You can address SOAP/XML security concerns three ways. First, if your use of SOAP/XML is light and limited to a stable set of partners, you might be able to get by with a classic firewall. However, the vendor must enhance the firewall so that it can at least recognize SOAP within HTTP and other protocols. You can then enable SOAP and XML content between your organization and its trusted business partners and block everything else.
Vendors of traditional firewalls are starting to recognize their products' shortcomings with regard to SOAP and XML. For example, about a year ago, Check Point Software Technologies announced support for SOAP/XML security in its FireWall-1 product. A longtime heavyweight in the classic firewall market, FireWall-1 can now recognize SOAP messages and XML content and block SOAP messages based on criteria such as source and destination. FireWall-1 lets you enable access on a Web-service—by—Web-service basis and can validate XML content against a schema that you specify, helping FireWall-1 trap suspicious SOAP messages and potential DoS attacks before they reach your Web service.
A second option for SOAP/XML firewalls is to build your own. Although probably not an appealing alternative for most organizations, building your own firewall is possible, and tools exist to help you do the job. For example, Microsoft Internet Security and Acceleration (ISA) Server 2000 lets you write Internet Server API (ISAPI) filters on an ISA server, and Microsoft provides a model ISAPI filter for validating SOAP/XML messages while they're at the ISA server. (To learn more about Microsoft's model ISAPI filter, go to http://www.microsoft.com/isaserver and select Ensuring trusted Web services.)
The third, and usually best, option is an application-level firewall that operates behind your classic firewall to validate only SOAP/XML traffic. Similar to a proxy, this type of product receives the Web service message as though the application-level firewall were actually the Web service. These products inspect the message; authenticate the person, program, or organization that sent it; then verify that the sender is authorized to the Web service and the requested operation. Authentication can use a simple username and password, a certificate, or a federated system that uses Security Assertion Markup Language (SAML).
An application-level firewall can authenticate credentials against sources such as a Lightweight Directory Access Protocol (LDAP) directory (e.g., Active Directory—AD) or a Remote Authentication Dial-In User Service (RADIUS) server. Then, the firewall checks the requested Web service and operation and the data elements (i.e., parameters) within the message to make sure the request is valid and authorized for the user. Either before or after authentication, depending on the product, the firewall weeds out malformed messages and DoS attacks by ensuring that the request's format complies with the corresponding schema. The firewall forwards messages that pass these checks to the appropriate Web service.
Most SOAP/XML firewalls also provide some type of audit functionality and logging so that you can monitor what's happening with your Web services. Because encryption and XML parsing are CPU-intensive, this more complex proxy architecture is important to implementing SOAP/XML firewalls in high-security and high-volume Web service scenarios. Because SOAP/XML supports security at the transport level, a SOAP/XML firewall can use Secure Sockets Layer (SSL) and Transport Layer Security (TLS) to encrypt the entire HTTP-based message stream.
But sometimes you need to be able to encrypt or digitally sign portions of an XML document—to facilitate multiparty transactions, for example. The XML Encryption and XML Signature security standards meet these intradocument cryptography needs. Because a SOAP/XML firewall functions as a proxy Web service, all authentication, encryption, and decryption take place at the firewall, letting you centrally and consistently control authentication, encryption, and policy checks even if Web services are scattered on servers throughout your network. Another advantage is that, because only decrypted traffic can be inspected, encrypted content is decrypted at the firewall and compared against the firewall's policy.
Register
