Deploying XML Web services in the enterprise has many compelling advantages. Web services provide a powerful foundation for building loosely coupled distributed applications and service-oriented architectures (SOAs). Enterprises use Web services to lower the integration cost of business-to-business solutions, allowing partners to share business documents without custom coding.

Web services flexibility comes with risks: Sensitive business data may end up in the wrong hands. Web services providers may be flooded by XML denial-of-service (XDoS) attacks, preventing legitimate users from gaining access. Business documents may be forged or altered, resulting in fraudulent transactions.

In this article, I'll discuss the security considerations for building Web services in a suspicious world - the dangers of working in this world; some old, some new. I then review the technologies that may be applied to address Web services security, along with the significant challenges when using these technologies. I conclude with recommendations on a security architecture that relies on an XML Web services security gateway as the first level of defense for Web services.

The Dangers
Because much of the value of Web services is about connecting sensitive systems together, the underlying risk is quite clear: wide sharing of valuable data leads to more exposure of that data. If we examine this issue more closely, however, we see that data sharing using Web services leads to new risks that are not so obvious.

Where's the Perimeter?
In the world of client/server and operating system security, we have the concept of a trusted computing base (TCB). The TCB consists of the hardware and software mechanisms that are responsible for enforcing the security policy, which defines when a user may access a resource. The TCB creates a security perimeter - valuable resources are protected within the security perimeter, and users must authenticate and pass authorization checks before they are allowed to access data within the perimeter.

In this model, the security perimeter is easy to understand. Bad guys and good guys are outside of the security perimeter, and the TCB distinguishes between the two parties so that only the good guys can access the data within the perimeter. The whole point of a security perimeter is to make sure the bad guys do not get inside.

Figure 1 shows the typical example of this model when applied to Internet connectivity: the IP firewall.

For Web servers, IP firewalls accept or reject HTTP traffic based on corporate policy. It's common, for example, to establish a security perimeter by constraining HTTP traffic to a demilitarized zone (DMZ) in the enterprise and providing an access-control policy for protected resources. IP firewalls usually prohibit external HTTP traffic from entering the internal corporate network.

When we transmit Web services over the IP firewall the simple model of a security perimeter falls apart. XML and SOAP traffic most commonly travel over HTTP, which can be controlled by the IP firewall. However, unlike browser-based Web server traffic, XML and SOAP messages do need to get through to enterprise servers within the corporate network. If IP firewalls are configured to permit Web services traffic within the corporate network, then we have lost our perimeter. IP firewalls cannot distinguish between the trustworthy and nontrustworthy Web services traffic tunneled via HTTP. As a result, attackers could bypass firewall checks and gain access to sensitive enterprise data.

Web services don't have a clear definition of a security perimeter. Because Web services architectures are built from many different service providers distributed across different enterprises, there is no simple way to distinguish the good guys from the bad guys. It's difficult to tell who is trustworthy and who is not.

Consequently, Web services should be created as mutually suspicious islands. Every time a client uses a Web service, the client and Web service establish a trust relationship. Security is enforced at each link of the Web services chain rather than at a single security perimeter. The resulting architecture defines a layered security model where each Web service has its own layer of protection.

Next, we'll examine the security facets that are the basis of trust in the Web services world.

Security Requirements and Related Risks
Web services applications have the same basic information security requirements as any other computer system:

• Confidentiality: Safeguard user privacy and prevent the theft of enterprise information, both stored and in transit
• Integrity: Ensure that electronic transactions and data resources are not tampered with at any point, either accidentally or maliciously
• Accountability: Detect attacks in progress or trace any damage from successful attacks (security auditing and intrusion detection). Prevent system users from later denying completed transactions (nonrepudiation)
• Availability: Ensure uninterrupted service to authorized users. Service interruptions can be either accidental or maliciously caused by DoS attacks

When deploying any Web services application, you need to consider how to address each of these information security requirements. As you identify security mechanisms that will address the requirements for your Web services, you will encounter common areas of security risk, shown below. Since a Web services architecture defines service interfaces and associated messages sent to those services, the risk areas naturally fall into message, services, and interoperability-related risks:

