Traditional development produces applications that are closed to wide usage. Custom development is required to open these programs to wide-scale integration. In contrast, Web services applications are by default open to other systems and additional configuration is required to block access.

The Challenge of Web Services Security
A growing share of the Internet marketplace is being turned over to Web services. Studies have shown that by the year 2006 a full 25% of all network traffic will make use of XML-based Web services. As with every new technology, the increased convenience comes with new security considerations. The challenges involved in the deployment of Web services must be overcome efficiently to keep business transactions secure and reliable.

The nature of Web services is such that transactions may span multiple systems with various security domains, identity systems, and many transport segments. Confidential data must be kept secure from external threats and authorized access while enabling access by and communication with trusted client applications. XML firewalling provides a portion of this functionality. Like their network-evel analogue, XML firewalls allow security administrators to define security policies for inbound messages but at an XML application level. However, they don't address the problem of equipping trusted client applications with the information necessary to enable access and communication.

Web services require a security context managed, coordinated, and propagated within a distributed architecture spread across multiple systems involving several trust domains that come together in a just-in-time format. While appearing untenable, these security coordination requirements are not particularly extraordinary. They simply need to be approached appropriately to overcome the unique bi-directional challenges of application integration and Web services more specifically.

Transport-Level Security Is Not Enough
Systems using SSL or VPN technology are used to provide online security. Creating a secure pipeline protects data effectively from one point to the next in transit. However, the message is vulnerable at each stop from the source to the final destination.

Transport-security implementations are excellent at providing just that, security during the transmission portion of an online transaction. The transactions in a Web services implementation use a spanning architecture to bridge technologies. Often a deployment will make use of multiple applications, traverse diverse transport mechanisms, and cross between "identity" and "trust" domains. In each of these scenarios there is a gap in the security of SSL or VPN solutions.

The security provided by a transport-level implementation ignores the content of the message itself. Using XML there are many ways to attempt to pass an invalid message. The message must undergo XML schema validation, a multipart message integrity check, address normalization, two-way authentication, and other processes in order to ensure that only proper messages are transmitted. This is important because, for example, a properly compromised XML schema can result in a denial-of-service from the provider. Authentication is required to ensure that the data in any section of the message is from a trusted source. If the data that is sent is invalid or malicious, protecting that data against attack en route is ineffective. Effective security must perform message-level checks to deal with these and similar difficulties.

SSL and VPN implementations have their niche and provide good security for certain applications. Transport-level security protects data during transmission, but providing Web services is much more than just transmitting information. With all the hazards that the open architecture of Web services encompasses, a different approach is necessary to provide good security.

XML Firewalls: A Starting Point for XML Security
Because of the unique hazards, challenges, and audit requirements represented by communicating XML formatted messages, Web services technology vendors have borrowed a page from the Web world and created XML firewalls. XML firewalls are designed to examine the XML content of the incoming traffic, understand the content, and based on that understanding, take an action - for example, routing the message to the appropriate end point or blocking it entirely.

XML firewalls typically work by examining SOAP message headers. The header may have detailed information put there specifically for the firewall to examine, or might have information about the recipients of the message, about security of the overall message, or about the intermediaries through which the message has passed. In addition, XML firewalls can look into the body of the message itself and examine it down to the tag level. It can tell if a message is an authorized one, or if it originated with an authorized recipient. XML firewalls can also provide authentication, decryption, and real-time monitoring and reporting.

Although the firewall takes care of enforcement, it is still up to the firewall's administrators to define rules or policies that describe when to accept messages, when to reject them, and what, if any, other operations to perform. These policies are typically written from the perspective of blocking all access to a protected service unless the messages conform to the policy. This is a key point since although the XML firewall can remove the need to program security logic into the application it is protecting, it does nothing to address applications attempting to access those protected services. In other words, any application attempting to access Web services on the other side of the XML firewall must be programmed to ensure that their messages and credentials will conform to the policy in place. If not, they will be blocked. While this approach could conceivably provide excellent protection for the firewall owner, there are significant security or administrative compromises that result.

The Need for a New Kind of Security
The security provided for Web systems incorporates many of the current security concepts, but they need to be adapted to be appropriate for the environment. Naturally the system needs to be secure, which means dealing with the unique strengths and new weaknesses that are a part of Web services schemes. On top of the need for solid protection there is the demand for adaptability and flexibility to accommodate change and new developments in the technology.

By design, Web services provide a customizable range of security. The message has to contain the security context in order to be readable by the implementation at the receiving end. The security at each hop in a transmission route needs to be coordinated to maintain message privacy while enabling successful delivery. Using the flexibility of XML in a Web services implementation brings with it distinct security threats. The additional extensibility of the language makes it more prone to malicious abuse by a clever attacker. As a result, a good implementation needs to make use of message-level auditing to ensure that the messages that are passed are sound.

