I have situation where I use JRun or Tomcat as servlet container with IIS (5.0 or 6.0). I want IIS to forward the HTTP (Basic) Authorization header that comes with the request via ISAPI-DLL to Tomcat or JRun. That does not work in most cases (got it to work with the jrun.dll sometimes, but never with iis_redirector.dll). No matter what settings I choose in the “Directory dsecurity” tab. Can you explain what happens there? Is that possible at all?
IIS does not have functionality to forward requests made to it. It merely knows how to parse the request, execute ISAPI Filters during request processing, and then execute the appropriate request handler (which includes Static File Handler, ISAPI Handler, and CGI Handler) to handle the request.
Thus, the answer to your question really depends on whether the ISAPI DLL that forwards the request is able to do it and do it correctly. Since neither jrun.dll nor iis_redirector.dll are written by Microsoft, I cannot comment on their specific functionality nor behavior. You will have to contact their support team or user group to find the answer. For certain, settings on the “Directory Security” tab is tangential to your question of request forwarding.
Now, you must realize that just because you can forward a request header such as Authorization: does NOT mean that you can correctly forward authenticated requests for any authentication protocol. Some authentication protocols resist re-transmission like this because it is no different than the classic man-in-the-middle attack. Yes, I know that you know that you are not the bad guy, but to the authentication protocol protecting the traffic transmitted via the Authorization: header, everyone is the bad guy except for the originator and recipient who hold the necessary keys to unlock the transmission.
In the case of Basic authentication, since it is insecure and has no defensive mechanisms, it falls victim to your re-transmission and security attack. So, yes, you got what you wanted, but you must realize that your entire authentication process is insecure from start to end, even if you SSL-encrypt it, because the endpoints are still vulnerable, and you are requiring more trust from your users than you need or have authorization for…