Enemy At the Gateway

• Implement some kind of access-control mechanism in the SOAP service logic. However, this may not be possible if you're running a closed-source, third-party SOAP service product or if you don't have the proper development resources. It also requires that clients update their software to accommodate the new XML authentication elements.

• Design, architect and implement all individual SOAP services into different URL endpoints. Worst-case scenario, we could host each SOAP service on a different server. This, again, assumes that you control the SOAP service implementation, your SOAP application server allows URL endpoint separation, and you have enough skilled staffers to manage one-off distributed SOAP services.

• Look for a SOAP application server that has some SOAP encryption and authentication extensions built in. However, this still may involve changes to the SOAP services.

None of these options is pretty. Luckily, WS-Security gateways parse and interpret incoming SOAP requests, just as a Web and SOAP app server would, then give you the tools necessary to route, authorize and restrict SOAP requests based on specific SOAP particulars, which are otherwise unknown to your firewall or Web server.

Using a WS-Security gateway in the scenario described above, we could restrict which clients can access which SOAP services, using myriad authentication schemes included in the XML security extensions typically supported by the various WS-Security gateways. And best of all, we could do this without making a single change to our SOAP application logic.

Authentication is only one of the capabilities provided by WS-Security gateways. The protocol also handles data integrity and encryption. For example, some SOAP services let B2B partners submit information directly into your database for processing. Imagine if an attacker pulled off a man-in-the-middle attack that resulted in copious amounts of tainted or false data being dumped directly into your database. A data-integrity mechanism, such as a cryptographic signature, could prove the data didn't originate from your partner and thus shouldn't be allowed to access the SOAP service for database processing.

WS-Security gateways also shield your Web and application servers from various forms of known attacks. This means you can use Microsoft's .Net SOAP framework without having to worry (as much) about the fact that it's hosted on Microsoft's notoriously insecure IIS Web server.

All this sounded good to us in theory, so we decided to see how well reality would match up. We asked DataPower Technology, Forum Systems, Reactivity, Sarvega, VeriSign, Westbridge Technology and Xtradyne Technologies to send their WS-Security gateways to our Green Bay applications lab. Sarvega initially accepted, but then, after some hemming and hawing, declined, citing resource issues. All the others sent products to us, and after syncing up with our Neohapsis partner labs, we got rolling (see "How We Tested WS-Security Gateways," page 54, for details). For an overview of our NWC Inc. labs, go to inc.networkcomputing.com.

Contrary to vendors' marketing literature, there is no "ultimate security product" that removes all risk, and WS-Security gateways are no exception. It's important to know what WS-Security gateways can do, but it's just as important to know what they can't do.

Current WS-Security gateways are ignorant when it comes to understanding the data submitted to the SOAP services. Sure, the data type--string, integer, array--is validated against a schema, but that leaves much to be desired. You cannot specify legal and illegal characters except through a well-detailed schema. Thus, unless the schema contains this information, you cannot configure the WS-Security gateway to disallow characters known to be used in SQL tampering attacks, for example, or to stop processing if anything resembling a format-string attack is seen. Ideally, WS-Security gateways should offer per-element data filtering, as their Web application firewall cousins do.

Some of our WS-Security gateway vendors claim to address this problem. Reactivity, for example, says its product can stop SQL tampering attacks. We discovered that it performs a straight generic-pattern match for a small subset of known SQL commands. The subset wasn't comprehensive enough to stop SQL tampering attacks, nor was its pattern-matching all that robust--though it caught our use of xp_cmdshell, it let Xp_CmDsHeLl slip through. However, Reactivity's attempts are more evolved than those of the other vendors, which admit they don't stop this type of attack. At least they're honest!

Another shortcoming is the lack of crossover between WS-Security gateways and Web application firewalls. None of the WS-Security gateways we tested made attempts to secure anything other than SOAP services or XML documents posted via HTTP. You're out of luck if you plan to consolidate both typical Web material and SOAP services on the same system. A few Web application firewalls, such as Kavado's ScanDo and InterDo and Process Software's MultiNet, do handle basic SOAP security, but they were not included in this review because they lack full WS-Security support.

