Protect your Web sites with certificates and SSL
Microsoft Internet Information Services (IIS) 5.0 is an extremely scalable, robust, and versatile platform for building both intranet and Internet Web sites. Like most Web servers, it can serve up both static and dynamic Web pages and provide secure communications by using the Secure Sockets Layer (SSL) protocol. Unlike many other Web servers, IIS can leverage the security features of Windows 2000 to authenticate users and authorize their access to content in a fashion that requires no work for the Web developer. One of those security features is the built-in support for certificates. You can issue certificates to both Web servers and end users to effectively enhance and maintain security.
Authenticating Users
Web developers commonly build a database, Web pages, and scripts for the purpose of authenticating users. These items work together to request that users enter their usernames and passwords. A script looks up the username in a database table that contains details about users, including their passwords. If the script finds a matching username, it compares the password the user entered with the password in the table. (If the table stores only hashed passwords for security reasons, a script must hash the password the user entered before comparing it with the one in the table). If the passwords match, the user is considered authenticated. Building your own system to authenticate users becomes more complex when the site must let users manage their accounts or must authorize users before letting them view content. A developer might spend many days or weeks writing complex pages and scripts. One very real danger is that bugs can slip through testing and an intruder can exploit those bugs to bypass the authentication or authorization mechanisms.
With Win2K and IIS, the developer doesn't need to worry about developing authentication and authorization code. In its default configuration, IIS accepts both Anonymous and Integrated Windows authenticated connections, as Figure 1 shows. For Anonymous connections, IIS reads pages and executes scripts within the security context of the IUSR_machinename account (by default) or another Windows user account that you specify, as Figure 2 shows. When the specified account has access to the content the user wants to browse, the server won't require the user to authenticate. When the user attempts to access pages for which the specified account isn't authorized, IIS will require authentication. IIS 5.0 can authenticate a user with Basic authentication, Digest authentication, Integrated Windows authentication, and client-certificate mapping. Each of these methods has benefits and drawbacks, which Table 1 summarizes.
In a homogeneous environment in which all clients and servers run Windows and Microsoft Internet Explorer (IE), you can safely rely on Integrated Windows authentication. In a heterogeneous environment (i.e., one in which the clients run OSs and browsers from multiple vendors), you'll have to choose authentication methods that the clients support. (IIS can support multiple authentication techniques simultaneously.) I concentrate on Basic authentication and client certificate mapping in the remainder of this article because these methods offer the best cross-platform support.
Regardless of the authentication type you choose, users must have a valid Windows account to be authenticated. This requirement causes many developers to implement custom authentication mechanism out of a fear that users with Windows accounts could somehow be a security threat or that Active Directory (AD) can't scale to support a large number of users. The reality is that a well-planned and well-managed environment that includes appropriate precautions has no appreciable security exposures, and AD can scale to accommodate the demands of even the busiest Web site. Using Windows authentication mechanisms makes enforcing security easier because the developer doesn't need to code usernames and passwords into scripts. This advantage applies even to multi-tier Web architectures with application and database servers because the Web server can delegate user security contexts to those systems.
Authorizing Access to Content
You can protect IIS content by setting entries in the ACLs that protect the pages, scripts, and executables stored in the file system. (Note that this feature is available only with NTFS.) When a user accesses a site anonymously and attempts to access content to which the Anonymous account doesn't have permission, IIS attempts to authenticate the user in an exchange with the user's browser. If you've configured IIS to request Basic or Digest authentication, the user will be prompted to supply credentials such as a username, domain, and password. Other authentication methods use the credentials that users supplied when they logged on to their workstation or a certificate in the users' profile. IIS receives the credentials and uses native mechanisms in Win2K to authenticate the user. When the user is authenticated, a token is created for the user, which contains (among other information) his or her SID and the SIDs for the groups of which the user is a member. IIS compares SIDs in the token against the entries in the ACL to determine whether the user is authorized to view the content or run the scripts or executables.
If a user repeatedly fails to provide credentials that have the necessary permissions to access the restricted content, IIS returns an Access Denied error page. You can also set permissions in databases such as Microsoft SQL Server and on objects accessed from dynamic Web pages to authorize users for specific data and actions. IIS delegates the user's security context to these resources.
Securing the Authentication Process
The first step in securing any authentication process is configuring the logon privileges granted to the user accounts that visitors to your Web site use. The logon privileges that you can grant to a user account are Access this computer from the network, Log on as a batch job, Log on as a service, and Log on locally. Win2K introduced the deny privileges Deny access to this computer from the network, Deny logon as a batch job, Deny logon as a service, and Deny logon locally.
Prev. page
[1]
2
3
next page 
