Security in Web Services

Opening up a procedure call to remoting makes applications vulnerable to accidents, poor end-user implementation, and crackers. Any application design needs to include some level of security. Web Services demand the inclusion of security.

Security problems with Web Services fall into two categories - interception and unauthorized use. SOAP messages intercepted by crackers potentially expose private information, such as account numbers and passwords, to the public. Unauthorized use at best costs money and at worst wreaks havoc within a system.

Very few of the concepts discussed here are things we would like to see in the hands of those wearing the black hats. Even the simple validation service handles e-mail addresses - a valuable commodity in this world of “opt in” spamming. If you add social security or account numbers to the service, then this becomes even more of a concern. Fortunately, the wire transport of choice - HTTPS - provides a 128-bit solution.

In addition, as mentioned earlier, by using Microsoft’s Web Services Enhancements (WSE) and the Windows Communication Foundation capabilities, you now can easily apply security standards such as WS-Security to your SOAP messages.

The Secure Sockets Layer

The Secure Sockets Layer, or SSL, is a protocol consumed by HTTP in the transfer of Internet data from the Web server to the browser. On the Web, the process works like this:

1. The user calls a secure Web document, and a unique public key is generated for the client browser, using the server’s root certificate.

2. A message encrypted with the server’s public key is sent from the browser.

3. The server can decrypt the message using its private key.

The protocol in the URI represents how HTTP would appear if it were changed to HTTPS:

 <address uri="https://aspx.securedomains.com/evjen/Validate.asmx" />

The service would then make an SSL call to the server. Remember that SSL is significantly slower than HTTP, so you will suffer a performance hit. Given the sensitivity of much of the information passing over Web Services, it is probably worth the slowdown.

Directory-Level Security

You also have the option to code security into your applications. This solves different problems from SSL, and, in fact, you may wish to combine the two services for a complete security solution.

Unauthorized access is a potential problem for any remote system, but even more so for Web Services. The open architecture of the system provides crackers with all the information they need to plan an attack. Fortunately, simplicity is often the best defense. Using the NT security options already on the server is the best way to defend against unauthorized users.

You can use NTFS permissions for individual directories within an application and require users to provide a valid username and password combination if they wish to access the service.

Tip 

Web Service security is a large area to cover. For more information, refer to the documentation included with the .NET Framework SDK.

The best approach to security is to use SSL and directory-level security together. It is slow, and at times inconvenient, but this is a small price to pay for the heightened level of security. Though this is different from the traditional role-based COM+ security, it is still very effective for running information across the wire.

Other Types of Security

The Windows platform also provides for other forms of security. For instance, the Windows CryptoAPI supplies access to most of the commonly used encryption algorithms - aside from the protocols used in the Secure Sockets Layer. Digital certificates (sort of a personal form of SSL ServerCertificates) are now rapidly becoming a powerful force in security.