• Message-related risks: Caused by potential compromises of the message content transmitted by a Web service. The risks include damaging ill-formed messages, message modification and eavesdropping in transit, and messages sent from nontrustworthy sources.
• Services-related risks: Caused by potential compromises of the Web service interface. The risks include access to the service by unauthenticated users, access of the service by unauthorized users, and unaudited use of services.
• Interoperability risks: Caused by potential mismatches of Web services implementations. The risks include vulnerabilities from lack of interoperability with currently deployed security products, and insecure application-to-application message exchange.

As you can see, there are plenty of risks to worry about when deploying Web services applications. Although the underlying security requirements are not new, the lack of a distinct security perimeter and the list of related security risks have resulted in the creation of new technologies that address the specific needs of Web services security. We'll discuss these technologies next.

The Technologies
Standards groups, particularly the Organization for the Advancement of Structured Information Standards (OASIS), the World Wide Web Consortium (W3C), and the Internet Engineering Task Force (IETF) have been very active over the past few years on security-related topics. Several specifications have been defined that together serve as the basis for Web services security solutions.

Security Building Blocks
The security of Web services relies on three key standards: Secure Sockets Layer (SSL)/Transport Layer Security (TLS), XML Digital Signature, and XML Encryption. SSL/TLS provides public key-based transport layer security that enforces confidentiality and integrity of message content. SSL/TLS is especially pervasive for Internet-based HTTP traffic, including Web services messages. XML Digital Signature specifies how to sign XML document elements to prevent tampering, while XML Encryption specifies how to encrypt elements to prevent disclosure.

The combination of SSL/TLS, XML Digital Signature, and XML Encryption go a long way toward addressing many Web services security requirements. Why aren't they enough? Although these standards are flexible and powerful, they are often too low level for convenient use. In particular, there are so many ways to enforce security with these standards that different uses may not easily interoperate without additional guidelines.

Upper-Layer Security
Built on the security building blocks we just described, the upper-layer security standards provide Web services security support in a more convenient package:

• WS-Security: Provides packaging for SOAP messages - it defines how to attach signature, encryption, and security tokens to SOAP messages.
• Security Assertion Markup Language (SAML): Defines the XML format for exchanging authentication, authorization, and attribute assertions; and includes the protocol for requesting this information from security authorities.
• Extensible Access Control Markup Language (XACML): XML specification for expressing access control policies.
• XML Key Management Specification (XKMS): Defines the interface for accessing keys and PKI servers using XML.

The Challenges
There are several technical challenges when assembling these technologies together to secure a set of Web services. In this section, we focus on three of the most significant: interoperability, performance, and preventing XML denial of service (XDoS).

Putting Together an Interoperable Security Solution
At this point you may have the impression that there are a lot of standards and technologies involved in Web services security, and that is certainly true. The main technical problem is not whether the appropriate Web services security mechanism is available, because it probably already is. Instead, the issue facing both vendors and customers is how to assemble an effective, simple, and interoperable solution out of the many available building blocks.

Figure 2 shows a typical layering of security mechanisms and protocols in support of a Web services deployment. As shown in the figure, the Web services sender and receiver are connected via an intermediary server, which could be providing infrastructure services such as message routing, or business-level services such as an e-commerce marketplace. We can see that HTTPS (HTTP over SSL/TLS) secures the point-to-point connections from sender to intermediary, and intermediary to receiver. Because SSL/TLS is transport-level security, it cannot by itself provide end-to-end security between sender and receiver. For example, SSL/TLS is inadequate if the sender needs to send encrypted data (say, a credit card number) that is not exposed to the intermediary. In this case the sender could use XML encryption and WS-Security to tunnel encrypted data through the intermediary to reach the receiver.

The Web Services Interoperability Organization (WS-I) is chartered to promote interoperability, and is working on providing guidelines for interoperability of Web services security. In particular, the WS-I Basic Security Profile Working Group is defining security scenarios and a security profile document to help enterprises piece together many of these standards to ensure interoperability.