Interoperability between standards-compliant implementations is key to an effective Web services deployment. However, as a result of the newness of the technology, the standards are still evolving. Consequently the security implementation needs to be easily adaptable to be able to accommodate the changes required by those maturing industry standards.

In addition to external interoperability, the security technology used must also accommodate the existence of prior applications. A successful solution fits with the existing enterprise security infrastructure with respect to techniques such as a single sign on, a PKI identification protocol, or accommodating an external policy store, performance monitoring, and load balancing systems.

Another feature of Web services is the just-in-time approach to business processes. Security has to be implemented and managed flexibly to facilitate this time-sensitive form of integration. The time-consuming reconfiguration of a hard-coded system can greatly impinge upon response time to a change in trust relationships or standards compliance.

To meet the changing needs of Web services, a good security solution needs to be conveniently manageable, flexible, and extensible. In order to be a useful implementation the policies governing the security protocols need to be customizable to the specific challenges of a particular service. Those policies also need to be coordinated on both sides of the integration to accommodate changing business relationships and the individual security requirements that go along with them. All of this points to the fact that Web services needs a new approach to security, one tailored to the particular needs and strengths of the technology.

Beyond XML Firewalling
Web services transactions can span multiple security and identity domains. This requires that a Web services security solution contain technology to restrict access to exposed services from external threats and unauthorized access. However, threat protection and access control while necessary are not sufficient for Web services security. Since interacting Web services must agree on integration parameters before the first XML message is exchanged there is also a need for coordination of security parameters. For VPN technology this coordination of security parameters happens automatically through in-band negotiation between VPN clients and VPN Gateways. On the Web, a similar kind of negotiation also happens automatically in the background between the browser and Web server. This way, crypto parameters like key length, cipher type, credential preferences, and protocol versions get negotiated automatically at the beginning of each session without any programmer involvement on the client or server end. There is no analogue to this kind of capability for Web services today.

XML firewalls alone don't address the problem of client-side security coordination. They focus on blocking functions for XML messages entering a restricted security zone. But like VPN and the Web before it, systems exposed as Web services that are to exchange data or be integrated must first have their security preferences aligned consistently. This challenge is even more acute for Web services than for VPN or the Web since the number of security permutations available at an XML message level, far outnumber the security permutations available when negotiating IPSec VPN or SSL Web communications.

Possible considerations include credential choices and how they are to passed, where a signature needs to be added inside a message body, what part of the message needs to be encrypted, are PKI certs required, how are they provisioned, what schemas are acceptable by the receiving application, how are SOAP messages sequenced to avoid replay attack, are message exchanges to be time stamped and reconciled to provide nonrepudiation, what CA will provide the signing authority for a SAML identity assertion, do certain message fields or parameters need to masked, encrypted or translated before leaving a security domain for regulatory reasons, are SSO tokens required, what version of WS-S will the applications conform to, is WS-SecureConversation required for the transaction and many others. Because of the open-ended, extensible nature of Web services, this list of security options is quite long. Unfortunately, today the only way for a sending application, i.e. a Web service, to communicate its security capabilities and expectations to a client application is by having the sending application's developer communicate this out-of-band with the receiving application's developer using e-mail or the phone. WSDL is silent on the subject of security. Even when WSDL starts to accommodate security descriptions, it is a static API protocol. Changes in security requirements and expectations can't be automatically updated on the client system without considerable developer effort. So even a small task like upgrading a Web service to a new version of WS-Security becomes a difficult coordination, development, and testing process.

A Web Services Security Coordination Model
XML firewalls provide a critical element in a broader Web services security strategy. But XML firewalls alone are not sufficient given the "integrated" nature of Web service transactions. There is also a requirement for coordination of security preferences between systems participating in Web services transaction. Ideally this coordination is dynamic so that changes on one or more systems can be automatically accommodated without developer involvement.

One possible model would comprise an XML firewall plus a client-side technology for distributing security workload to and coordinating security preferences with client systems. Like VPN security, the client-side technology should be either software or hardware depending on provisioning preferences. There should also be a purely developer-oriented option for customers uncomfortable with any client footprint. Besides coordinating policy, the client-side technology should provide other value functions for a Web services transaction like SSO integration, PKI provisioning, and identity bridging. The service-side and client-side components of this architecture could then be coordinated by exchanging what amounts to a policy document outlining their security preferences, terms, and conditions for the transaction. That way changes in policy in one system get automatically negotiated with the others preserving loose-coupling.

In combination with an XML firewall this kind of client component can provide organizations with a security model that can span transactions both inside and outside the traditional corporate security boundary. From a cost and time-to-market perspective, a client-side element that can negotiate on-the-fly with an XML firewall saves considerable developer effort and time. It also removes the usual error and consistency risk inherent in a programmed model of security provisioning. While this kind of two-way security model is not universally appropriate, it can prove extremely beneficial in many Web service integration scenarios.