Fact is, much of the security infrastructure needed by Web services already exists. However, while it's important that enterprises leverage their current capabilities to address new security requirements, serviceoriented architectures pose a new set of challenges that are not fully addressed by traditional security measures.

Inherently Open and Vulnerable
Web services simplify the loosely coupled integration of distributed, federated systems – systems that have been implemented with open APIs. What's more, Web services send machine- and human-readable messages that fly across the Internet. Print out an XML message and your niece could read its content. The point is, Web services–based systems are much more vulnerable to eavesdropping.

Security Distributed within the Perimeter
HTTP requests with any type of payload can easily tunnel through corporate firewalls to interact with sensitive data within the enterprise. That's why it's not enough to monitor network packets. It is also insufficient to assume that once a Web service request gets past the perimeter of the enterprise it has a legitimate right to access any corporate system within the firewall. Think of your enterprise as an office building. Some people aren't allowed in the front door. Others are permitted to enter the main lobby but cannot access specific floors. Some can access a floor of the building but not the offices on that floor. You get the picture. It's much the same with Web services. Due to their inherent openness, they require security at the perimeter of your enterprise as well as anywhere it is needed within your network to ensure that only authorized requests are met. They demand renewed focus on the way application-level security concerns are addressed, combining traditional forms of security with new approaches to authentication and authorization, securing exposed interactions, and ensuring transport integrity.

End-to-End, Not Point-to-Point
Existing solutions provide point-to-point security. For example, SSL/TLS offers such features as authentication, data integrity, and confidentiality for secure point-to-point sessions.

Problem is, Web services aren't designed for point-to-point sessions. With service-oriented architectures, the SOAP message model operates on logical endpoints that abstract the physical network and application infrastructure and, therefore, frequently incorporates multiple hops with intermediaries. As SOAP messages are sent from an initial requester to a service, intermediaries might intercept them to perform such functions as routing, requesting additional data, modifying the message, encrypting or decrypting portions of the message, or adding security tokens.

The challenge, then, with such distributed environments, is ensuring that intermediaries do not invalidate message integrity, violate the trust model, or destroy accountability. Most serviceoriented architectures require end-to-end security across multiple intermediaries – both inside and outside corporate boundaries. So, while SSL might suffice for point-to-point security, it does not offer adequate protection for the privacy and confidentiality of sensitive data that is passed between multiple Web services.

Integrated, Abstracted, and Based on Standards
Securing Web services calls for unifying concepts. It requires solutions to both technical issues, such as secure messaging; and business process concerns, like policy, risk, and trust. And it demands a coordinated effort from platform vendors, application developers, network and infrastructure providers, and customers themselves.

Appropriate standards organizations are hashing out the emerging security model and security-focused specifications such as WSSecurity, XML Signatures, and XML Encryption (see Table 1), which will be broadly available from multiple vendors. Together, the model, specifications, and standards process will enable businesses to quickly and costeffectively increase the security of their existing applications and confidently develop interoperable and secure Web services.

Web services are designed to simplify the integration of disparate applications, transports, and platforms, each of which might have their own security implementations. However, such islands of security are limited to their respective arenas. Furthermore, as new Web services are deployed to meet new business requirements, the burden of building the security for each new SOAP interface from scratch would quickly become prohibitive. Instead, organizations should consider adopting an overarching security abstraction layer that enables them to set security policies, create security services, and provide multiple levels of authentication, authorization, and encryption. By abstracting security, an organization need not concern itself with what type of security technologies its partners are using. It would need to know only that its partners have adequate levels of security, such as encrypting sensitive transaction data. Furthermore, security abstraction creates platform independence, enabling a business with a heterogeneous computing environment to define access control policies centrally for implementation on each platform, rather than managing policy for each platform independently.

Take an Evolutionary Approach
Most organizations already have a security infrastructure in place. Rather than starting anew, it's prudent to leverage that infrastructure as much as possible and add new security capabilities to address the specific needs that Web services bring. This evolutionary approach fosters the creation of secure, interoperable Web services based on a set of security abstractions that enable the integration of formerly dissimilar technologies. For example, you might add message-level integrity or persistent confidentiality (by encrypting message elements using XML Encryption) to an existing Web service whose messages are carried through SSL/TLS. Thus, messages have integrity (and confidentiality) that persists beyond the transport layer. This enables specialization within an overall security framework to suit specific customer requirements while at the same time permitting incrementally deployed, evolutionary technologies.

An integrated security infrastructure must therefore offer distinct security services for Web services to consume. Every customer and every Web service has its own unique security requirements based on their business needs and operating environment. Within workgroup settings, for instance, simplicity and ease of operation are top concerns, while for publicly accessible Web services the ability to withstand concerted denial-of-service attacks is a higher priority.

Different services require different levels of security, from passwords to digital certificates. For example, an organization might build password- based authentication services for its internally accessed inventory service but might use digital certificates–based authentication for the order-entry Web service its partners use.

These requirements may be combined in many ways and expressed at different levels of specificity. A successful approach to Web services security requires a set of flexible, interoperable security capabilities that, through policy and configuration, enables a variety of secure solutions. In this way, organizations can achieve security strategies that are appropriate for them.

Content is Key
XML messages come with rich payloads of information and provide a standard, structured format for accessing content. For that reason, Web services bring an unprecedented ability to harvest real-time data and apply that information to such things as security.

Additionally, Web services systems can leverage contextual information – who's accessing the data, what are their access rights, and what type of client device is the person using, to name a few examples. By using profile data in conjunction with business content, a business system can grant user-specific, content-specific, read and/or write access to a Web service. By interacting with the existing authentication system, it can dynamically tailor responses based on each user's most current security profile and the content of the request.

Here's an example. A company that employs an order-processing Web service might design its system so that its business partners can enter orders up to $100,000, but that orders exceeding $100,000 must be entered by internal staff. Accomplishing this requires making use of in-flight message content (order value) and context (client identity).

Multi-Vendor Cooperation
To be clear, Web services security is a tough knot. Designed for distributed, federated, heterogeneous systems, the new application architecture raises security issues that no single vendor can solve. Businesses should expect to work with application, operating system, management, and security companies to implement an effective and comprehensive security solution. If that sounds like a real headache, you'll be glad to know that thanks to an unprecedented level of cooperation among software companies, such multi-vendor solutions will interoperate seamlessly. Web services has been a tremendous catalyst to collaboration. It has brought the industry together to address age-old security issues as well as several new concerns, in the quest for an interoperable, standards-based framework on which companies can run business-critical applications. As a result, new security standards (see Table 1) and solutions will soon help corporate IT teams clear the last remaining hurdle to easily deploying trustworthy, production-ready Web services.

About the Author
Gene Thurston serves on the Web services security council for OASIS. He has more than 22 years of software industry experience, the last 10 of which have been dedicated to computer security. Gene is the security architect for AmberPoint, a leading Web services management solutions company. Core to the AmberPoint product suite is a strong policy-based authorization system that enables organizations to use identity, XML content, system state information and many other factors to produce permit/deny authorization systems. gthurston@amberpoint.com