The Challenge of XML and Web Services Security

Thoughts from the Integration Consortium

Information Management Online, February 1, 2007

Integration Consortium

This month's column was contributed by Scott Morrison, vice president of Engineering and chief architect at Layer 7 Technologies.

By providing a flexible, platform-neutral way for rendering diverse data types, XML has become a standard for exchanging information across heterogeneous applications. Web services, a set of XML based protocols for finding and communicating between loosely-coupled, internet callable application "services" have therefore become the preferred mechanism for integrating heterogeneous applications and enabling service- oriented architectures (SOAs).

Standardizing on XML and Web services for data exchange and integration provides significant IT benefits including flexibility, interoperability and reach. However, it also introduces new kinds of security challenges.

• Web services can be transmitted over any transport protocol including common Web protocols like HTTP. This makes it easy for Web services to bypass network firewalls.
• Web services expose business functionality through open APIs requiring new application aware security measures.
• Web services enable multi-hop composite applications requiring message level security and audit that can span multi-hop SOA transactions end to end.
• XML based messages can be deliberately or inadvertently malformed to cause parsers or application break creating new XML threat and vulnerability protection requirements.
• Web services transactions are principally machine-to-machine necessitating new thinking around machine-to-machine trust enablement and credentialing.
• Web services and their client applications must agree on security parameters (like crypto preferences and standards support) before they can successfully exchange data creating a need for new kinds of policy coordination.

Traditional security measures like network firewalls and VPNs are not sufficient to address these new security challenges. Network firewalls are not service or application aware and, therefore, can't regulate access based on service or service feature like operation type. Network firewalls also can't protect against XML-borne threats in a message or message attachment since they lack the ability to inspect XML messages, validate XML structures or detect anomalous XML content. Similarly, network-based VPNs whether SSL or IPSec can't preserve a message's integrity and privacy as it gets passed across service hops in a SOA transaction. Moreover VPNs can't provide message level audit trail or non-repudiation across a SOA transaction. As a result, up until recently he only option for implementing application level XML and Web services security has been to program security directly into the application based service.

Coding security into a Web service however requires developers to understand how to implement emerging WS-* standards like WS-Security, WS-SecureConversation, WS-Trust, WS-Federation, and WS-Policy, to name some, on both the Web services and its clients. It requires Web services coders and client developers to coordinate security preferences through out-of-band mechanisms since a Web service can't communicate security expectations or capabilities to clients automatically. And if a Web service's security needs to be integrated with existing trust infrastructure such as PKI, directory, single sign on (SSO) and identity federation, programmers will need to implement one-off integrations on both the service and client application. For most situations, programming XML and Web services security will therefore lack the consistency, flexibility, scalability and deployment speed end users require.

As a result, two new classes of security infrastructure have emerged to try and satisfy customer demand for purpose-built XML and Web services security on both the service provider and client. To deal with the complexity of Web services security management and enforcement on the Web services provider side of an integration, end users can now avail themselves a new class of XML security infrastructure often referred to as an XML firewall or Web services gateway. An XML firewall or Web services gateway is a dedicated device or piece of software that can be implemented in a DMZ or data center to enforce XML and Web service security preferences around access control, credentialing, integrity, privacy, threat mediation and audit. In some cases, they can also perform hardware accelerated data transformation, routing, service level agreements (SLA) and other policy operations. In all cases, XML firewalls allow security administrators to define security policies for XML and Web services transactions and enforce them centrally without programming.

XML firewalls are a necessary first step in securing Web services, however for some scenarios there is a further requirement to automate security on the client application through an XML VPN. When Web services are shared across security and identity domains or when the client application is a portal there is often a requirement to reconcile identity domains, provision PKI for certificate based trust, integrate with an existing single sign on infrastructure, enable non-repudiation and manage policy change between a Web service and client application. Doing this manually while possible is complex. For this reasons some vendors also offer an XML VPN product for automating client security and coordination.

This article examines how and when to deploy XML firewall and XML VPNs to deliver total XML and Web services security for SOA based infrastructures.

XML Firewalls: A First Step

Taking their cue from the Web world, technology vendors have developed XML-specific firewalls to address the unique security challenges of XML and Web services. XML firewalls are designed to examine and evaluate the XML content of the incoming traffic and, based on that evaluation, perform an appropriate security action. That action may require routing the message to a designated end point, transforming the message based on its content, validating a signature, decrypting a field or blocking access to certain operations. Sometimes, these operations are accelerated through specialized ASIC accelerators.

XML firewalls typically resolve an incoming message to a specific target Web service either by examining the SOAP message header or, with native XML, the HTTP header. Once the target Web service is resolved, the XML firewall can apply a stored security policy based on the target address, originating caller identity, message content and, in some cases, the successful execution of prior policies. Most XML Firewalls can also examine elements of the message body like fields, parameters, and attachments. As part of Web service lifecycle management, several XML Firewalls also auto-generate virtualized WSDL views of back-end target Web services to simplify versioning, addressing and SLA-based operations.

Page 1 of 2.