IIS7 Mixed Mode Authentication

问题:

We're getting ready to start migrating some of our IIS6 sites to IIS7, and the application currently uses Forms Authentication. We have started getting some requests from various sites to use the Windows Authentication for the users. While this is easy enough to implement (and I've shown internally that there is no issue with the app, as expected) the question then is how to continue to keep Forms authentication for when Integrated Windows doesn't work. I've seen several walkthroughs on how to have it configured on IIS6, and I could do the same thing on IIS7, but then I have to turn on Classic Mode processing. Any solution should also be back portable to IIS6, if possible, to keep the build tree simple.

So what are my options on this? Do I setup the app with Integrated Windows Authentication in IIS7, Forms Auth in the web.config, and redirect 401 errors to an "error page" allowing them to login using forms, then back to the regular app?

The case when Forms is likely to be needed is going to be reserved for Contract workers, our support staff, and if someone needs to access it on their site from their Extranet. So primarily it's for our staff to login to check functionality and confirm bug reports. I suggested we just maintain that for our support staff to work, we need a Windows login that will always be live, and then we'll just enforce local responsibility on who can login to the site, but I'm told that we would do better to have Forms Authentication.

Any thoughts? I can post some of the links of the articles I've already read through if that would help the forum better narrow my needs.

tl;dr: How to do mixed mode authentication (forms, windows) in IIS7 without changing to classic pipeline and still be able to use the build in IIS6 if possible.

回答1:

No, that's not quite right, but I can't do a code block in a comment reply, so I'll post a new answer ...

The following code block allows me to control anon access from IIS7 without having to muck about in the metabase (where GUI changes on IIS6 get applied)

<location path="WindowsLogin.aspx" >
    <system.web>
        <authorization>
            <deny users="?" />
            <allow users="*" />
        </authorization>
    </system.web>
    <system.webServer>
        <security>
            <authentication>
                <anonymousAuthentication enabled="false" />
                <windowsAuthentication enabled="true" />
            </authentication>
        </security>
    </system.webServer>
</location>

回答2:

thanks for getting back to me, I have been playing round with several of the implementations on and off for a few weeks now, that I've read about on the internet (javascript, 401, 2 virtual directories) but still havnt really found anything that works as I wanted. We will be potentially rolling it out to more than one client-each with different hardware/setups even different versions of iis, so wanted it to be as generic as possible. Ive come up against a brick wall on a couple of the suggested solutions...

when you say for IIS7+ you removed anon access in web config, I assume like this: -

<location path="Authent/WinLogin.aspx" > 
  <system.webServer>
    <security>
      <authorization>
        <add accessType="Deny" users="?" />
      </authorization>
    </security>
  </system.webServer>
</location>

回答3:

I spent a few days trying to get this to work, with a slight difference... I wanted the first login screen to present the forms login with an button underneath "Login With Windows Authentication".

I eventually gave up on all these techniques, as I never could quite get the satisfactory results. My workaround was as follows, and works perfectly:

• Create a separate website "LoginWithIntegratedSecurity"
• Set this up with integrated security
• This web site creates a temporary "User Hash Key" in the database, which identifies the user
• Redirects back to LogonPage in Forms Authentication website with Hash key in url
• LogonPage in Forms Authentication checks for Hash key, and logs user in after database check

So if the User clicks the button "Login with windows Authentication", the server redirects to the windows authentication site (passing the "ReturnUrl"). This site challenges and logs in user, then redirects back, again passing the "ReturnUrl" as well as the HashKey.

This all happens very fast, and appears pretty seamless.

I know its a hacky workaround, but for my case it worked well.