views:

321

answers:

2

I have an administrative website on our intranet that currently uses Integrated Windows Authentication through IIS. We would like to move this application to a public website and secure it with SSL so our users can access it from anywhere.

I had been planning on using an HttpModule to redirect from http to https, but it doesn't look like this works with integrated authentication (the login popup appears before the redirect).

Am I stuck using the "require SSL" checkbox in IIS? This doesn't seem all that user friendly since the user gets a nice fat error page instead of a gentle redirect if they forget to use the https URL.

What would you do in this situation?

+1  A: 

We had similar issues on our intranet site and ended up switching from Integrated Windows Authentication to requesting their network username/password directly on the site. That way we can redirect them to HTTPS or other such things without worrying about when the authentication popup shows up.

We have some code similar to this (assuming you're using ASP.NET) that authenticates the user, and then we store the authentication state in a cookie.

public static bool AuthenticateUser(string username, string password)
{
    System.DirectoryServices.DirectoryEntry _entry = new System.DirectoryServices.DirectoryEntry(ldap_path, username, password, System.DirectoryServices.AuthenticationTypes.Delegation);

    bool _authenticated = false;
    try
    {
     Object _o = _entry.NativeObject;
     _authenticated = true;
    }
    catch
    {
     _authenticated = false;
    }
    finally
    {
     // Avoids the "multiple connections to server not allowed" error.
     _entry.Close();
     _entry.Dispose();
    }

    return _authenticated;
}

It ended up saving us tons of headache and frustration by handling all authentication in the application rather than depending on IIS.

JoshMock
Thanks for the response. I started leaning towards turning off the integrated authentication today anyway after learning that it probably wouldn't work outside the building.
Shea Daniels
Is there any particular reason you decided not the use the membership provider features and roll your own?
Shea Daniels
We already had a long-existing data structure that wasn't going to work with the standard .NET membership provider features.We could have implemented our own class that inherited from MembershipProvider but we didn't need all the properties and methods it requires so we decided to build our own stripped-down version instead.
JoshMock
A: 

I've solved this as an IIS problem every time, not a code problem:

  • create a new web site in IIS
  • bind it to the same IP address (and/or host header), to your SSL cert and to port 443
  • configure this to point to the same application root as the current port 80 site
  • test to make sure that directly connecting to https://site gives the expected responses
  • reconfigure the original site (still bound to port 80) to use the HTTP Redirect feature
  • configure the port 80 site to redirect to the port 443 site; optionally, remove the application and virtual directory mappings (in case someone accidentally disables the redirect)

From then on, any user that just types the web site address into their browser will get a lightning-fast redirect message from IIS that sends them to the SSL-protected version of the site.

ParanoidMike