Securing a Web Service the Low-Tech Way San Jose CA

provided by: 
Originally published at Internet.com

In the past few years, a lot of work has been done to add new schemas of information that can be sent to secure and identify users of Web services. While implementing security is generally important for Web services, there are a lot of "low-tech" ways to implement security around your Web services that don't involve a lot of extra coding.

The first method is using a firewall to block the ports on which your Web services listen. If you have a Web service that is used only within your company network, put it on an alternate port (other than port 80 or 443) and then block access to that port at your firewall. That's one of the easiest ways to block access. Along with that restriction, you can configure Internet Information Server (IIS) to allow only certain IP addresses to use the Web service. You can control this by selecting Properties -> Directory Security -> IP address and domain name restrictions under the IIS management application.

Once you have your access controlled, securing the data going to and from the Web service may also be important for your application. I say may because a Web service that provides the time and temperature probably doesn't need to have these sorts of access rules on it. To reliably encrypt the data on the Web service, add an SSL certificate. You can either use a self-signed certificate or purchase a cheap SSL certificate from any one of a number of companies. A self-signed certificate has the downside of not being recognized as a "real" certificate by anyone who doesn't accept you as the root authority. An inexpensive SSL certificate will have a root certificate that is known universally but instead of being a "second-tier" certificate, there will be an intermediate authority between your certificate and the root. This has been known to cause issues with certain browsers, but it causes far fewer errors than the self-signed certificates.

A final approach for securing your Web services is to add a simple user name and password field to each method call. This is an easy way to ensure that every call requires authentication prior to use and doesn't require the caller to do anything fancy with their code. The user ID and password are easy to exchange "off-line" to prevent someone from using it incorrectly. If you add this level of security to the other options discussed in this tip, you've got a simple way to make your Web services much more secure than they would be otherwise.

About the Author

Eric Smith is the owner of Northstar Computer Systems, a Web-hosting company based in Indianapolis, Indiana. He is also a MCT and MCSD who has been developing with .NET since 2001. In addition, he has written or contributed to 12 books covering .NET, ASP, and Visual Basic. Send him your questions and feedback via e-mail at questions@techniquescentral.com.