email article printer friendly get the code more resources

Compare Web Service Security Metrics
Do WS-Security's granular X.509 digital signatures and X.509 encryption justify certificate management and performance problems?
by Roger Jennings

Posted October 16, 2002

Secure HTTP (HTTPS), Secure Sockets Layer (SSL) 3.0, Transport Layer Security (TLS) 1.0, and X.509 digital certificates are today's de facto standards for secure, encrypted transmission of SOAP messages between a pair of endpoints. All commercial browsers and Web application development environments provide transparent support for HTTPS. Provisioning X.509 certificates for Web server identification has become a substantial business for VeriSign and several competitors. Client-side SSL, which employs X.509 certificates to enable the Web server to identify client users or computers, is less common but reasonably easy to implement.

SSL provides two-way encryption and one-way or two-way authentication between a predefined pair of SOAP message endpoints. B2B business processes and even some B2C transactions might require SOAP request and response messages to traverse multiple hops between the Web service and the consuming application. In this case, message security and user identity can be compromised at the intermediate points. The WS-Security specification—now under the aegis of the Organization for the Advancement of Structured Information Systems (OASIS)—addresses message-level security in contrast to HTTPS's transport-level security at the OSI stack's session level. WS-Security also supports granular digital signatures; each SOAP header element and the payload can be individually signed. This means that intermediaries can add or substitute their signatures when necessary.

	Figure 1. Compare Unsecured, HTTPS, and X.509 Web Service Execution Times.

Previous articles in this series, which I call the "WSDK Quartet" (with apologies to Lawrence Durrell), cover Microsoft's WS-Security implementations of one-way and two-way username signing, symmetric (shared-secret) encryption, and both (see Resources). In this final article (for now), I'll show you how to implement two-way X.509 certificate-based signing and/or encryption with the WSDK Technical Preview and Visual Basic .NET service and consumer code (see Figure 1). You also can try a live ASP.NET version of this article's WsdkX509Client.sln project (see Resources). I'll also compare WS-Security's performance with HTTPS, explain my Web service execution time measurement methodology, and discuss X.509 certificate management and interoperability issues.