SOAP Header Security in ASP.NET 1.x

When working with Web Services one of the more difficult aspects of implementation is security. There are several scenarios of Web Services usage and depending on what your Web Service is intended to do you will require different methods of security.

If your Web Service is intended for public use security is probably not a great concern. If however your target audience is for strict corporate use or even internal use within a single company you will need to make sure your Web Service is not accessed from unauthorized sources.

The first natural thought it to create a login service which can authenticate users before allowing any access to your service methods. One of the biggest annoyances with Web Services and Web requests in general is that state is always destroyed after each request. There’s no simple solution to maintaining a user’s security principle across multiple Web Service requests.

What does this mean in simple terms? It means that you can authenticate on one request but subsequent requests will not be authenticated because the Web Service is not able to “remember” your client. In addition you don’t really want to be sending over user names and passwords as serialized text over the internet.

Fortunately there is a fairly simple alternative called SOAP headers or envelopes. These are sent as separates XML packages with your Web Service requests and can be read by the Web Service separately from the web method parameters.

The purpose of this article is to demonstrate how to use SOAP headers on a Web Service in an ASP.NET application, and, how to implement the header on an ASP.NET client application. The demonstration will be fairly straightforward and will use a login form to create a Web Service security content and use that context object on all Web Service requests.