First published by IBM developerWorks at http://www.ibm.com/developerWorks. Visit ibm.com/ developerWorks for more tutorials on open standard technologies , IBM products, and more.
A case study
Sam Thompson, jStart Program Manager for Web services, IBM
01 Apr 2003
This article describes how the emerging WS-Security standard was used to secure a Web service
that was developed and deployed in the fall of 2002. The article will discuss the security-related
requirements of the Web service and how they were met using a combination of HTTPS/SSL, digital
certificates, and digital signature technologies. The article will crawl through the WS-Security element
of the SOAP message used to trigger the Web service, explaining each section of the WS-Security
element in detail. After reading this article, you should have a better understanding about how you
can use WS-Security in a production Web service application and feel confident about using this
emerging standard in your own projects.
Web services security - ready to do business
Over the past couple of years, Web services has gone from being an overly-hyped technology to
one that many organizations are using productively. The early implementations, like all new technology
projects, tended to be sandbox-type efforts or projects that were small, inside the firewall, and
non-mission-critical in nature. Those brave souls that tried to venture into the world of delivering
Web services over the Internet found that they either had to provide services that were open and
available for use by anyone (for example XMethods or Amazon) or had to develop their own,
typically proprietary, very company-specific, security scheme.
Early adopters using the Internet as their transport typically used some form of registration process
(for example Google) for open Internet services or only provided services to a small number of
business partners with whom they already had a tight, trusted relationship. For example, in order
to use Google’s Web service-enabled search engine, the service requester must first register with
Google through an HTML based form. As part of the registration process, Google sends the
requester an email with a security “token”. When the requester invokes the service, they provide
this token to Google as part of the SOAP message to verify that they are a registered, authorized
user of the Google Web service.
In these situations, even though service providers were using industry standards such as SOAP,
additional information concerning the security scheme/process needed to be provided in order for
the service requestors to be able to use the service. This had a rather undesired effect of tightly
coupling the requester and the provider, a scenario that wasn’t desired by either party.
The WS-Security Standard
Clearly an industry standard way of securing a Web service was required, and IBM, Microsoft, and
VeriSign responded to this need in April, 2002. From the WS-Security specification (see also
“WS-Security describes enhancements to SOAP messaging to provide quality of protection through
message integrity, message confidentiality, and single message authentication. These mechanisms
can be used to accommodate a wide variety of security models and encryption technologies.
WS-Security also provides a general-purpose mechanism for associating security tokens with
messages. No specific type of security token is required by WS-Security. It is designed to be
extensible (e.g. support multiple security token formats). For example, a client might provide proof
of identity and proof that they have a particular business certification.”