IIS Security

Any Web server must be secured against unauthorized access; authentication is a requirement of any Web application. The IIS security mechanisms interact with ASP.NET security; Figure 19-1 shows how the CMS page request is typically processed through the IIS security checks and passed on to the worker process that provides the ASP.NET runtime environment.

Security in IIS is set up using the Directory Security tab (in IIS Manager, right-click the Web site and select the Properties > Directory Security tab), as shown in Figure 19-3. Before authenticating a user, IIS performs authorization checks on the client machine's domain name or IP address; these can be configured using the IP Address and Domain Name Restrictions dialog, shown in Figure 19-4 (the dialog is displayed when you click the Edit button in the IP address and domain name restrictions area in the Directory Security tab).

Figure 19-3. IIS Directory Security tab

Figure 19-4. IIS IP Address and Domain Name Restrictions dialog

After the client machine has been authorized, IIS attempts to authenticate the user. Every request is authenticated; every request operates in the security context of a user account. There are a number of configurable mechanisms for authenticating users in IIS. When IIS authenticates a user, it creates a worker thread using the user's credentials and then uses that thread to perform the requests. In this way, IIS relies on Windows to provide authorization and enforce security. IIS is a Windows service and runs in the context of the local system account. IIS uses impersonation to control security: When a user makes a request to the server, access to resources is performed as the user and not the trusted local system account; while the actual InetInfo process runs as System, the worker thread runs in the context of the user.

Impersonation

Impersonation is the ability of a thread to execute in a security context that is different from the context of the process that owns the thread; it is a term for the adoption of a different security identity. Impersonation is especially useful within server applications to ensure that that user making the request has sufficient permissions to complete the processing. The application impersonates that user and attempts to perform the action; Windows security will either allow or deny the access to a requested resource.

IIS 5 and IIS 6 support several methods of authentication:

• Anonymous access

• Basic authentication

• Digest authentication

• Integrated Windows authentication

• Certificate authentication

The Authentication Methods dialog, shown in Figure 19-5, provides the ability to configure the first four methods in the list (the dialog is displayed when you click the Edit button in the authentication control area in the Directory Security tab).

Figure 19-5. IIS Authentication Methods dialog

NOTE: IIS 6 provides two additional authentication methods: Advanced digest authentication, and Universal Naming Convention (UNC) authentication. To enable these methods, you need to configure the appropriate metabase properties: UseDigestSSP, and UNCUserName and UNCPassword, respectively. For details, refer to the IIS 6 product documentation.

Anonymous Access

Anonymous access is the default method of authentication for IIS. It is used to provide access to the resource for any user and does not require a user to supply a user name or password. In order to process a request, IIS must use an identity for authorization; by default, IIS impersonates a local account, IUSR_<machinename>, to process anonymous requests. You can manually change this account by clicking the Edit button in the anonymous access area of the Authentication Methods dialog (Figure 19-4) and supplying the credentials for a new account.

Basic Authentication

Basic authentication is part of the HTTP specification. Being a standard mechanism means that it has the widest support among Web browsers and Web servers. With Basic authentication, the browser displays a login dialog to allow a user to enter a user name and password, which are then passed to the Web server via the HTTP headers. The information that the user enters is base-64 encoded before it is sent over the network. This encoding scheme can be easily decoded; therefore, this method of authentication should never be considered secure unless protected by an appropriate encryption such as Secure Sockets Layer (SSL). On the server, the user credentials are authenticated against the Windows security accounts on one of the domains or servers on your network, the user is logged on locally on the Web server, and then IIS impersonates the request to access resources.

Basic authentication works with nearly all browsers and is not affected by proxies or gateways.

Digest Authentication

Digest authentication is a challenge-response mechanism that sends a password digest, or hash, over the network. The password never crosses the network. The browser encrypts the digest using a password entered by a user and passes it to the server; the server compares the encrypted digest with the one generated from the stored password; if they are the same, then the user is authenticated. Digest authentication is more secure than Basic, but the use of SSL is still recommended.

Digest authentication only works with IE5 and later; it is unaffected by proxies or gateways.

IIS 6 introduced a stronger version of digest authentication called Advanced digest authentication. The difference between the versions is that with Advanced digest authentication the user credentials are stored on the domain controller as a hash, and therefore they cannot be read by anybody with access to the domain controller, even the domain administrator. However, the authentication algorithm used between IIS and the client remains the same.

Integrated Windows Authentication

Integrated Windows authentication is a challenge-response mechanism that uses either Kerberos v5 or NTLM (NT LAN Manager) authentication. A negotiation process between a client and a server is used to determine which one will be used. If the server is in a nondomain environment, then NTLM authentication will be used; if the server is in an Active Directory domain where a Key Distribution Center (KDC) is available, then Kerberos may be used as an authentication mechanism. The browser will attempt to automatically use the credentials of the currently logged-on user to connect to the Web server; usually, no logon dialog is presented to the user. Both Kerberos and NTLM use strong hashing algorithms, and therefore the Integrated Windows authentication mechanism provides the strongest form of security we've discussed so far.

Integrated Windows authentication requires that clients run IE5 or later in the Windows environment. This mechanism does not work over proxy servers or firewalls; therefore, it performs best in an intranet environment.

Certificate Authentication

The Certificate authentication mechanism provides the ability to authenticate the user if a recognized certificate is present in the HTTP request. Using the Secure Communications dialog, shown in Figure 19-6, you can configure IIS to require or accept client certificates. By default, they are ignored.

Figure 19-6. IIS Secure Communications dialog

To enable Certificate authentication, you have to install the server certificate and enable SSL as well as establish the certificate trust list (CTL) that will list the certification authorities (CAs) whose certificates your site will trust.

NOTE: To use client certificates, user browsers need to have certificates installed and be configured to present certificates as part of the request.

Each client certificate will be checked against the CTL as a first step for authentication. For users with accepted certificates, you can then require that they use Basic, Digest, or Integrated Windows authentication, or you can map the client certificates into Windows user accounts. You can map one certificate or multiple certificates to one Windows account.

If you choose to require certificates, then users without certificates will be denied access. For users with certificates, the certificates will be validated against the CTL. If the certificates are valid, either the users are asked to identify themselves using Basic, Digest, or Windows Integrated authentication, or their certificates are mapped to Windows accounts.

If you choose to accept certificates, users with certificates will be authenticated as just described; users without certificates will be required to authenticate using Basic, Digest, or Windows Integrated authentication.

Certificate authentication is the most secure authentication mechanism; it is particularly well suited for business-to-business (B2B) communication over the Internet.