Performance is also an issue. We give serious props to Xtradyne for offering a software product that can keep up with appliances from DataPower and Forum Systems, which rely on hardware acceleration to provide zero-failure performance levels. Hybrid "appliance" products, which were nothing more than a stock OS and branded hardware from a Tier 1 vendor and other software-only entries, were incapable of performing even simple proxy services without failures--and, more important, these products did not notify us of failed transactions. Silently dropping transactions is unacceptable in an environment where revenue is generated, or lost, via Web services.

Also of note is the amount of experience needed to configure these devices. Fortunately, most WS-Security gateways start off being easy to configure, because they can import the base set of rules from the WSDL (Web Services Definition Language) file of the Web service you are trying to protect. Beyond that, they can become complex when you try to add restrictions. At the most extreme end, DataPower's XS40 requires a firm understanding of XSLT (Extensible Stylesheet Language Transformation) to configure some of the more advanced features.

The moral of this story: WS-Security gateways help control who is accessing your SOAP services, but the SOAP services themselves are still largely accountable for mitigating application-level security threats.

We tasked our six WS-Security gateways with securing Web services in our NWC Inc. infrastructure and then scrutinized them from Layer 4. We discovered an immature set of products for a still-evolving set of standards, as well as quite a bit of confusion among vendors trying to position themselves as necessary additions to your data center.

Our most disturbing discovery was the looseness with which the WS-Security 1.0 standard has been interpreted. The WS-Security spec (see schemas.xmlsoap.org/pecs/ws-security/ws-security.htm) lists what must be supported to claim compliance: UsernameToken, BinarySecurityToken (X.509 or Kerberos), SecurityTokenReference, XML Signature and XML Encryption. Support for and compliance with (let alone conformance to) a standard are very different. Both VeriSign and Xtradyne are guilty of implying compliance with WS-Security 1.0. VeriSign supports only X.509 as a method of authentication (not surprising, given its core business), and Xtradyne doesn't support anything but SAML (Security Assertion Markup Language). We found that when marketing literature says the product supports the proposed WS-Security 1.0 standard, what it usually means is that it has a limited subset of functionality that may come nowhere near to complying with the standard.

To add to the confusion, there's neither strict definition of nor consensus on what these products should provide in terms of security features. There's not even a common terminology in use, though most of the concepts are pulled from other areas and could be adapted. One product's "client" is another product's "consumer"; one product's "operation" is another's "function."

After careful consideration, we present our short list of the functionality you should expect from a WS-Security gateway:

• Scrubbing of XML (content inspection)

• WS-Security 1.0 compliance

• Access control for both services and operations

• Integration with existing identity stores, such as LDAP and Active Directory

• Serving of WSDL
• Zero-failure performance, defined as the capability of a device or program to process requests under heavy load without dropping any transactions
• Schema validation and auto SOAP-envelope validation
• Logging and creation of comprehensive audit trails for both transactions and policies.
After months of rigorous testing in our lab, with an eye toward the fulfillment of these requirements, we chose Forum Systems' Forum Sentry 1504 2.0 as our Editors' Choice. The product met more of our expectations than did its competitors, with the added bonus of providing configuration and management utilities that require virtually no specialized knowledge. Forum Sentry is still far from perfect--some advanced configurations will require XSLT conversion, and its content-inspection capabilities are limited at this time--but the product provided a firm base for evolving into what we expect from a WS-Security gateway.

The Forum Sentry line was designed to provide security for XML documents, so the move to support Web services was a natural fit. The appliance's 1U form factor and dual 10/100-Mbps NICs support its proxy-based architecture. A separate management port is provided for secure configuration.

Forum Sentry offers an IOS-like CLI (command-line interface) for configuration, as well as a Web-based console for all administration aspects, except for policy creation and management, which are handled with Forum's XML Workbench. XML Workbench provides an easy-to-use mechanism for defining task lists, Forum's term for policies. This product highlights the company's maturity in the XML area, with its hierarchical, GUI-based method of identifying documents based on any element or element value within XML. When configuring the device to perform encryption of a single node in the response document, for example, we had only to click through the hierarchy of elements to find the appropriate node; all the other products made us use XPath (XML Path Language) to designate encryption of specific elements.

Forum Sentry is a pure proxy; clients send requests to the device, which identifies the document based on its configured policies, applies the appropriate task list to the document and forwards the resulting request to the back-end system. The path in the URI is passed to the back-end system--something we'd like to see improved in this product. Forum Sentry has no means by which the endpoint for a service can be obfuscated--a feature of all the other products we tested.

The device did not support WSDL, and this proved somewhat problematic. Rather than import a WSDL file and derive services and operations, we had to capture a request to the back-end service, save it and import that file into Forum Sentry. It would have been easier to import the original schema (DTD or XML). This is true of all schemas used during validation of requests. Forum says it will offer more robust functionality later this fall, thus easing the process.

Forum Sentry takes advantage of an nCipher HSM (Hardware Security Module) for cryptographic acceleration and key management. Our performance tests show this to be advantageous, as Sentry was one of only three products to maintain performance at zero-failure-tolerance levels while performing encryption.

Rather than associate a policy with a designated TCP port, Sentry 1504 uses priorities and identification tasks to determine which policy should be applied to a request or response. Although this requires more forethought when designing policies, it also supports the product's unique ability to provide signatures and encryption based on dynamic values, including user credentials.

Forum Sentry 1504 2.0. Forum Systems, (801) 313-4400, (866) 333-0210. www.forumsys.comClose on the heels of Forum Sentry was DataPower's XS40, which impressed and frustrated us. Like Forum Sentry, the XS40 is a 1U-form-factor appliance with dual 10/100-Mbps NICs and a separate management port, as well as a serial console. The XS40 can be configured from its IOS-like CLI or its Web-based administration console.

Aside from its reliance on XSLT--no surprise, given the device's kinship to the company's XS35 (an XSLT acceleration device that was our 2003 Infrastructure Product of the Year)--the XS40 met our list of configuration expectations with ease. The extensive knowledge of XSLT that is required does make configuration a complex task, but DataPower told us it is addressing the issue by reworking the administration console and by shipping a wider variety of prebuilt XSLT code designed to perform specific tasks, such as content inspection.

The XS40 uses XSLT for every aspect of control over ingress and egress of SOAP messages. Out-of-the-box support for authentication and integration with identity stores, such as LDAP, is not provided, and we were obliged to write XSLT to create and manage a local identity store. Although the version of Forum Sentry we tested did not support LDAP out of the box, it did provide user authentication.

When it came time to configure the XS40 to encrypt a single element within the response document, we had to dig out our reference books on XPath. Every product we tested--with the notable exception of Forum Sentry--required a knowledge of XPath to perform some aspect of configuration, with encryption at the element level rather than at the document level being the most common scenario.

Configuration via the Web-based administration console was simple in other respects, and included a drag-and-drop method of populating the pipeline with filters and transforms to manipulate incoming and outgoing messages. We configured separate ports and policies for each of our test cases, which made management of multiple policies much easier. We liked the modularization of the policies in all the products, since it provided an easy mechanism for reusing policies.

The XS40's biggest selling points are its flexibility and its performance. Upgrades and support for evolving standards are made simple by requiring only an upgrade of the XSLT language, rather than the software.

Although none of the products we tested was a speed demon, those from DataPower, Forum and Xtradyne consistently processed 250 messages per second, regardless of the policies and configurations applied. Our tests of Web services platforms earlier this year (see "Serving Up SOAP") shows that this is likely adequate to keep up with all but Sun Microsystems' implementation, but we expect that device scalability will increase and keep ahead of the back-end servers for which they proxy, ensuring that they don't become bottlenecks.

