Microsoft's ASP.NET was an attempt to bring the Stateful Application Model to the Stateless Web. For a certain (admittedly common) type of Application it works pretty well. Provided, of course, that you don't want to do something outside of the 'normal' ASP.NET model. This is, of course, part of why I dislike ASP.NET so, but it is the technology our office has chosen to pursue, and it has led to some interesting challenges as we try to bend the technology to fit our needs.

The primary suite of Web Applications that we maintain, is what we call the RONet. The architecture on the RONet was done right around ten years ago, and the entire architecture was written in classic ASP/VBScript. The architecture, which this post will not go into, is pretty clean, but it was clearly designed at a time when the Internet, and a Web Application, was not what it is today. The existing Architecture, while sufficient for what has already been written, is not sufficient for moving forward, so we have been working on putting in to place a new Architecture to replace the old one in a piecemeal fashion.

Regrettably, Microsoft did not provide any good mechanism to integrate Classic ASP to ASP.NET. This makes the task of a piecemeal replacement of Classic ASP with ASP.NET far more difficult than it needs to be. There are a few methods to work around this. In Classic ASP, Authentication is typically verified using a Session variable. One solution, is to copy the correct Session variables from Classic ASP into ASP.NET. There are known methods (read: ugly hacks) to accomplish this.

The problem with reimplementing this sort of Session-based authentication in ASP.NET is that it's not terribly forward thinking. ASP.NET implements it's own Authentication model that exists beyond the session (that's not entirely fair, as the Authentication is tied to the Session Cookie, but bear with me), and by not taking advantage of the ASP.NET model, you lose access to things like the built-in Role- or Claims-based Security.

This post represents the beginning of my adventures in customizing the ASP.NET Authentication mechanism. There will be several most posts over the next few weeks regarding how this is accomplished. We will be using ASP.NET Forms Authentication, since Forms authentication is best suited for the work that I've been doing.

1. Custom MembershipProvider to customize the Authentication Step
2. Custom User Principal to customize Role-based Authentication
3. Custom Claims-based Authentication

The next post in the series will be posted next week, where I'll be going over writing a custom MembershipProvider, and particularly focusing on some of the challenges that I ran in implementing our particular system.