.NET Web Services Security

Web services are all about connecting businesses in a standard and secure manner.For a real-life Web service, security is intrinsic to every facet of operation and no party would ever agree to interact with a non-secure Web service. Unfortunately, Web services security is still in its infancy; standards such as WS-I are just emerging and there is no built-in support in the development tools for them. That being said, there are quite a few programming techniques you can use today in .NET 1.1 to secure your Web services, and do so in a way that will ease the transition to future standards and protocols.

Who Needs Security?

You do, and you need to design security into your Web services from the ground up. Toy-like Web services you have seen at development conferences or used in tutorials have no place in today's business and services. Your Web service needs to authenticate callers, making sure they present a valid identity, and your authentication process should not compromise sensitive information, such as passwords. Once a Web service authenticates an identity, it can use that identity for a number of purposes, such as verifying that a caller is authorized to perform certain operations, or disallowing unauthorized access. Web services can use identities for billing, licensing and auditing, and even for run-time service customization.

.NET Web Services and Security

When you use .NET to build a Web service, you rely on the built-in security support in ASP.NET and Internet Information Services (IIS). While this support makes developing secure ASP.NET Web Forms a breeze, it may require some work to develop and consume secure Web services. The problem is that ASP.NET and IIS security assumes there is a user on the other side of the wire, and that the user can type a user name and password into a dialog. Of course, with Web services there is no user involved, because Web services connect a client (an object) to a remote object (the Web service). This means that client-side developers have to provide your Web service with security credentials either explicitly or implicitly. .NET offers two security options to Web service developers: rely on Windows security or provide custom authentication. This article describes these two options and their different flavors and provides a side-by-side comparison of the security techniques.

Windows-Based Security

Using Windows-based security requires that the calling client application provide the credentials of an account on the server (or on the domain server). As a result, Windows security is most appropriate for intranet applications that use Web services to interact across a well-administered corporate network. This is because typically you have relatively fewer clients in an intranet application than in an Internet application. However, if managing a large number of accounts is acceptable to you, you could use Windows security across the Internet as well, where the number of users of the service can be considerably larger.

To use Windows security, all you need to do is configure the Web service appropriately. Once you configure the Web server to use Windows-based authentication, all calls to all methods on the Web service are authenticated.

To configure your Web service to use Windows-based authentication, you need to set the authentication tag in the Web service configuration file to Windows:

You also need to disable anonymous access to the Web service. In IIS, display the properties of the Web service and select the Directory Security tab. Click the Edit... button to bring up the Authentication Methods dialog box. Clear the Anonymous access check box (see Figure 1).

Then, you need to select from the available authentication options on the Authentication Methods dialog box: Basic, Digest, or Integrated. These three options differ in the transport protocols they require and in what they require on the client side. Since you have disabled anonymous access, if you do not select at least one of the authentication options, all calls to your Web service will fail.

By: Juval Lowy

Juval Löwy is a software architect and the principal of IDesign, a consulting and training company focused on .NET architecture consulting and advanced .NET training. This article contains excerpts from his latest book (Programming .NET Components 2nd Edition (O'Reilly, 2005). Juval is a frequent presenter at development conferences and Microsoft's Regional Director for the Silicon Valley.

Over the last three years Juval has been part of the Strategic Design Review process for .NET 2.0.

Microsoft recognized Juval as a Software Legend as one of the world's top .NET experts and industry leaders.

Contact him at www.idesign.net