DataPower XS40 XML Security Gateway 2.3. DataPower Technology, (617) 864-0455.www.datapower.comReactivity's XML Firewall ships on a Dell 1650 with dual 2.6-GHz Xeon processors and 2 GB of RAM running on Red Hat Linux Advanced Server 2.1. Reactivity has a firm grasp of what's needed to be best-of-class in this market, and this product excels at some of the more esoteric features, such as policy archival and rollback, but it failed to perform at zero-failure levels. This held it back from tying with Forum Sentry for the top spot in our review. Given that the XML Firewall supports (and was tested with) an nCipher HSM, we were stumped by the low performance of this device in our lab. Our discussions with Reactivity led to the conclusion that the size of the data and encryption requirements were not a scenario it had planned for, but the company couldn't say for certain why the device performed less than optimally.

In every other area, the XML Firewall shines. Although we were able to thwart its out-of-the-box content inspection for SQL injection attacks, it was the only product to provide by default even minimal support for this level of content inspection. The XML Firewall's broad set of options for WS-Security let us specify static credentials for accessing back-end systems.

XML Firewall also provides basic Web services management capabilities, such as per-operation response times, access counts and average document sizes. Key management, global exception mapping and full SOAP request/response logging are available. Console audit logs can be tuned to include the SQL statements used to modify policy and configuration data, which is stored within a local Postgres database instance.

The product lets you define by hand or import from WSDL service and operation definitions. The XML Firewall can apply a wide array of security features on both incoming SOAP requests and outgoing SOAP responses, and can validate the content of requests against the XSD (XML Schema Definition Language) derived from the WSDL, as well as a simple, well-formed validation--for example, no content validation. You can configure XSLT caching, access control, encryption and digital signatures on a per-operation basis.

Authentication-support configuration was a breeze. All WS-Security options are supported, and we used a user name-password pair by creating a password file using htpasswd and uploading it to the device via the administration console. Certificates are also easily managed and integrated into authentication mechanisms.

Reactivity XML Firewall 2300. Reactivity, (650) 551-7800. www.reactivity.com

The XML Message Server (XMS) 1U-form-factor appliance, equipped with dual 1-GB copper NICs, rides on the EnGarde Secure Linux distribution, providing tighter network and transport-layer security.

The XMS would have won this review handily had it not been for performance issues. Although the product supports hardware cryptographic accelerators, it does not ship with one installed, and after testing the device with a simple, straight-through proxy configuration, we were not convinced that an accelerator would provide the necessary chops to push the XMS to the performance levels achieved by the products from DataPower, Forum Systems and Xtradyne.

XMS did impress us with the maturity of its configuration and management aspects. Providing features and functionality similar to Reactivity's XML Firewall, the XMS offers a wealth of configuration options, including many typically found only in Web services management products, including QoS (quality of service), SLA (service-level agreement) support, and access restrictions based on time parameters as well as user credentials.

Identity-management integration was excellent as well. In addition to the basic support provided by its competitors, XMS lets you create fine-grained policies based on LDAP attributes, such as "Department" or "Title." Like those of XS40, XMS' policy rules are reusable and can be operation-specific or grouped according to corporate policy implementations.

As with all the products but the Forum Sentry, encryption of specific elements required XPath. Furthermore, we had to upload schemas to support content-level validation. Although the XS40 also required this, it provided a separate tool for extracting the schema from the service's WSDL. Westbridge says it is addressing these issues.

The XM S has a head start on WSDL security in that it can be configured to aggregate WSDL from services to which the requesting client has access, thereby eliminating the problem of exposing all services to the client and restricting this data to authenticated users only. No other product offered such a feature, but we'd be pleased to see it incorporated into all WS-Security gateways.

Westbridge XML Message Server. Westbridge Technology, (650) 210-0700. www.westbridgetech.com

Xtradyne failed to impress us, except for its performance and its automatic validation of SOAP schemas. Its DBC (Domain Boundary Controller) was difficult to configure and was the only product requiring a fat--albeit Java-based--client for all aspects of administration and management. A lack of support for WS-Security, and for XML Encryption in general, was problematic, though the product offered a surprisingly comprehensive set of configuration options in terms of operation-level access control.

