Over a million developers have joined DZone.

Security Coordination for Web Services Beyond XML Firewalling

· Integration Zone

Build APIs from SQL and NoSQL or Salesforce data sources in seconds. Read the Creating REST APIs white paper, brought to you in partnership with CA Technologies.

[This article was written by Sean.]

This is the second of our From the SOA Security Vault series of blogs. These cherry picked blogs written over the last decade represent some of the most influential musings from our CTO, Toufic Boubez, on the topic of security and governance in software oriented architecture. These blogs provide a peek into the thought process of Toufic while he was co-editing the W3C WS-Policy specification, and co-authoring the OASIS WS-Trust, WS-SecureConversation, and WS-Federation submissions. During this period he was also participating on the OASIS WS-Security, SAML and UDDI Technical Committees. This article, written back in 2004, explores the challenges of web service security in a pre-NGFW world.

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-level analog, 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 its 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 these 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 single sign-on, PKI identification protocols, or external policy stores, 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 analog 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 outnumbers the security permutations available when negotiating IPSec VPN or SSL Web communications.

Possible considerations include credential choices and how they are to be passed; where a signature needs to be added inside a message body; what part of the message needs to be encrypted; whether PKI certs are required; how they are provisioned; what schemas are acceptable by the receiving application; how SOAP messages are sequenced to avoid replay attack; whether message exchanges are 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 transactions. 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.

The Integration Zone is brought to you in partnership with CA Technologies.  Use CA Live API Creator to quickly create complete application backends, with secure APIs and robust application logic, in an easy to use interface.


Published at DZone with permission of Jenny Yang, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}