Enterprise applications Toolkit

Practical examples for establishing Web service security in .NET

Tags:
Example,
Security,
Simple,
Add

Kevin Koch, Builder.com Builder.com

Published: 06 May 2003 13:08 BST

Why make a Web service private?
You may ask, "Why remove public access to a Web service?" Many developers view Web services as a public, freely consumable service where any consumer may discover a Web service and implement it in his or her own applications. While this scenario is true, there are many situations where you may not want your Web service publicly available.

For example, a large organisation with multiple office locations throughout the country, each with a custom internal solution that communicates with the other offices via Web services may want a private Web service. Or perhaps you're working in an organisation that implemented a new cutting-edge system of delivering complex information via Web services, and you want to charge your clients for utilising this service.

In both of these examples, the target audience of your Web service is definitive and must be controlled by the implementer of the Web service, restricting access to those who aren't authorised.

If you require a private Web service, it isn't enough simply to hope that nobody happens to guess what and where your Web service is. Restricting access to authorised consumers won't prevent others from manually discovering your Web service on the Internet; reading its WSDL description; revealing all of its methods, parameters, and return values; and implementing the Web service in their own application -- even though they will be denied access due to the SOAP Header security. The fact is, if it exists and is public, it will be found.

Web.config
The first step in making your Web services private is to put them into their own directory. This is also a good practice for organisational purposes.

Once your Web services are in their own directory, you can add a Web.config file that applies to that directory only. Every ASP.NET application generated by Visual Studio .NET automatically has this file inserted at the root of the project and is responsible for the configuration settings of the entire ASP.NET application. The Web.config file contained in the root of the project is the only file that may contain application-specific configurations, because the configurations may be only declared once globally for the entire application. However, every subdirectory in an ASP.NET application may contain its own Web.config file with specific instructions for security, authentication, protocols, etc.

If you use Visual Studio .NET, the software will insert a template Web.config file containing all of the XML nodes available in the root Web.config file. However, since this new Web.config file resides in a subdirectory, your project will not execute correctly because many of the definitions are restricted to the root Web.config file and cannot be duplicated.

To make your Web.config file in your Web service subdirectory compile correctly, you must do the following:

Locate the tag and the closing tag.
Delete everything in between these two tags with the exception of the tag.

The Web.config file is merely an XML file containing specific instructions on how to handle certain characteristics of behaviour pertaining to the directory that the Web.config file resides within. Although the tag is valid for a Web.config file contained in a subdirectory, you'll need to remove it for your sample in Listing C, because the auto-generated tag tells IIS to allow anonymous access to that directory.

You'll also secure your Web service directory by simply adding a few lines of XML to your Web.config file. Listing C shows the entire Web.config file in its complete state.

This solution is incredibly simple yet very powerful. The tag instructs IIS which HTTP requests are allowed or not allowed on files contained within the directory. By removing "HttpGet" and "HttpPost" requests, you effectively prevent any direct browser access to your Web services. By removing the "Documentation" protocol, you tell IIS not to display the WSDL description for your Web services.

The interesting part about this is that it doesn't prevent a consumer of your Web service from accessing it. Once your Web service is complete, and you're confident of your interface contract defined by the Web service, you may generate the WSDL file, distribute it to your authorised consumers, and then make your Web service private by adding the lines in Listing C to your Web service directory.

More enterprise IT news in ZDNet UK's Tech Update Channel.

For a weekly round-up of the enterprise IT news, sign up for the Tech Update newsletter.

Let the editors know what you think in the Mailroom.

Go to section: