ServiceTechMag.com > Archive > Issue XXXVIII: April 2010 > XML Appliances for Service-Oriented Architectures
Thomas Rischbeck

Thomas Rischbeck

Biography

Thomas holds a Ph.D. in Parallel Computing from the University of Newcastle upon Tyne. He engages with the world-wide SOA community, is a frequent speaker and book author (co-author of "SOA Design Patterns" and "Modern SOA Infrastructure: Technology, Design, and Governance" within the Prentice Hall SOA Series).

Thomas currently works as an IT architect and business developer with [ipt], a local SOA consulting boutique with a Java technology focus (see Gartner's Guide to SOA Consulting). He is a member of the extended [ipt] board and responsible for the sales process and new client business. Thomas has a track record of successful SOA introduction and delivery projects-often built around ESB platforms. He specializes in SOA reference architectures, SOA design patterns and SOA security.

Prior to joining [ipt] Thomas was a senior engineer with Hewlett Packard's middleware division. After the HP-Compaq merger in 2001, part of the middleware division was spun out. Thomas was part of that move and took the role of solutions architect in the newly founded company, Arjuna Ltd.

Contributions

rss  subscribe to this author

Bookmarks



XML Appliances for Service-Oriented Architectures

Published: April 8, 2010 • SOA Magazine Issue XXXVIII
 

Introduction

XML appliances are a type of SOA intermediary that typically comes in hardware form factor and addresses the security threats associated with modern XML architectures. They are primarily geared towards security enforcement, monitoring and transformation. [REF-1] More recently, XML appliances also made inroads into the area of SOA management and governance.

XML appliances contain hardened chips that can process XML in specialized circuits, at “wire-speeds”. This yields high throughput and low latency, which are relevant criteria for deployment at the network perimeter. Many SOA security issues and XML-specific threats can be detected very efficiently by XML appliances. They allow turn-key deployment because of the hardware form factor.


Development

Niche vendors rose to this challenge and addressed the businesses’ critical need for the protection of Web Service resources. They developed XML appliances as an evolution of the more traditional TCP/IP routing devices. Geared towards the processing and filtering of SOAP and XML payloads their characteristic attributes are low latency and high throughput. The content of SOAP messages serves as the basis for routing decisions. For example, the XML appliance may examine SOAP headers for the presence of a valid SAML token. XML appliances are slowly becoming an integral component as part of a layered defense against attacks and vulnerabilities.

Like their WAF predecessors, XML appliances have a network appliance form factor. They typically comprise an application-specific integrated circuit (ASIC) for the processing of XML content “in silicone” – and therefore without significant performance degradation. The ASIC offers XML security, acceleration, transformation and parsing and provides low latency and high throughput when routing XML messages. XML appliances (as routers) are typically built around a Unix- (or Linux-) based operating system, some devices even do without hard disk (“no spinning media”), relying solely on solid-state memory for booting up the operating system. XML acceleration can also reduce power consumption.

XML appliances are typically stateless – they do not provide transactions and can’t act as resource coordinators. This is for the following reasons:

  • Statelessness makes clustering simpler. The state management across multiple clustered instances is a difficult and resource-intensive undertaking (as demonstrated by J2EE servers).
  • Distributed atomic transactions are in conflict with loose coupling. Long-lasting business processes that lock resources can block a subset of the services for other requests - potentially affecting services at multiple businesses. In the context of service-oriented architectures it is therefore often a much better choice to not use blocking transactions but to rely on compensation handlers instead.

Routers and Web Application Firewalls

XML appliances emerged from network routers and application-aware firewalls – however, these devices are decidedly different. In this section we address the similarities, overlaps and differences between XML appliances and related product types.

Switches and bridges connect several network segments at the Ethernet layer (TCP layer 2) and shuffle packets around. Routers can handle information on the OSI layer 3 (corresponding to the IP transport layer – see diagram below). Routers are capable of examining IP packets. For example, only certain source/destination IP addresses and port numbers may be allowed to go past. Routers can therefore act as firewalls, fulfilling and important role in network security. XML appliances have built-in router functionality in most instances.


Figure 1 - Composition of an Ethernet frame

With the pervasiveness of the Web, HTTP has become the most prevalent type of traffic across the firewall.

  • Outbound HTTP is typically handled via a so-called forward proxy that channels all requests to the public Web.
  • Inbound HTTP is often handled via reverse proxy servers that dispatch requests to backend Web servers.

Frequently, HTTP and SMTP are the only traffic types allowed through the corporate firewall. More intelligent gateway products have adapted to this development – they operate at the TCP/IP application layer (corresponding to the OSI/ISO layers 4-7) and examine application payloads to identify and neutralize application-specific threats.


Figure 2 - The ISO/OSI reference model compared to the TCP/IP model and associated coupling devices. TCP/IP doesn’t distinguish between the application, presentation and session layers defined in the ISO/OSI model – XML appliances act at the application layer (OSI 4-7).

These devices act as a first line of defense against HTTP attacks and protect backend Web applications from security breaches. They can monitor compliance with corporate policies and balance workload amongst several backend servers. As part of their job they inspect and take actions based on the content of HTTP headers, bodies and the overall system context and take routing decisions accordingly. One salient feature is HTTP session affinity: this guarantees that a given browser client is always directed to the same backend server (based on the HTTP session cookie) which is important for the maintenance of stateful HTTP sessions.

XML appliances and WAFs overlap – but they are still distinct product types. Web application specific functionalities, such as HTTP session handling and cookie support are not normally supported by XML appliances. XML appliances augment other threat protection mechanisms focused at the operating system level, the services level (SMTP, POP, HTTP/S) and the application level (Web applications).


Figure 3 - The ISO/OSI reference model compared to the TCP/IP model and associated coupling devices. TCP/IP doesn’t distinguish between the application, presentation and session layers defined in the ISO/OSI model – XML appliances act at the application layer (OSI 4-7).

XML Threat Protection and Payload Validation

As mentioned above, XML appliances were originally geared towards supporting Web service security. With the erosion of the firewall that accompanied the rise of B2B Web service usage, security considerations were the primary driver for their emergence.

XML appliances are specialized to provide threat protection and content inspection in order to shield a corporate service portfolio from external attacks. This includes the detection of replay attacks, stripping of binary payloads, scanning for malicious content and many other forms of security protection.

  • Explicit threats - XML appliances can enforce explicit policies specific to a service, domain or enterprise. These are threats that are expected and known in advance.
  • Implicit threats - blanket XML-level threats apply to all services in an SOA. The XML appliance provides a broad umbrella of protection against such types of attacks.

XML Acceleration

XML appliances use a specialized XML processor to perform heavy-duty XML processing in silicone. They can therefore handle a high volume of XML requests with comparatively low latency. This makes XML appliances ideal candidates for deployment at network boundaries, such as within the DMZ.

The following XML and cryptography functionality is available in hardware, depending on the chosen XML appliance product:

  • XSLT Transformations - XML appliances may offer functionality to compile XSLT stylesheets and run the compiled code on specialized hardware.
  • XML Schema Validation - validation can be highly resource intensive because a complete XML document must be parsed in-memory to do schema validation. At the same time this is frequently an important requirement so that within the corporate network a “clean order” principle can be assumed.
  • SSL Acceleration - The termination of SSL tunnels is highly resource-intensive. Software implementations cannot typically handle a high volume and throughput of SSL connections. That is why existing routers have for long offered hardware SSL acceleration in order to offload work from backend Web servers into the DMZ zone.
  • Message Privacy - An XML appliance can usually support XML encryption and decryption operations in hardware terminate the encryption if desired and route decrypted XML messages via a trusted network to the backend logic.
  • Message Integrity - Ensure that a message has not been tampered with, decrypt the message and eventually pass it on to the backend processing logic. The ability to sign and verify signatures is a critical part of XML key management and SAML (Security Assertion Markup Language).

Those functions are resource-intensive and may be prohibitively resource-consuming when implemented in software. Offloading of encryption and decryption operations from the service endpoint to an XML gateway, however, introduces yet again a first mile/last mile problem. The high-quality message-level protection that WS-Security offers is terminated by the XML appliance. So you loose the end-to-end security provided by WS-Security. The last mile (or first mile) is therefore less secure – this approach therefore only works, if the trust in the local network that hosts the services is relatively high.


SOAP-VPN

Some XML appliances come with VPN-like functionality based on a consumer-side gateway appliance (hardware or software). Between the gateway and the provider appliance, a virtual channel is established, using WS-Security to provide integrity and privacy at the data layer. This approach works by transmitting WS-secured SOAP messages across the public Internet and across firewalls

Connection of services across federated business entities is therefore seamless – only trust between the gateway appliance and the provider’s XML appliance must be established. Complicated negotiation and reconciliation of transport and security protocols is not necessary. WS-Security tokens are attached to in-flight messages transparently and guarantee privacy and integrity.

The diagram below demonstrates how two organizations use an XML appliance to create a SOAP-VPN. A gateway appliance deployed at organization A enables virtual private communication across the public Internet. The gateway employs WS-Security to protect messages from eavesdropping and manipulation. The usage of an appliance at the consumer side (Organization A) avoids complex software setup and configuration which would otherwise be necessary in order to consume Organization B’s secure services.

Note that the SOAP VPN approach is very different from traditional TCP/IP based VPN solutions where a tunnel is created that secures traffic at the transport layer.


Figure 4 - Organization A uses an XML Appliance that applies WS-Security encryption and digital signature according to the service contracts exposed by Organization B.

XML Appliance Features

In detail, the following security requirements exist in Web Service based systems:

  • Policy Management: Provide a policy definition point (PDP) and policy enforcement point (PEP) for the single-point management and application of Web Service policies and other compliance requirements. The policies should be managed corporate-wide or across connected business partners (the “extended” enterprise or enterprise nervous network) – Validate consistent policy implementation.
  • Scanning of binary attachments for malware and viruses: usually offloaded to more specialized antivirus toolkits. This is similar to email servers that check for viruses and restrict message content and size.

Conclusion

Hardware-based XML appliances are geared towards very efficient processing of XML messages. For resource-intensive processing such as message encryption-decryption, signature-verification, filtering and transformation, hardware-based XML appliances can significantly improve throughput and reduce latency. This offloads CPU load from general purpose application servers and service hosting platforms. The hardware form factor of XML appliances also implies that they can be easily installed into the data center, without requiring software installation. Note however, that not all data center guidelines allow such deployments. Therefore, many XML appliance vendors now chose to provide their software as a virtual appliance that can be deployed anywhere (albeit without XML acceleration).

XML appliances are extremely adept at acting as a policy enforcement point (PEP) – the vendors’ support is broader in this area than for other intermediary types. Interoperability of the policy definitions is still an obstacle though. Best practice is the single-point management and application of policies and other compliance requirements. Such policies should be managed corporate-wide and across connected business partners. Consistent policy implementation and the ability to audit their application is therefore crucial.


References

[REF-1] Lorie MacVittie, “XML Gateways.” Network Computing, April 28, 2005