In survey after survey, security is the most frequently cited barrier to developing distributed applications using Web services technology. In some cases, the findings indicate that the overall level of security concerns among information technology professionals appears to be increasing (Evans Data). Yet in spite of these trends, enterprise adoption of Web services technology is clearly accelerating. Smart organizations recognize that they must move forward with Web services deployments - employing a variety of security tactics - to avoid the greater risk of being left behind as their competitors embrace and benefit from Web services technology.

SOAs have been held out for years as a substantially more cost-effective and flexible strategy for architecting enterprise software systems than historical approaches including monolithic system design and tightly coupled client/server models. Many enterprise CIOs and industry observers believe Web services technology, and widespread vendor support of these standards, will enable the widespread adoption of SOA.

There is clear evidence that not only is adoption possible, but that it is well underway in the Global 2000. It's impossible to ignore the daily drumbeat of case studies, articles, and speeches from CIOs declaring their adoption of Web services-based SOAs as funded, high-priority strategic IT initiatives. Gartner Group predicts that SOAs will move to the mainstream in 2003 because "the fact is that Web services are pivotal to future actively managed, flexible and responsive enterprise architecture. It is not possible to sit back while competitors explore this territory without risking that they will open a strategic business lead [companies] will find hard to close."(Gartner)

The reasons for forging ahead are compelling. Nonetheless, security concerns must be adequately addressed to ensure the success of these projects as well as overall systems integrity. A clear pattern is emerging for how to best deal with the issue of Web services security.

Ensure that security is modular and pluggable. One fact is incontrovertible - security models, protocols, and techniques will evolve. The key to ensuring that a system can evolve with them is to isolate and make pluggable the code that enforces security policy. By separating security policy enforcement logic (authentication, authorization, privacy) from Web service business logic, it is easier to enhance the security model to meet more sophisticated security requirements over time. The vast majority of Web services implementations today are secured via HTTPS. In fact, this is the only model endorsed by the WS-I in its Basic Profile (currently in draft form), which aims to ensure Web service interoperability. In the future, systems must evolve to adopt emerging standards such as WS-Security and SAML if they are to participate in more complex - and more interesting - Web services usage patterns.

Stage the introduction of Web services technology to mitigate the complexity of the security problem. Most organizations are adopting Web services technology in bite-sized chunks, identifying projects that are limited in scope and low risk, but high in potential payback if successful. These "low-hanging fruit" initiatives allow the organization to gain experience with the technology and to assess its viability for more widespread and sophisticated deployment. As a side effect, they also tend to contain the complexity of the security problem. The vast majority of initial Web services projects are internal and often limited to a single security policy domain. Moreover, service consumers and providers tend to communicate directly instead of through chains of active SOAP intermediaries.

Leverage proven Web-based security models for initial projects. By limiting the complexity of the security problem in early deployments, it's possible to use existing security tools and techniques. HTTPS is a mature model for channel-based security. In initial projects, channel-based security is often sufficient to ascertain the identity of the consuming application and to ensure message privacy and integrity. Leveraging these existing and familiar investments means one less learning hurdle for the organization to jump as it adopts Web services technology. And as noted before, HTTPS is the only WS-I Basic Profile 1.0-endorsed security mechanism and therefore the only guaranteed path to interoperability with WS-I-compliant implementations.

Embrace emerging standards as tools and vendors support them and as architectural complexity requires them. As organizations mature in their use of Web services, existing security models, protocols, and tools fall short. Emerging standards, such as WS-Security, aim to fill the holes exposed in existing standards (federation, policy, trust) in the light of complex Web services usage scenarios. Implementations of proposed standards are just beginning to find their way into vendor offerings.

Security concerns are not a reason to delay the introduction of Web services technology into the enterprise. Successful IT organizations are employing this technology to solve real business problems and to gain competitive advantage. Ensuring implementation flexibility and taking a "walk before you run" approach to Web services adoption will ensure that systems are both secure today and poised to be secured in more complex deployments in the future.