By David Burgett

The one thing that can really push a new technology into the forefront of business executives’ minds is the ability to generate additional revenue. Web services allow you to sell your existing functionality as a service to anyone with an Internet connection. Now, the question becomes, once you publish your functionality as a Web service that anyone on the Internet can use, what’s to stop anyone from using it? That is, how can you ensure that only your paying customers use the service? This is the first installment of a three-part series that will examine several techniques for ensuring the security of your Web services.

Securing Web services
In this article, I will use a fictional company called The Internet Dictionary Company (TIDC) as the basis of examples. It has maintained a Web site for several years where users can freely look up word definitions. It also has a premium service offering additional information such as the etymology of the word, synonyms, and so on. With the advent of Web services, TIDC has realized the opportunity to generate additional revenue by offering a customized dictionary Web service to other Web sites. The Web service allows customer Web sites to access the TIDC information about a specific word and use that definition within their own Web sites.

Another fictional company, Regal Research, offers online research information about royal families around the world, present and past. Regal Research has used TIDC in the past by offering links to the TIDC Web site to define certain words. This solution is not very user-friendly, however, because the user is taken to a new browser window linked to the TIDC Web site. The integration value of using TIDC is lost, because the word definition retrieved from TIDC is not integrated with the Regal Research Web site.

With the new TIDC Web service, however, Regal Research can now fully integrate the definitions and other information directly into its own site (Figure A). Now when a Regal Research user asks for a definition of a word, the definition is displayed within the Regal Research site, unaware that the definition was provided by a separate Web service. This process offers better functionality to users of Regal Research and generates additional revenue for TIDC, using mostly existing functionality.

Figure A
TIDC Web service architecture

Now that TIDC has created a Web service and Regal Research is using it, TIDC must ensure other Web sites cannot freely access the service. There are numerous ways to achieve this goal. Choosing the right one depends on the level of security needed and the goals of the application. One technique is known as IP blocking.

IP blocking
The first type of Web service security we will examine is IP blocking. IP blocking is a common security technique available on all popular Web servers such as Apache and Microsoft Internet Information Server (IIS).

IP blocking is simply the process of identifying those IP addresses from which Web requests will be accepted. This is usually achieved by specifying a list of acceptable IP addresses. Each time a Web request is received by the server, it compares the IP address sending the request to the list of acceptable IPs. If the IP is on the list, the request is fulfilled normally. If it is not on the list, the server returns an HTTP 403.6 error, “Forbidden: IP address rejected.” Note that it is also possible on most Web servers to specify blocked IP addresses rather than allowable addresses.

Because Web services are typically used through a simple HTTP request, IP blocking works identically for Web services as it does for standard Web site requests. Clients who are on the accepted list will be able to make Web service calls, as well as see the WSDL files on the site to learn about the Web services.

Issues to consider
You need to consider a few issues when using IP blocking. Because all requests are blocked by the Web server itself, clients will not be able to access any part of the Web site until you have added their IP to the accepted list. This behavior blocks potential customers from viewing the WSDL files to learn about your Web service offerings. Also, it is important to note that users with invalid IP addresses will be blocked from Web pages within your site. This fact can be critical, because developers often place Web services and pages within the same Web site to maximize reusability. So if you use IP blocking for your Web services, you must either accept the same security for your Web pages or create different virtual directories on your server for your sites and services.

In the example scenario of The Internet Dictionary Company, IP blocking is an effective security measure. As shown in Figure B, the Web server running the TIDC Web service automatically allows Web requests by Regal Research, while simultaneously blocking requests from anywhere else. Doing so ensures that only paying customers are able to access the TIDC Web service.

Figure B
IP blocking allows paying customers to use the TIDC Web service, while denying access to others.

Implementing IP blocking is relatively simple, but the process varies from Web server to Web server. Using IIS, version 5, a user can simply choose the Directory Security tab of the Web site properties box and enter the acceptable IP addresses. With Apache, you can modify an .htaccess file that specifies which addresses should be allowed access.

A final consideration for using IP blocking is that access to the Web server is usually required in order for an administrator to specify the acceptable IP addresses. This access may not be possible or cost-effective in a situation where the development is completed in a remote location, away from the Web server. For example, if the TIDC developers are in New York and the physical Web server resides in California, the developers will have to find someone in California to edit the IP list every time they add or delete a customer.

Coming next…
In the second installment in this series, we will examine two more techniques for securing Web services: user authentication and digital certificates.