Is it possible to write an ISAPI filter equivalent (IHttpModule imlementation?) using managed code? I want my filter to get invoked for non .NET applications a well.
Unfortunately, you cannot [yet] write an ISAPI Filter equivalent using managed code. The closest you can get on existing technologies is IIS6+ASP.Net 2.0 configured as Wildcard Application Mapping, which allows managed code (either HttpModule or HttpHandler) to be invoked for any request type (.NET as well as non .NET) and optionally use the DefaultHttpHandler to pass the request handling back to IIS for further processing. For example, this allows .NET Forms Authentication to apply for ASP pages.
However, I do not consider this to be really “ISAPI Filter equivalent”, by which I mean invoking managed code throughout the request processing lifecycle. Managed code is only invoked in one place in the request pipeline, right before the request is processed and executed. Meanwhile, ISAPI Filter has over a dozen different events firing throughout the request lifecycle, one of which corresponds to “right before the request is processed and executed”.
Of course, you can always write an ISAPI DLL in native code which basically parses the request, launches the CLR inside an AppDomain, and passes requests into it for processing. This is how ASP.Net works today. Or you can write an ISAPI DLL which uses COM Interop to call into managed code components. You may even do a lot of work and write an ISAPI Filter DLL which triggers on all events and passes data into the AppDomain to “simulate” managed code running inside of ISAPI Filter events. But none of these are really “ISAPI Filter equivalent” with managed code.
In other words, it is not possible to use managed code to customize authentication events – IIS negotiates Basic/NTLM/Kerberos/Passport authentication prior to processing and executing the request, which also preceeds when the ASP.Net Wildcard Application Mapping is executed… thus it is not possible for managed code to participate in modifying the IIS authentication behavior. This is why you must configure IIS to be “Anonymous Only” in order to apply .NET Forms Authentication.
Now, IIS7 presents a different story. You will have ISAPI Filter equivalent extensibility of IIS7 using managed code, and it is using the familiar IHttpModule and IHttpHandler interfaces. What we did in IIS7 is refactor and componentize the IIS6 Web Server into a compact “IIS7 Server Core” which exposes a brand new native code extensibility interface, and we are providing 40+ “Functionality Modules” which are coded using the new native code extensibility interface. The 40+ “Functionality Modules” allow the “IIS7 Server Core” to provide the “IIS6 feature set” plus expose completely new features and functionality. One of them is extensibility of the IIS7 Server Core using managed code in an integrated fashion.
Finally, a word of caution when attempting to use managed code to “filter” requests, regardless of IIS version. Since only one CLR Version can be in a given process, if you configure managed code of one version to “filter” requests that are ultimately executed with another CLR Version, that will cause a conflict and prevent request execution.