.NET Web Services and Security

By Juval Lowy

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