The DBC supports LDAP identity stores out of the box, as well as an internal store. Using the internal store, we created several users and groups. Services, called "resources" in the DBC, were easily imported by specifying the location of the WSDL for the service. Once imported, the service endpoint could be obscured so that clients use one URL, while the DBC communicates with the real service. This functionality is typical of devices providing load-balancing capabilities at Layer 7, and it can provide a small measure of security. We were pleased to find this capability in most of the products we reviewed, with Forum Sentry being the lone exception.

Policies consisted of allowing or disallowing users and/or groups access to specific resources based on IP or credentials identification via a SAML assertion.

Of exceptional note was the DBC's automatic validation of SOAP schemas. Although some other products provide this feature, it must be enabled within a policy. DBC has taken a more straightforward approach and verifies the validity of the SOAP schema before it attempts to process the request. We hope that other vendors will offer this basic protection in their next versions; it's fundamentally a poor assumption to take any user request at face value--validating it before processing is a must.

Web Services Domain Boundary Controller 1.3. Xtradyne Technologies, (800) 225-CALLXTRA, +49-6196-400-971. www.xtradyne.comVeriSign's vision is all about PKI (public key infrastructure), and this is apparent in the initial release of its Trust Gateway. To give credit to the digital certificate behemoth, it does make PKI simple, and its product's ability to validate certificates in real time via a managed service is a boon.

Although we were pleased with the depth of PKI support within Trust Gateway and the ease with which such typically complex configurations were handled, we were disappointed by the lack of full WS-Security support and the limitations of the product's encryption capabilities. The XML Encryption specification includes the ability to encrypt an entire XML document or a single node within the document. However, VeriSign does not support element-level encryption, something it will need to address before SOAP 1.2 is widely supported. Intermediaries and automated Web-services-based transactions may pass through several Web-services products during processing, and being able to encrypt specific data elements is paramount to ensuring the confidentiality of data intended to be processed only by specific endpoints.

The Trust Gateway also requires hard-coding of name spaces for advanced configuration of routing based on an endpoint's URI. This tightly couples Trust Gateway and breaks the basic promise of SOA (service-oriented architecture): loose coupling to promote reusability without modification of clients.

Trust Gateway embodies the notion of trust. Configuring access control for specific operations required importing the client's certificate and then simply checking a box to indicate that the certificate should be trusted for a specific operation. Importing certificates was incredibly simple: We specified

the secured URL of a domain we wished to trust, and the Trust Gateway connected to the site and imported the certificate from the established HTTPS session. Westbridge's XMS, in contrast, required us to transfer certificates and key pairs to the device via secure-copy, which, while decidedly more secure, was also decidedly a pain.

Unfortunately, VeriSign makes you pay dearly for this convenience by licensing the product for $50,000--on a yearly basis.

Trust Gateway signs its configuration files to ensure against tampering. We hand-edited the gateway's configuration file (which is XML-based) and attempted to restart the system. The system notified us that the configuration file had been altered or corrupted and refused to start. After we restored the configuration file to its original state, the system started up fine.

Unlike those of XML Firewall, Trust Gateway's log files are not signed, and this dilutes the integrity of the audit trail. We suggested that, at the very least, log files should be signed as they are rotated, and VeriSign says this feature will be included in a future release.

Trust Gateway 1.0.1. VeriSign, (800) 579-2848, (650) 961-7500. www.verisign.com

Lori MacVittie is a Network Computing technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].

Jeff Forristal is the lead security developer for security consultancy Neohapsis, Chicago. Write to him at [email protected].

Post a comment or question on this story.

We deployed products within NWC Inc.'s infrastructure in our Green Bay, Wis., business applications labs (for more on our fictional manufacturer, NWC Inc., see inc.networkcomputing.com). Software-based products from VeriSign and Xtradyne were deployed on Dell 2650 machines with dual Xeon 2.6-GHz processors, 1 GB of RAM and a 1-GB copper NIC running Red Hat Linux 9.0.

Each product was configured to proxy for a .Net-based and a J2EE (Java 2 Enterprise Edition) Web service (Mind Electric Glue on Solaris 9.0, Sun Microsystems SunFire V480 hardware) to evaluate interoperability between platforms and SOAP encoding models.