Performance
Performance is often the most significant challenge when deploying Web services security solutions. We'll use Figure 3 to illustrate some of the performance issues you are likely to encounter. This figure offers an example of a typical set of processing steps that might be required to secure a SOAP/XML transaction. As the transaction is processed, it is parsed, its schema is validated, XPath filtering is applied, it is decrypted, and so on, until the transaction processing is completed.

The first thing to note about the example is the sheer number of security processing steps required. For Web services with security requirements that span the areas of confidentiality, integrity, accountability, and availability, this number of steps is not unusual.

In Figure 3 the numbers and colored bars show the relative computational cost of each processing step. The green bars represent the time spent in XML-related computations, such as parsing, schema validation, and transformation. The red bars represent the time spent in cryptographic-related computations, such as public key encryption and decryption. To give you an idea of the latency involved in one of these steps, an XML signature of a modest-size message using typical software-based implementations can take well over 100 milliseconds.

Although you might expect cryptographic processing to dominate Web services security processing, the example shows this is typically not true. Because XML is so expensive to analyze and transform, Web services security enforcement generally spends much more time performing XML processing than cryptographic processing.

As a consequence, it's important to realize that performance optimization for Web services security requires addressing both cryptography and XML acceleration. SSL and cryptographic hardware accelerators help speed up Web services security processing, but unless you also consider acceleration of XML processing you are unlikely to see significant performance improvement.

Finally, you should consider the additional security performance overhead due to the stateless nature of Web services. Browser-based Web server security can take advantage of a security session to optimize security. When accessing a Web server, the initial authentication step (for example, using a password or digital certificate) may be slow, but it happens only once per session, so the user experiences minimal delay. In contrast, every Web service transaction must be authenticated, so this performance penalty is paid on every transaction. The end result is a potentially lengthy fixed authentication delay built into the response time of every Web service transaction.

XML Denial of Service (XDoS)
One challenge that enterprises are only beginning to consider is XDoS. This concept may be new to most people, but experts agree that protecting against XDoS attacks will be a common issue as more Web services are exposed on the Internet.

Years of experience have shown that Web servers must be protected against DoS attacks. There are many variants on these attacks, such as the virus infections of huge numbers of consumer PCs with Trojan horse programs, which are then launched remotely at a later time to flood a target Web server host and bring it down. IP firewalls commonly contain countermeasures against these attacks by limiting the rate of traffic from an IP address and detecting hostile patterns of incoming messages.

The analogous XDoS attacks in the Web services scenario will be more serious. Because of the resources required to process XML, it is much easier for the attacker to create and transmit malicious XML than it is for the defender to process and reject the XML. XML supports rich and complex document structures, including recursion, which can potentially cause infinite loops during input processing. While IP-based DoS attacks usually require large numbers of messages, an XDoS attack can be launched on a Web service with a single 2KB malformed XML message.

Countermeasures for XDoS attacks are straightforward to define. For example, incoming XML should be schema validated to ensure that the XML conforms to a supported Web service interface. Message monitors may be installed to check thresholds on message rates, and content-based filters can be used to detect recursion depth and other complexity measures of the XML document.

Although XDoS countermeasures may be clear, their implementation is definitely a challenge. The only way to effectively deal with XDoS is to have a high-speed XML engine that can detect and dispose of these attacks before the server is overwhelmed. From our previous discussion, we have already seen that performance is a major challenge when deploying Web service security; the burden of XDoS detection compounds this problem. As in the case of IP firewalls that handle DoS attacks, it is sensible to consider an engine that offloads the Web service server from needing to handle this processing.

The Solutions
Web services security can be enforced in a variety of places in the architecture. In this section, I make some recommendations on the best approach to use. I discuss using an XML security gateway as the first level of defense, and then adding Web services application-based security as a second level of defense as needed.

