Concerns about security are cited as the single largest barrier to rapid Web services adoption. Yet most Web services today are fairly straightforward point-to-point integrations that can be securely implemented using only digital certificates and the Secure Sockets Layer (SSL) protocol.

Regardless of security strategy, enterprises are well advised to monitor their Web services to ensure security has not been compromised. Taken together, widely available standard security technologies and active monitoring provide a sensible approach to the majority of today's Web service security challenges. This article describes how to use these technologies to secure the most common deployments of Web services quickly and easily. I'll close with a brief introduction of WS-Security and how this emerging standard relates to what you do and do not get with SSL.

Web Services Security in Perspective
When considering what will be needed to enable a ubiquitous service-oriented architecture (SOA) in the next 3-5 years, the security challenge looks daunting. The WS-Security standards that specify security infrastructure that will allow the safe delegation of trust and identity are still evolving. The maturing of these standards is a necessary step toward the realization of a true service-oriented architecture. However, if we step back and focus on how Web services are really being utilized today, we find that practical, secure deployments are possible now. In contrast to the fully distributed applications of the future SOA "nirvana," most of today's Web services are simple point-to-point integrations.

As the name suggests, Web services can be seen as a logical evolution of the previous generation of distributed computing - the World Wide Web. It should thus come as no surprise that much of the security infrastructure developed for the browserbased Web is directly applicable to the realm of server-to-server Web services. Indeed, the combination of well-known Internet security technologies and best practices for monitoring security compliance are the primary requirements for securing today's initial Web service deployments.

Web-enabled business-to-consumer (B2C) commerce provided much of the impetus for the development of the SSL protocol and digital certificates. B2C commerce required confidentiality and integrity for the communications between a consumer running a browserbased client, and the front-end application server responsible for facilitating the transaction. Authentication of the server was also critically important to ensure that the consumer could trust the party requesting personal and confidential information such as credit card numbers.

In the case of Web services, the need for confidentiality and integrity are similar, but because the primary communications are server-to-server, the requirement for authentication is truly symmetric. In addition, new monitoring requirements arise because Web services applications are capable of exposing strategic business assets. Information sharing provides leverage and business advantage to partners as long as that communication is secure. As enterprises make their information assets more widely accessible internally and externally they must be sure that strategic information is available only to authorized parties.

Securing Point-to-Point Web Services
As I stated earlier, the most common external Web services being implemented today are point-to-point. The key security requirements for this type of Web service are authentication and confidentiality. Authentication ensures that the Web service client and server are known to each other. Confidentiality ensures that data exchanged between the parties are kept secret and intact. In some cases, integrations within the firewall must be simi- larly secured due to concerns about the critical nature of the assets accessed through a Web service, or regulatory requirements. In fact, Gartner has found that $1trillion has been lost by corporations due to theft of company information. These security requirements can be met using proven and familiar technology, namely the SSL protocol and digital certificates.

Consider a fictional retailer, Gargantuan Books, which would like to offer its resellers the ability to check stock and pricing using Web services. The security of Gargantuan's systems and data is critical to the success of the Web services initiative. Gargantuan needs to know which resellers are accessing which Web services and that communications between Gargantuan and its resellers are being kept confidential.

The StockCheck and PriceCheck Services
Gargantuan decides to provide all its resellers with the ability to check book availability via the StockCheck Web service. Gargantuan's gold-level resellers will be allowed to check both availability and pricing via a special Web service, the PriceCheck service. Both services take a unique identifier for the book (its ISBN) along with the number of copies being requested; they return a stock status of OnStock, Partial, or BackOrder. The PriceCheck service also returns the price to this reseller for the book. Resellers plan to use these services to provide store clerks and online customers with book availability and pricing information.

Gargantuan creates these Web services and provides its resellers with the WSDL description shown in Listing 1 .

Securing the Services
At this point Gargantuan's Web services are not secure! Any application with access to the Internet could call them at

http://www.gargantuanbooks.com/ws/Reseller.asmx

