Be the first to write a review
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.
Note: Visual Studio .NET 2002/2003 running ASP.NET 1.x is required for this tutorial. Both VB.NET and C# code samples will be provided
Kevin Koch is a senior software engineer with over 8 years experience designing and architecting primarily web based applications. Fresh out of college during the nineties he co-founded Task Solutions and developed several projects with the then popular classic ASP.
During the Dot Com boom Kevin left his position as president and joined a new venture to build an enterprise insurance claim system build upon J2EE technology. After the Dot Com crash Kevin schooled himself to become an expert with .NET technology and is currently freelancing his ASP.NET skills to build enterprise n-tier frameworks using advanced OO methodologies.
You must me logged in to write a review.