First Level of Defense: XML Security Gateway
Based on the challenges I described previously, I recommend starting with a hardware-based XML security gateway as the simplest and most effective way to enforce Web services security. An XML security gateway is typically deployed behind an existing IP firewall, and secures all XML traffic before it reaches the Web service on the application server. A hardware-based XML security gateway has many advantages, including:

• Performance: An optimized hardware solution that addresses both XML acceleration and cryptographic processing will improve latency and throughput of XML security processing by a factor of at least 10 over software implementations. In many cases the performance improvements are considerably larger.
• Scalability: By deploying a high-capacity XML security gateway, the number of application server platforms may be significantly reduced. An XML security gateway can handle an increased Web services transaction load without needing to add additional application servers.
• Manageability: By channeling all Web services traffic through a small number of high-capacity gateways, the number of security enforcement points is reduced. This simplifies the security configuration and makes changes easier to manage.
• Simplicity: An XML security gateway can enforce the majority of Web services security requirements, thus avoiding the need to write security code within the Web service applications.
• Security: Removing security from applications is a best practice, and improves the security assurance of the architecture. As in the case of an IP firewall, an XML security gateway is a hardened security platform that protects potentially vulnerable application servers.
• Availability: XDoS is a significant threat to Web service availability. An XML security gateway provides high-performance XDoS checking to protect Web services applications.
• Interoperability: Web services security standards and technologies are a moving target, and will continue to evolve. An XML security gateway is a natural place in the architecture to translate across multiple transports and security standards.
• Monitoring: Because Web services traffic passes through the gateway, it provides an effective central enforcement point for audit logging and accountability.

Second Level of Defense: Web Services Application
Although the first level of defense for Web services belongs on an XML security gateway, there are important cases where it makes sense to have a second level of defense on the Web services application platform.

Both J2EE and .NET application server platforms have their own container-based security models. In existing component deployments, the application server security policy may be an important part of protecting the application. Legacy applications may also have business-specific security embedded with in. In these cases, it is possible to integrate the security enforced at the XML security gateway with application server security. In particular, security context information that is authenticated at the XML security gateway and based on Web services standards such as WS-Security and SAML may be used to enforce authorization and audit policies on the application server.

Deployment
The most common deployment of an XML security gateway is as a proxy within the enterprise DMZ (see Figure 4). In this configuration, the XML security gateway protects the application server against Internet-based XDoS attacks and enforces incoming access control, including authentication and authorization. The XML security gateway may also be deployed as a proxy to protect access within the corporate intranet.

For a more advanced deployment, the XML security gateway may be installed on the Web services client side. In this scenario, the gateway provides outgoing access control, limiting the transmission of sensitive data to the Internet. The gateway can also be used to secure a federated extranet, where the Web services client and server environments do not share common security policies and mechanisms. To address federated extranet security, the XML security gateways can use SAML as a common standardized security token to map client-side security policy to server-side security policy.

Conclusion
This article described many of the issues that need to be considered when deploying an enterprise Web services architecture. The traditional concept of a single security perimeter does not apply to the loosely coupled concept of Web services. Instead, I advocate viewing Web service applications as mutually suspicious islands that need to establish trust before communicating to a partner application. Mutual suspicion means that there is no central point of trust in the architecture. XML security gateways protect each Web service application and establish trust; in this manner, a security architecture is defined by the network of XML security gateways and application servers.

I described a number of security challenges when assembling a Web services security solution. The first is interoperability; the existing standards are complex and still evolving, so it's difficult to ensure that your Web services security implementation will interoperate with your partner's. Future guidelines from groups like the WS-I Basic Security Profile Working Group will help you through this process. In the meantime, an XML security gateway can serve as a translation point between incompatible security technologies, and evolve as your requirements change.

The other major challenge of Web services security is performance. I described the close relationship between security and performance, which is due to the large processing burden of XML as well as the additional processing load caused by XDoS attacks. An XML security gateway has the processing capacity to handle XML security traffic quickly and efficiently.

• WS-Security Just Became an OASIS Standard

• Figure 1
• Figure 2
• Figure 3
• Figure 4