Until the release of IIS 7, it was fair to say that the ASP.NET application had its own life cycle, which wasn”t really integrated with IIS. For instance, when you”re using IIS 6, a request will have to be authenticated by IIS before it”s forwarded to the ASP.NET engine. After getting the request, then ASP.NET engine will run its own authentication again (that is, if the web app is configured to require that operation). So, we really have some sort of duplication, even though the authentication algorithms aren”t really the same. Besides this duplication, there were also other problems. For instance, the ASP.NET authorization will only be applied to ASP.NET resources.
The good news is that with IIS 7 the ASP.NET engine can really be integrated with IIS and you no longer have the problems I”ve mentioned inthe previous paragraph. With IIS 7, you”ll even be able to build IIS modules in managed code (yep,no need to write unmanaged code if you don”t want to). In other words,you”ll be able to, for instance, apply forms authentication to all the resources served from the server. This integration will only be achieved when IIS is running in integrated mode.
In order to achieve this integration, the IIS 7 has its own configuration API (more info on future posts), which is quite similar to the one used on ASP.NET applications (though there are some nasty details that might get in your way, specially if you”re building a section that is supposed to be integrated with the IIS 7 admin console). If you”ve looked at a recent web.config file, you might have seen a <system.webserver> configuration section. That section is specific to the IIS 7 server. The good news is that many of the ASP.NET modules can be used on IIS 7 since the team wrote several classes responsible for assuring the correct integration with the server 🙂
I”m finding IIS 7 so interesting that I think I”ll write a couple of posts about it in the next days 🙂