Forms Authentication
Forms authentication, which was available as an add-in option to earlier IIS versions, is now integrated in IIS 7.0. In contrast to the other authentication methods that IIS 7.0 supports, forms authentication lets web-application administrators and developers manage user registration and authentication at the application level, without needing to use the built-in Windows authentication mechanisms and identities.
Forms authentication uses a redirection mechanism to a logon page to determine the user’s identity. When a user connects to a document hosted on a site that’s protected using forms authentication, the user will enter his or her username and password at a logon screen, which then passes the user’s credentials to an authentication and credentials database, such as a Microsoft SQL Server database. The forms-based authentication mechanism then performs some sort of matching process to verify that the entered credentials match what’s in the forms-based authentication credential database.
The new out-of-the box support for forms authentication is possible because in IIS 7.0 Microsoft merged the IIS and ASP.NET authentication models, aka the IIS and ASP.NET authentication pipelines. In the pre–IIS 7.0 model, IIS examines a web request, performs its authentication routines, then passes the request to ASP.NET so that it can perform similar authentication tasks.
In IIS 7.0, Microsoft has produced a new unified authentication pipeline that incorporates the best aspects of the older models. IIS 7.0 still supports all the old authentication protocols as well as forms authentication. Prior to IIS 7.0, forms authentication could be configured only for ASP.NET web content, whereas in IIS 7.0 forms authentication can be used for all content types. Having only one IIS authentication model to deal with greatly simplifies the jobs of web administrators and .NET application development.
Windows Authentication
IIS Windows authentication (called Integrated Windows authentication in earlier IIS versions) consists of two authentication protocols: NTLM and Kerberos, which are typically supported only in Microsoft browsers. (Windows authentication never transmits the password in the clear and thus doesn’t require the use of SSL/TLS.)
Of all the web authentication protocols I’ve discussed so far, Windows authentication requires the least configuration and user intervention. Windows authentication doesn’t prompt the user to provide his or her credentials in a dialog box; instead, IE automatically retrieves the credentials from the user logon session’s credentials cache—unless Integrated Windows authentication has been disabled in the IE configuration settings. In IE, you can enable or disable Integrated Windows authentication support through the Enable Integrated Windows Authentication setting on the Internet Options Advanced tab. (You need to restart IE for this setting to take effect.)
Windows authentication also has some less-attractive features. For example, NTLM authentication doesn’t work across most HTTP proxies because it requires persistent point-to-point connections between the web browser and server. The IIS web server keeps the HTTP connection open for the duration of the NTLM challenge/response sequence. But web proxies typically close the HTTP authentication connection after they receive a 401 Access Denied HTTP error message (which is a part of the NTLM challenge/response sequence). Notable exceptions to this rule are the Squid proxy (www.squid-cache.org) and Microsoft ISA Server running in proxy (cache-only) mode: These proxies can deal with NTLM authentication traffic. A possible workaround for the NTLM proxy issue is to tunnel the HTTP traffic using, for example, an IPsec or L2TP tunnel. But then again, few organizations allow the creation of VPN tunnels that bypass their proxies and/or firewalls.
Kerberos authentication is available only on IE 5.0 or later browsers and IIS 5.0 or later web servers. For Kerberos authentication to work, the browser user and web server must be in the same or a trusted Windows 2000 or later domain, the browser must have permanent access to a DC (which means that you must open Kerberos TCP port 88 on your firewalls), and the web server must have a valid Service Principal Name (SPN) that’s registered in AD.
Given these limitations, Windows Authentication is best suited for intranet web authentication and is unsuitable for authentication in an extranet or Internet environment where web browsers and servers are separated by proxies and firewalls.
Client Certificate–Based Authentication
Client certificate–based authentication uses the SSL/TLS protocols to authenticate web users. To use this authentication method, your web server must have a server SSL certificate installed and you must deploy certificates to your clients. Although client certificate–based authentication is the most secure form of web server authentication, it includes the overhead of obtaining and managing client certificates. You can obtain client certificates either by buying them from commercial Certification Authorities (CAs) such as VeriSign or through your internal public key infrastructure (PKI).
IIS supports a mapping mechanism that lets administrators map client certificates to AD or SAM (the local security database on a standalone Windows machine) accounts. This mapping enables both strong authentication and authorization simultaneously: External users can authenticate to web content using certificates, and administrators can use an internal account for setting permissions on their resources and constraining what data external users can access.
As in previous IIS versions, IIS 7.0 still supports AD-level and IIS-level certificate mapping. AD-level mapping means that the certificate mappings are stored in one central AD that multiple IIS servers can leverage. IIS-level mapping means that the certificate mappings are defined in an IIS server’s configuration files.
Unlike in previous versions, the certificate-mapping configuration options are no longer available through the IIS Manager snap-in. But you can still configure certificate mapping either by directly editing the IIS XML configuration files or by using WMI, the appcmd.exe tool, or a Visual Basic (VB) script. You can find a useful sample VBScript script for setting up certificate mapping at http://blogs.iis.net/ulad/archive/2007/01/19/vbscript-to-configure-one-to-one-client-certificate-mapping-on-iis7.aspx. And you can get more information about configuring certificate mapping in IIS 7.0 at http://go.microsoft.com/fwlink/?LinkId=78498.
More Authentication Choices
IIS 7.0 offers a rich array of authentication options, to enable you to choose the level of authentication that will adequately secure your web server from unauthorized access. Unlike earlier versions of IIS, which enabled all authentication types by default, IIS 7.0 offers authentication options as separate components, requiring you to select and enable only those you really need. This gives you more control over IIS authentication and also might help you to give more thought to the type of web server authentication that’s optimal for your environment.