Building Password-Protected Web Sites with Microsoft Internet Information Server

Covero Consulting Group, Inc.
Last updated Monday, March 20, 2000

There are at least five aspects to creating a password-protected web site:

  1. Registration
  2. Authentication
  3. Authorization
  4. Forgotten username/password retrieval
  5. Account maintenance

This document focuses on authorization. It describes possible ways to implement user authorization when using Microsoft's Internet Information Server, ISAPI, and Active Server Pages.

What is Authorization?

Authorization is the process of controlling access to Web-server based content on a user-by-user basis. For example, suppose there are three areas of a site: areas A, B, and C. Suppose the following users are allowed access to these areas as follows:
User Area A Area B Area C
Gordon Yes Yes Yes
Percy Yes No No
 

Suppose that the site directory structure has a separate directory for each area, e.g.:
When Percy attempts to access a file in area B, such as http://root/B/index.html, he should be told that he does not have access to that area of the site. When he attempts to access a file in area A, such as http://root/A/news.html, he should be allowed access.

Robust authorization should protect not just HTML files, but also any other files in the restricted area. For instance, Percy should not be able to download http://root/B/background.gif. Robust authorization should also protect files that exist on the Web server only for downloading. For example, suppose there's an Adobe Acrobat (PDF) file named FiscalYearSalesResults.pdf in area B that users with access to area B can download via a link on an HTML page in area B. Percy cannot view the page containing this link. But if Gordon emails the URL http://root/B/FiscalYearSalesResults.pdf to Percy, Percy should not be able to paste that URL into his browser and retrieve the file. A robust authorization system prevents Percy from accessing this file, either directly, or indirectly.

Possible Authorization Schemes

There are four realistic methods of authorization for a Microsoft Internet Information Server (IIS) system:
  1. Basic authentication
  2. ASP-based authorization
  3. Self-authenticating scripts
  4. ISAPI authentication filter

Basic Authentication

Basic authentication uses Windows NT user accounts to protect directories and files. Each user who accesses the system must have an account on that NT domain. Unless all pages in the site are protected by Secure Socket Layers (SSL), NT usernames and passwords will be transmitted in clear text. This creates a major security hole. Furthermore, performance can be very slow on an NT system that has many user accounts. For these reasons, basic authentication is only a viable system for intranet sites.
There is a commercial component called Dynamic Authentication Filter that maintains its own database of users, yet uses NT's security to protect content. When a user logs in via DAF, their session is mapped to an existing NT user account. The problem with this method is that you have to create a separate NT account for all possible combinations of areas. In the simple example above, you need accounts with the following security permissions:
  1. Area A
  2. Area B
  3. Area C
  4. Area A & B
  5. Area A & C
  6. Area B & C
  7. Area A, B, & C
Thus, you need 2^N-1 different accounts, where N is the number of different protected areas.

ASP-based authorization

ASP-based authorization requires that all protected pages be Active Server Pages, rather than HTML pages. A few lines of VBScript code are placed at the very top of each ASP page. This code checks to see whether the user is logged in, and if so, whether the user is allowed access to this page. If the user isn't logged into the system, he/she is redirected to a login page. If the user is logged in, but is not authorized to view this page, they are redirected to an error page that explains this.

This system is fairly simple to implement, but it has two disadvantages. First, it only prevents unauthorized access to ASP pages. Users can view any other file type if they know the URL of that file. Second, it requires adding code to every protected page; this can be simplified somewhat by using an #include statement to include the script code.

This system is further complicated if publicly-viewable pages contain direct links to protected content. Supposed, for instance, that a table-of-contents page contains direct links to PDF files within a protected area. Any user can view the table-of-contents page and see the link to the PDF file. They can copy this link, and paste it into their browser to access the PDF file directly, bypassing the authorization system.

This can be prevented two ways. The first is to create a hard boundary between public and protected content. Links to protected content are only visible once the user has logged in and crossed the boundary between the public area and the protected area. This method does not adequately protect content, though. If the site uses Microsoft Index Server to provide searching capability, content on protected pages will be added to the site search catalog, because Index Server reads the ASP pages in such a way that the security mechanism is bypassed. Thus, using the example users above, Percy could search the site for "Fiscal year sales," and the search engine may return a link to http://root/B/FiscalYearSalesResults.pdf. He can download this file directly, even though he's not supposed to have access to area B. Another security hole is that Gordon, who can get into area B, could send Percy the link to

The second method to protect non-ASP content is to include a level of indirection for downloaded files. Using a commercial file download component, such as ASPFile, links to downloadable files can be of the form http://root/B/DownloadFile.asp?name=FiscalYearSalesResults.pdf. The ASP page DownloadFile.asp is local to area B, and can enforce authorization. The actual PDF file can be stored outside of the Web server file structure, and thus, cannot be downloaded via a URL.

Unfortunately, this is not a panacea. Older browsers do not support RFC 1867, the upload/download protocol, although there's an add-on for Microsoft Internet Explorer 3.02. Microsoft Internet Explorer 4.0, 4.01, and 5.0 support this protocol, but contain bugs in their implementation of it. For some file types, IE will use the helper app to display the file in the browser, rather than downloading it. If IE does download the file rather than viewing it, some versions of IE will ignore that Content-Disposition HTTP header, which specifies the filename of the file being downloaded. When this occurs, IE will present a Save As dialog to the user without a filename filled in. It's then up to the user to decide what to name the file. Netscape 4.x browsers implement RFC 1867 properly; when the user clicks on a link such as http://root/B/DownloadFile.asp?name=FiscalYearSalesResults.pdf, they are presented with a Save As dialog with the filename FiscalYearSalesResults.pdf pre-filled in.

ASP-based authorization cannot easily protect images and other files references inline in a protected ASP page. Thus, it's possible for non-authorized users to download these files directly if they know the URL. This causes a security breach if these files contain sensitive content, such as a picture of an organizational chart.

Covero Consulting Group has created two large, commercial sites with ASP-based authentication and authorization. One of them used VBScript to manage authentication and authorization, and one used a combination of VBScript and a custom COM object we developed. ASP-based authorization is a good choice for sites that that need a reasonable level of protection, and reside on shared, commercially hosted servers. Commercial hosting services are very wary of adding custom ISAPI filters to their servers. If the site will reside on a dedicated server, this should not be an issue.

Self-Authenticating Scripts

Self-authenticating scripts is a system that uses a single URL to access all protected content. URL parameters an/or Session variables keep track of what page the user is viewing. If implemented in ASP, this basically requires that the site's entire content be contained in a single huge ASP page with a large number if IF statements. If implemented with an ISAPI Extension, the ISAPI code can pull the HTML and GIF resources from files to generate the various pages.

ISAPI Authentication Filter

An ISAPI authentication filter is a special type of DLL that is used by IIS. It can provide both authentication and authorization. The ISAPI interface specifies events that the filter can be notified of. This allows the filter to intercept requests to read files via HTTP. At this point, the filter can retrieve browser cookies, authenticate the user, etc.

ISAPI filters have a number of advantages. First, when properly written, they are very fast. Second, unlike ASP-based authentication, they can manage access to, and thus protect all file types, not just ASP files. Third, they require no modification to HTML or ASP files; the filter works automatically, behind the scenes.

ISAPI filters must be written in C/C++, and are somewhat complex to write. There's not very much documentation available, although there are several complete samples available via MSDN, including an authentication filter. Visual C++ contains a wizard that will generate a skeleton ISAPI filter.

There are commercial ISAPI authentication filters available, such as Authentix. Authentix can create its own database of accounts, or can retrieve username/password information via ODBC.

Return to top
Return to the Resources page
Contact us