and check Gargantuan's stock and pricing. In order to secure them, Gargantuan can activate mutual (aka symmetric or "2-way") SSL on the Web servers exposing these services. Using SSL involves (1) procuring a digital certificate for the computer running the Web service, (2) toggling the SSL handshake configuration setting on the Web server to require client authentication, and (3) procuring digital certificates for the computers that will be the clients of the Web services (see sidebar, "How SSL Works").

Procuring and Enabling Digital Certificates
Digital certificates for SSL can be acquired quickly, simply, and cheaply from various public Certificate Authorities (CAs) such as VeriSign, GeoTrust, and Comodo. A wizard on the Web server guides the entire process from initial application to final X.509 certificate install on the computer. Once installed on both ends of the communication, the SSL request-response protocol for two-way authentication is fully automatic for Web services, just as it is for one-way, browserserver interactions.

So, Gargantuan procures a digital certificate for the server running the Web service, sets the SSL handshake configuration setting on the server to require client authentication, and informs its resellers that they must procure digital certificates for the computers that will be clients of these Web services. Gargantuan now safely provides these services at

https://www.gargantuanbooks.com/ws/Reseller.asmx

(Note the https: prefix, that 's' indicates SSL.)

How Secure Are StockCheck and PriceCheck?
Gargantuan has met most of its security requirements by setting up mutual SSL. Not only does the server authenticate itself to clients but clients are required to authenticate themselves to the server as well. Clients without valid certificates cannot access the service and communications between Gargantuan and its resellers are protected by strong encryption (see sidebar, "Procuring and Enabling Digital Certificates").

This is an adequate level of protection for many Web services; however, as with any security scheme, abuses can still occur. Gargantuan needs to monitor its Web services in order to detect and respond to abuses. Just as banks need surveillance cameras alongside hardened vaults and security guards, Gargantuan needs an active monitoring solution to monitor the performance of its security measures and to provide key information in the event that there is a security issue. Active monitoring is essential regardless of the security approach used.

Monitoring and Enforcing Security
In order to monitor security, Gargantuan needs to be able to "see" the identity of the clients accessing each of its Web services. It is not enough just to know that a certain client accessed the server; Gargantuan needs to know that only Gold authorized resellers are accessing the PriceCheck service. To demonstrate how this can be done, we'll continue our example using a specialized Web services management tool to monitor security for Gargantuan Books.

A powerful Web services monitoring tool enables companies to quickly isolate and resolve run-time issues, including security problems. Typically, a tap or sensor is placed at each Web service end-point in the flow of messages that monitors all Web services. With this highly scalable and low-overhead architecture, all service requests and responses are completely visible. We can monitor the security of all Web services, alert operators of security problems, and record detailed information for use in resolving security issues.

Web Services Monitoring Is Different
Due to the self-describing nature of Web services thanks to WSDL and XML Schemas, Web services monitoring tools can discover what Web services are running by reading all appropriate WSDL files. In this way the tools can then present monitoring information using the language defined by the Web services themselves.

When a Web service client first accesses a Web service, the monitoring tool detects the "establish session message", which contains the identity of the client from the SSL handshake. It can then monitor and analyze all elements of the Web service stream, including client identity. It logs the information for later analysis and generates alerts to service operators and systems management applications. In this case, Gargantuan wants to log the identities of all clients attempting access, alert a security officer when unauthorized clients attempt to access services, and record detailed information on all unsuccessful access attempts.

Gargantuan can not only monitor and enforce its security policies, but can also monitor the performance and availability of its Web services, diagnose service problems, and gain real-time visibility into the business activity flowing through its Web services network (see sidebar "Monitoring Web Services Security").

How Secure Is StockCheck Now?
The combination of secure communications via SSL and active monitoring has secured Gargantuan's point-to-point Web services. The services are secure - Gargantuan and its resellers are authenticated - and all communications are protected by strong encryption. An active monitoring solution is essential to ensure that security is maintained: all accesses are logged for later analysis and failed access attempts generate security alerts. As an added bonus, Gargantuan is able to address other operational challenges and gain business insight from its Web services stream.