The products were then configured to handle four scenarios:

• 1. Straight through: The product was required to pass the request to the back-end server and return the response to the client.

• 2. Encrypted element: The product was required to encrypt a specific element (and subelements) within the XML document before returning the response to the client.

• 3. Validation of XML: The product was required to validate the SOAP request and the XML document being submitted.

• 4. Authentication and authorization: The product was required to use either WSSEC (WS-Security specification 1.0, see schemas.xmlsoap.org/; SAML assertion or user name-password) or pull credentials from the submitted XML document to authenticate the client, then determine whether the client's credentials permitted access to the requested operation.

These four scenarios let us evaluate all aspects of configuration and management and gave us the opportunity to examine any integration with external identity stores offered by the products. We also determined the skills necessary to configure the devices--most of the products required specialized chops, such as a thorough understanding of XML schemas and XSLT. We also used these scenarios to appraise each product's certificate and key management features.

For performance testing, we configured Spirent Communications' Reflector to respond to SOAP requests, while a Spirent Avalanche was configured to generate load by simulating hundreds of clients posting SOAP requests to each product under test. The Avalanche attempted to generate as many as 500 requests per second in two separate tests, one using Scenario 1 and the other Scenario 2. Both sets of performance tests submitted a 2-KB SOAP request.

Xtradyne was not included in the performance test for Scenario 2 because it does not support encryption, and VeriSign's product was configured to encrypt the entire response message because it does not support element-level encryption. Logging was decreased during performance testing to the warning level.

Each product was then scrutinized at Layers 2 through 7 for vulnerabilities, such as SQL injection attacks, by developing a J2EE Web service that used a vulnerable version of Microsoft SQL Server 2000 as its database. SAML: Security Assertion Markup Language. An XML framework for exchanging authentication and authorization information.

SOAP: Simple Object Access Protocol. An XML format used to exchange structured information between distributed systems. It is sometimes referred to as XML-RPC; HTTP is the most popular transport used with SOAP.

WSDL: Web Services Definition Language. An XML format to describe the various available network services, and associated parameters and data types, hosted by a system. A WSDL file will tell a client what SOAP services are available and how to use them.

WS-Security: The Web Services Security extension is a set of optional SOAP features. It includes WS Signature, which is used to sign XML data to prove validity and origin, similar to PGP; and WS Encryption, which is used to encrypt XML data to ensure privacy/security. Some aspects of WS-Security build on existing XML security protocols, such as XML Signature and XML Encryption.

WS-Routing: An optional SOAP extension that lets SOAP endpoints specify or override the route a SOAP message is to take.

XML: Extensible Markup Language. An SGML-derived text-formatting language used to format document data into elements, which can then be handled in various manners. HTML is very similar to XML, though XML has much more rigid formatting requirements.

XPath: XML Path Language. A standard naming convention for accessing XML elements within a document. Allows for consistent addressing and naming of document elements.

XSLT: Extensible Stylesheet Language Transformations. XSL is the language used to define how XML elements are to be displayed/presented, and XSLT is the use of the XSL language to transform XML data into specific output, such as HTML. Some vendors use it to define the conditional validation processing that should be done on an XML document."Look Before You Leap"

"Enemy at the Gateway"

Business applications white papers and research reports

Business applications books

SAML

XACML

XKMS

XML DSIG

XML encryption

WS-Security

Security Pipeline SpecWatch on WS-Security

"Microsoft, IBM Demo Standards For More Secure, Complex Web Services"

"Oasis Adopts Web Services Standard for Portals"

"Leading-Edge Health-Care Provider Deploys Web Services"

R E V I E W

WS-Security Gateways

Sorry,
your browser
is not Java
enabled

Welcome to

NETWORK COMPUTING's Interactive Report Card, v2. To launch it, click on the Interactive Report Card ® icon

above. The program components take a few moments to load.

Once launched, enter your own product feature weights and click the Recalc button. The Interactive Report Card ® will re-sort (and re-grade!) the products based on the new category weights you entered.

Click here for more information about our Interactive Report Card ®.