Managing ASP.NET Sessions Between Iframe and Page

Let me start off by saying, "I feel your pain, brutha." I went through this 3 years ago, and I wish MVC had matured at that point because the WebForms solution I designed fairly well resembles the MVC model without actually having the Microsoft libraries built for me (of course, there were several glaring "Why the hell did I do that" differences).

I also ended up using iFrames to manage the content differences using .Net as the parent application and classic asp as the slave. I developed the framework architecture in .Net and implemented that. The classic asp pages were then "culled" of unnecessary presentation pieces (includes and whatnot) and loaded into iFrames. Data was then passed in through the url using a custom encryption. To make sure that the authentication could not be spoofed easily and the page accessed by cracking the query string we also employed Wildcard handlers in IIS that forced .Net to authenticate before parsing classic asp pages.

Given that, my recommendation would be to head to MVC straight away.

1. MVC will give you access to routing at the global.asax level. With clever manipulation of a controller, you could develop your models in a proper fashion and have a common controller that handles all classic asp requests as necessary.
2. MVC will make it very simple to add a test project and allow you to refactor individual application pieces based on the new model structure while providing adequate test coverage to make sure you're getting it all right. The value of this is absolutely incalculable because in any refactor code coverage is a huge concern.
3. MVC follows a more scripted approach to presentation than WebForms does. WebForms tries to mix it all up like it's some kind of stateful application (which it isn't), and that can be quite a culture shock for people accustomed to classic asp. Don't get me wrong, your developers are going to have culture shock no matter which way you go, but if you can take some of that shock out of the presentation layer you might find greater success.

I like both WebForms and MVC (though I'll admit with the introduction of Razor I'm becoming a little biased towards MVC). They both have their places, and I think an application such as the one you describe may be ideally suited for an MVC implementation particularly given the "staggered" nature you'll need to adopt in rolling out refactored application pieces.

Whichever way you go, I think you need to make sure that the .Net application is always the parent application when it comes to authentication/authorization/routing/etc. A colleague of mine implemented his migration on a similar application with classic asp as the parent, and he had a large number of problems when it came finally to integrating everything back together.

Treat an EAR like a pseudo-virtual machine

An EAR is simply a collection of WAR files that share common configuration and libraries, usually from JARs. This enables a collection of inter-dependent services to be managed more easily within an application container. Thus you can think of an EAR as a simple form of virtual machine once it is deployed into its container.

In the same way that one process on a virtual machine cannot affect another, the same is true for an EAR. All the WARs are isolated to protect their internal state.

Scaling authentication

In general web applications need to be stateless to scale well. Having a lot of information in the session is an anti-pattern that prevents this. This leads to a conflict between the stateless nature of HTTP and the need to maintain a speedy, customised user experience. Authentication is a classic use case, and is prevalent in chatty APIs that require a lot of authenticated requests to deliver end-user functionality.

Single Sign On and Single Sign Off need careful signalling to work correctly (consider partial Sign Off), particularly when horizontal scaling is in place. Simply sharing session state is almost never a good solution and a better approach is to use a single point of reference for the user information that all nodes in the cluster have access to.

Concentrating on speedy cached access to relevant information will yield far more scalable results than some complex, fragile session sharing solution.