Beyond SSL-Secured Point-to-Point Web Services
The security story for Web services by no means stops here. As we progress beyond today's point-to-point Web services, SSL will not be enough. We will need messagelevel security. The building blocks for message- level security are XML Signature and XML Encryption.

XML Signature supports the security principles of integrity and nonrepudiation. XML Signature is a W3C standard that can be placed inside an XML document or it can refer to external elements that are signed. It is important to be able to just sign part of an XML document, such as when patient information is updated by an authorized health care provider. XML Signature might refer to external elements when it is being used to guarantee integrity of critical Web pages to prevent defacement.

XML Encryption supports the security principles of confidentiality in transit as well as persistent confidentiality when messages are stored (something SSL definitively can not do). This is a critical need when maintaining adherence to security policies and regulatory compliance. As with XML Signature, XML Encryption can be applied to just a portion of an XML document, such as the credit card number being transmitted with an order.

WS-Security builds on the solid security base W3C established with XML-based security. Just as XML Signature and XML Encryption are about XML security, WS-Security is about SOAP security. It is a set of extensions to SOAP. Its role is to specify how to pass security information in SOAP headers.

IBM, Microsoft, and VeriSign developed and submitted WS-Security to OASIS. The OASIS Web Services Security (WSS) technical committee is now driving the standard effort forward with a focus on using XML Security with Web services. The simplest way to think about WS-Security is that it defines security tokens passed in the SOAP header. The most important tokens passed in this manner are for authentication and authorization. Why? Because this specifies who signed the XML message that is in this SOAP message's payload. Or it specifies what the individual is allowed to do ("purchases up to $10,000") that might not be consistent with the Purchase Order carried in the payload.

The typical way WS-Security will work is that all or part of an XML message will be signed or encrypted and in the SOAP header will be passed a signature or decryption key to be used by the message recipient.

As with any security system, the keys to its success are the policies it is designed to enforce and the monitoring of how effective it is at such enforcement. Therefore, it is critical that all authentications, all authorizations, all linkages between identities and the transactions they perform, and the regulations affecting encrypted XML data elements all be monitored and logged for discovery and defense.

Conclusion
Point-to-point Web services can be securely implemented today. The industry-standard Web security technologies SSL and digital certificates form the basis for simple and effective Web services security. Properly implemented, they provide authentication and ensure communication confidentiality and integrity. Coming soon are ways to apply message-level security that will allow Web services to handle sensitive information that must remain encrypted and Web services that take multiple hops. In order to ensure security no matter what type of technology is applied, companies must also monitor security compliance at run time. SSL, digital certificates, and an active security monitoring system provide a sensible approach to securing the majority of today's Web services when used together.

How SSL Works
The most widely deployed and used system of security on the Internet is Secure Sockets Layer (SSL). SSL is what makes the padlock symbol light up in your browser when you go to a secure site. It is used not just for security between a server and a browser; it can also be used between two servers. SSL provides three important security capabilities: server authentication to the client, confidentiality of the transmitted data, and (optionally) client authentication to the server.

Server authentication ensures that the domain the client expects to be visiting is indeed where the server is. This authentication happens through a digital certificate installed on the server. The certificate has a domain contained in it that must match the actual domain of the server.

Confidentiality of transmitted data is provided by the activation of the SSL protocol. This protocol - built into all common Web and application servers - does an initial secret key exchange and cryptographic protocol negotiation; that protocol is then used to encrypt all data transmitted between client and server. No one has been able to demonstrate any vulnerability of SSL encrypted data on the wire.

Procuring and Enabling Digital Certificates
Using the built-in IIS Server Certificate Wizard, it's easy to generate the key pair that is needed to submit a request to a Certificate Authority for a server digital certificate. A base-64 encoded certificate signing request (CSR) is saved as a text file representing all the information provided. It is this text file (which contains the public key just generated) that will be submitted to the certificate authority for the creation of the X.509 digital certificate which will enable SSL.

Using the standard enrollment page of one of the public certificate authorities (in this case FreeSSL), the CSR from the aforementioned text file is copied and pasted into the Web form. This provides the CA with all the necessary information to validate the identity of the submitter and the rights of that submitter to the specified domain. (That's all that's needed to acquire an SSL certificate.) The validation and certificate generation process takes anywhere from 10 minutes to four days depending on the CA and the type of certificate requested.

Once the X.509 certificate is generated, it is delivered by the certificate authority as a base-64 encoded text file. The IIS Certificate Wizard is invoked again, this time for the purpose of installing the certificate.

The text file containing the certificate is provided to the wizard, which decodes and parses the certificate and presents the information back to the administrator for confirmation purposes. Upon completion of this step, the certificate is installed; it will now enable SSL connections to be made either by browser clients or by servers acting as clients.

Monitoring Web Services Security Using an active monitoring solution, Gargantuan can monitor the security of its Web services, alert security officers of problems, and log information in order to resolve security issues.

The tool auto-discovers Gargantuan's Web services and exposes the Web service operations and fields for monitoring and analysis (see Figure 4). The screen capture on the right shows the main configuration screen. Gargantuan uses this graphical interface to create a security dashboard, and rules for alert generation and logging.

Gargantuan has requested monitoring all HTTP and HTTPS handshakes including client-side SSL authentication. SSL is initially turned off, clients are not authenticated, and the services are unsecured. SSL is activated at 2:31 between the fourth and fifth entry in the log. The log shows an attempt to connect without client authentication which results in a 403 http failure. It also shows client authentication information for all accesses after SSL is activated.

About the Author
Dr. Jothy Rosenberg is a serial entrepreneur and the cofounder, CTO, and CEO of Service Integrity, a rapidly growing Web services monitoring and analysis software provider. Prior to this venture, Jothy cofounded GeoTrust, the world's second largest certificate authority. He is also the author of How Debuggers Work and the forthcoming Building Secure Web Services with WS-Security (Sams; 2004). jothy@serviceintegrity.com

Pragmatic Web Services Security Today by Dr. Jothy Rosenberg
WSJ Vol 03 Issue 12 - pg.40

Listing 1: WSDL for Stockcheck and PriceCheck

<?xml version="1.0" encoding="utf-8"?>
<definitions name="Reseller"
targetNamespace="http://ws.gargantuan.com:83/Reseller.xml"
xmlns:tns="http://ws.gargantuan.com:83/Reseller.xml"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/" >
<message name="StockCheckReq">
<part name="ISBN" type="xsd:string"/>
<part name="Quantity" type="xsd:long"/>
</message>
<message name="StockCheckResp">
<part name="Status" type="xsd:string"/>
</message>
<message name="PriceCheckReq">
<part name="ISBN" type="xsd:string"/>
<part name="Quantity" type="xsd:long"/>
</message>
<message name="PriceCheckResp">
<part name="Price" type="xsd:decimal"/>
<part name="Status" type="xsd:string"/>
</message>
<portType name="ResellerPort">
<operation name="StockCheck">
<input message="tns:StockCheckReq"/>
<output message="tns:StockCheckResp" />
</operation>
<operation name="PriceCheck">
<input message="tns:PriceCheckReq"/>
<output message="tns:PriceCheckResp" />
</operation>
</portType>
<binding name="ResellerBinding"
type="tns:ResellerPort">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="StockCheck">
<soap:operation
soapAction=
"http://ws.gargantuan.com:83/Reseller.xml#StockCheck"/>
<input>
<soap:body use="encoded"
namespace=
"http://ws.gargantuan.com:83/Reseller.xml"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace="http://ws.gargantuan.com:83/Reseller.xml"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
<operation name="PriceCheck">
<soap:operation
soapAction=
"http://ws.gargantuan.com:83/Reseller.xml#PriceCheck"/>
<input>
<soap:body use="encoded"
namespace="http://ws.gargantuan.com:83/Reseller.xml"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace=
"http://ws.gargantuan.com:83/Reseller.xml"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name="Reseller">
<port name="ResellerPort"
binding="tns:ResellerBinding">
<soap:address location=
"http://www.gargantuan.com/ws/Reseller.asmx" />
</port>
</service>
</definitions>