Top ASP 101 Stories The Top 10 ASP Links @ Microsoft.com What is Adovbs.inc and Why Do I Need It? An Overview of ASP.NET QUICK TIP: Read the VBscript Documentation Show All Tips >>  ASP 101 Updates

Authentication Tutorial

Hello! And welcome to my quick and easy guide to authentication. In an effort to make this as painless as possible, I’ve laid this out in two steps. First, I’ll explain Authentication: What it is, how you work with it, and what options are currently available to you. Then, I’ll explain each choice in more detail to help you decide which is the best way for you to authenticate your web users! Sound good? Let’s get started!

What is Authentication?

Let's assume you want to restrict access to your website. For example, you might have valuable information, such as real-time stock quotes (like Reuters or Datastream), or you want to charge a monthly fee in order to access your database of superbowl picks or you may be such a nice person that you don’t want to charge your visitors a dime, just want to track your visitors.

In these cases, you want to let people in, but only after checking that the visitors have an authorized username and password. Additionally, you might want to limit certain visitors to only certain areas of your website. It may be OK for your mom to see your online photo album/ geneology tree, but you wouldn’t want her to get a jump on the family superbowl pool by seeing your expert picks, no would you?

So, have you figured it out yet? Verifying that a visitor is authorized to visit a particular part of your website (usually via a username and password) is called Authentication. Authentication allows you to control the access to your entire website.

What are my choices?

IIS

Internet Information Server, this is a part of Windows NT/2000

SSL

Secure Socket Layer, provides a secure connection between the user and your website server.

ODBC

Open Database Connectivity. An ODBC is a database such as Microsoft Access, or SQL 7.0.

ASP

In this case, we are referring to Active Server Pages.

Assuming you have the latest and greatest IIS, you have several choices when working with authentication including:

IIS NT Challenge Response

A good choice if you are on a Windows Network, you can require that your visitors use Internet Explorer, and there's no proxy-server between the browser and the server.

IIS Basic Authentication

Can expose your NT usernames and passwords unless all connections are over SSL. Connections over SSL are generally slower than non-SSL connections.

A Basic Authentication filter such as AuthentiX

Since it runs separately from NT accounts, it cannot compromise NT accounts! It can maintain high performance with a large numbers of users. And it can validate your visitors against an ODBC or internal database. Many advanced features.

Write your own filter

Flexible, but resource intensive to build. (read:"You will not have a life for two months".)

Cookie Based Authentication with ASP pages

Only protects ASP pages. Can be slow. Requires cookies. Cookie-based systems can be susceptible to spoofing (impersonating).

Self-Authenticating ISAPI dlls, CGI-scripts using Basic Authentication.

Good performance, all content generated though a single URL. Doesn't use conventional directory/file/html format.

Certificate based.

Secure, but intimidating for webmasters and surfers alike. Requires SSL, which as we stated above, could lead to a hit on your website’s performance.

Which should I use?

In deciding which type of Authentication to use, it's important to keep the following points in mind:

• You want to accommodate the widest possible audience, along with browser and platform independence. (NTCR and cookies are limited, and may not work with a broad audience)
• Performance is critical. If (as you hope), your site becomes wildly popular, you don't want a dead-slow server (SSL/Certificates, ASP, and cookies can be slow)

So, what are your choices?

NT Challenge Response

NTCR

NT Challenge Response

NTLM

NT Lan Manager

NTFS

NT File System

Using NT Challenge Response is an obvious choice, and is included as one of the options when you set up each IIS directory. Any directory you want to protect must be on a NTFS partition.

How to set up NTCR

In Internet Service Manager (IIS1-3) or the Microsoft Management Console for IIS (IIS4 and up) select the directory you want to protect. Make sure Basic (Clear Text) is off and Windows NT Challenge Response is on. You can leave Allow Anonymous on.

Create an account for each user you want to provide access, remove the permissions for "IUSR_machinename" from the directory, and add permissions for the added users. Alternatively, you could set up a group, permit access to that group, and add permitted users to the group. Remember, the user will need execute rights if the directory has any ASP, ISAPI extensions, counters, and so on.

Note that when the user returns to a non-protected page, they will be prompted for their username and password again, unless you have also granted them read-access to non-protected pages. However canceling the prompt will let them in, disconcerting though this may be.

If the user has permission to access the directory but is in a different domain than the IIS machine, the user will have to prepend the domain name, so IIS knows where to look for the password.

Because NTCR uses a token mechanism for verifying users, the password of the currently logged in user is not available to IIS. This will have an impact if you are trying to access a resource which is not on the same machine as IIS, since IIS will not be able to login using the current user to a machine elsewhere on the LAN. For example if an NTCR protected ASP page tried to read an Access mdb file on another machine, it would fail. Similarly for SQL Server with Integrated or Mixed security. See Q166029, Q149425.

NTFS is the way to go if you are on a Windows Network.

For intranets NTCR can be an ideal solution, where all users are on accessible domains, there aren't too many users, and you can require the use of a compatible browser (Internet Explorer is the only browser which supports NTCR).

You won't want to use NTFS if

• you want compatibility with browsers other than IE, or older browsers
• you want to protect directories on FAT partitions
• you expect (don't we all?) a large number of users Having a large number of users becomes a problem because this clutters the NT user database and it becomes very difficult to maintain. It can also impair the speed of the operating system itself! Using the NT user base can also be a problem because of potential security risks. You are elevating a 'mere' web surfer to the status of a full NT user. You have to be careful not inadvertently grant too many permissions.
• there's a proxy server involved As documented in the IIS 4 Resource Kit, NTLM will not work through a proxy. The problem is that it requires more than 1 round trip to complete authentication and so needs a persistent connection end to end end, from client to origin server. Proxies don't generally work that way.

IIS Basic Authentication

On the world wide web, the oldest and most widely supported authentication method is Basic Authentication. IIS Basic Authentication is included as an option when you set up each IIS directory. Any directory you want to protect must be on a NTFS partition.

SSL

Secure Socket Layer

How to set up IIS Basic Authentication

Setting up IIS Basic Authentication is similar to setting up NTCR.

In Internet Service Manager (IIS1-3) or the Microsoft Management Console for IIS (IIS4 and up) select the directory you want to protect. Turn on Basic (Clear Text) and turn off Windows NT Challenge Response. It is OK to leave Allow Anonymous on.

When you select Basic (Clear Text) you will be warned that you Windows NT usernames and passwords will be transmitted without being encrypted. For your NT accounts this is a pretty serious issue. You should only consider this option in combination with SSL, which is slow and requires you to buy a certificate from Verisign or Thawte (among others).

Create an account for the each user to whom you want to give access, remove the permissions for "IUSR_machinename" from the directory, and add permissions for the users you added.

Alternatively you can set up a group, permit access to that group, and add permitted users to that group.

Remember the user will need execute rights if the directory has any ASP, ISAPI extensions, counters etc.

IIS Basic Authentication is the way to go if you accept the need for SSL and don't mind paying the performance penalty. Keep in mind that you will need a SSL certificate if you don't already have one.

You won't want to use IIS Basic Authentication if you are concerned about the security of your NT accounts and performance. IIS calls LogonUser and ImpersonateLoggedOnUser for each and every request, which is expensive in terms of CPU cycles.

A Third Party Basic Authentication filter

AuthentiX is a fast, filter based third party tool for IIS authentication developed by Flicks Software (me).

It allows you to password protect your website (directories and individual files) by asking visitors for their usernames and passwords. It works separately from the Windows NT usernames and passwords, ensuring the security of your NT accounts!!

How to set up AuthentiX, a third party Basic Authentication filter

Setting up AuthentiX is easy and straight-forward.

• Download the free evaluation version, unzip it and run setup.exe. Installshield will guide you through the rest of the installation process.
• Make sure Basic (Clear Text) is off and Allow Anonymous is on. You can leave Windows NT Challenge Response on or off.
• Create a user. From the main AuthentiX dialog, click the Users button, then Add. Type a username and password and click OK. The user will be added to the User List. Click OK.
• Create a group. From the main AuthentiX dialog, click the Groups button, then Add. Type a Groupname, click on a user (to highlight it) listed in the Non-Members list box, and click Add. The user will be moved to the Members list box. Click OK. You should now see the group in the group list. Click OK.
• Protect a directory. From the main AuthentiX dialog, click the Access button, then Add. Click the Browse button and select a directory that is part of your web directories, and that you would like to protect. Click the By Group button and add the group you created in the previous step. Click OK. You should now see that the group is protecting that directory. Verify that the group is protecting the desired directory and click OK twice
• Using a browser, go to the URL that the directory is accessed from using IIS. It should prompt you for your username and password.
• Type the username and password and you should be granted access.

You can see how to set up ODBC and other advanced options by downloading the online Windows help file or checking out the online Guided Tour. Because the pace of enhancements and improvements to this product sometimes outstrips the documentation, you can find out more by working with the free evaluation download.

Authentix, a third party Basic Authentication filter is the way to go if

• You want the high performance that a filter offers
• You want to be able to add and modify users from ASP pages and don't want the ASP pages to have SysAdmin priviledges
• You want browser independence
• You don't want any chance of compromising NT username/password security
• You want to separate your web-users from your NT Accounts
• You are concerned about performance. In addition to the speed associated with filter based solutions, AuthentiX is unique in that it does not impersonate an NT account to grant access, eliminating the CPU-expensive call to LogonUser on every request.
• You have directories you want to validate against an ODBC database
• You want to authenticate multiple IIS servers against a single ODBC machine on the LAN.
• You want to use browser based remote administration
• you need to protect all content in a directory: htm, asp, gif, jpg, zip, and so on.
• you want advanced features like
  • limiting concurrent logins
  • bandwith, request and login throttling
  • protect by IP, Domain Name and by referrer

You won't want to use a third party Basic Authentication filter if

• protecting your premium content directories does not warrant the price of registration.
• Basic Authentication is not secure enough for your purposes
• you want all accounts of every type in one userbase, specifically the NT user account database, for administrative reasons.

Write your own Basic Authentication filter

Writing your own Basic Authentication filter is an option if you have the skills, resources and time to do it.

ISAPI

Internet Server Application Programming Interface

How to write your own Basic Authentication filter

You will need to build a dll that conforms to the ISAPI filter specification and has the following entry points:

• GetFilterVersion
• HttpFilterProc

The GetFilterVersion function is the first entry point called by the Internet Information Server. In this function you set the IIS notifications that you want to receive, and any other first time setup tasks.

The HttpFilterProc function is called in response to the notifications set in GetFilterVersion and is where the work of the filter is actually done.

There are several excellent references to help develop an ISAPI filter. Recommended is Que's "Special Edition Using ISAPI", ISBN 0-7897-0913-9 (to which this writer also contributed).

Writing your own Basic Authentication filter is the way to go if

• you have special requirements, and commissioning a custom enhancement to a third party Basic Authentication filter is not an option.
• you have the skills, resources and time.
• you want to validate against a specific or proprietary type of datasource, such as flat-file, or your own database.

You won't want to write your own Basic Authentication filter if

• you have a short deadline
• you do not have the skills or resources required
• Basic Authentication is not secure enough for your purposes
• you want all accounts of every type in one userbase, specifically the NT user account database, for administrative reasons.
• a third party tool like AuthentiX meets all your needs

Cookie Based Authentication with ASP pages

You can use the cookie based session variables of Active Server Pages to capture a username and password from a form, validate the username and password, then set a session variable to indicate the user has correctly logged in. (Note: AuthentiX V2 and up can protect via cookies, but protects all pages, not just ASP).

ASP

Active Server Pages

How to use Cookie Based Authentication with ASP pages

1. Create a login page like the following example:
   
   Login.asp

   <form action="loginNow.asp" method="POST">
   Username: <input type="text" name="username" size="22"><br>
   Password: <input type="password" name="password" size="22"><br>
   <input type="submit" value="Login Now">
   </form>
   

2. Create an ASP page to receive and process the results like the following example:
   
   LoginNow.asp

   <% 
   username = Request.Form("username") 
   password = Request.Form("password") 
   If ("George" <> username) Then 
   	Response.Write("Sorry, incorrect username and password (1)") 
   	Response.End 
   End if 
   If ("Washington" <> password) Then 
   	Response.Write("Sorry, incorrect username and password (2)") 
   	Response.End 
   End if 
   Session("username") = username 
   %> 
   George, you have logged in successfully.
   <a href=protected.asp>Please continue to the protected page</a>
   

3. In each ASP page to be protected, check the username and password. You could use an include file statement if you had several ASP pages and wanted a single file to do the checking.
   
   Protected.asp

   <% 
   username = Session("username") 
   if ("" = username) Then 
   response.Write("Sorry, you are not logged in.") 
   response.End 
   End if 
   %> 
   You have access to this Active Server Page! 
   

Cookie Based Authentication with ASP pages is the way to go if

• You are happy coding your own solution in VBScript, and you only have a few asp pages to protect.
• You don't mind excluding those who cannot or will not accept cookies.
• You don't have gif/jpeg/pdf or other non-ASP content, so you are not concerned about someone else creating web-pages linking directly to your non-ASP protected content.

You won't want Cookie Based Authentication with ASP pages if

• You want to protect all content, not just ASP pages.
• You are worried about performance. Any reasonably large amount of Active Server Pages can have a significant detrimental effect on the performance of your server. The popularity of products such as XBuilder, which generates static html pages from ASP pages for performance reasons (among others), illustrates this point.
• Cookie-based systems can be susceptible to spoofing.

Self-authenticating scripts.

Self-authenticating scripts usually provide a single URL entry point, with parameters indicating the current state of the session and the content requested. Self-authenticating scripts can be written as ASP, CGI, Win-CGI, or ISAPI dlls, and other variations.

ASP

Active Server Pages. The script communicates with IIS via server-variables.

CGI

Common Gateway Interface. The script communicates with IIS via stdin and stdout.

Win-CGI

Windows Common Gateway Interface. The script communicates with IIS via temporary INI files.

How to use Self-authenticating scripts

There are too many variations to show how to create a self authenticating script in this tutorial, however they all share a common means of authenticating.

When a request comes in and the content to be displayed is protected by a Basic Authentication username and password, the script sends a 401 Access Denied message, indicating the realm, and some html that is displayed to the user when the login attempt fails.

A regular http reply looks like this:

HTTP/1.0 200 OK 
Server: Microsoft-IIS/3.0 
Date: Wed, 11 Mar 1999 16:31:52 GMT 
Content-Type: text/html 
Last-Modified: Wed, 18 Feb 1998 22:45:46 GMT 
Content-Length: 1234 
Content: Interesting Stuff 

A 401 Access denied reply looks like this

HTTP/1.0 401 Access Denied 
Content-type: text/html 
Server: Microsoft-IIS/3.0 
Date: Wed, 11 Mar 1999 16:35:47 GMT 
WWW-Authenticate: Basic realm="Message in Popup" 
Content: You cannot get in!

Once the script sends a 401 Access Denied message, the browser will pop up a dialog indicating the realm, and invite the user to enter a username and password. The user will not see the access denied content unless the login fails. Some browser keep retrying the pop-up dialog until it succeeds or the users escapes out, others only pop-up three times.

If the user types in a username and password the browser will send them to the server as a part of the http request header that looks like the following:

Authorization: Basic cGvcmU6cGRcmU= 

The string "cGvcmU6cGRcmU=" is Base64 encoded.

The script will ask the server for this header by requesting the server variable HTTP_AUTHORIZATION, and decode it. The resulting string will be in the format username:password and the script can match these against acceptable values in order to determine whether to transmit the content or issue another 401 Denied.

NB: In IIS4, the HTTP_AUTHORIZATION value may not be returned correctly by IIS. In MMC, select the directory in which the ASP page calling this function resides. If Basic (Clear Text) is off, and NTCR is on, then HTTP_AUTHORIZATION will not return the correct value. This problem did not occur in IIS3. Microsoft bug Case Number is SR X980 2166010 644. Recommended workaround is to either

• turn Basic (Clear Text) off and NTCR off for that directory.
• turn Basic (Clear Text) on and NTCR on for that directory, Make sure that Allow Anonymous is checked.

Self-authenticating scripts is the way to go if

• You have the skills, resources and time to do it.
• You want to generate your content in a single program

You won't want Self-authenticating scripts if

• You want protected content in normal directory/file/html format
• You are worried about maintaining the content. Scripts can become fairly complex when the content becomes large, and changes are not easily made. If you have content stored in a database then this can be more flexible, but you have the added complexity and performance hit of interfacing to the database.

Certificate based authentication.

Client certificates are an advanced form of authentication, and at this time they are still very much in their infancy with respect to compatibility and ease of use.

SSL

Secure Socket Layer.

MMC

Microsoft Management Console.

How to use Certificate based authentication

Since this technology is still maturing, be sure to have the latest version of IIS4 installed on your system.

• Obtain a certificate from a certificate issuing authority such as Verisign or Thawte. Refer to the IIS documentation on Key Manager.
• Select a directory you want to protect in the MMC
• Click on the Secure Communicatations Edit button on the Directory Security property sheet and use the certificate you obtained. Select both Enable Client Certificates and Require Client Certificate
• Enable client certificates for this resource
• Issue client certificates for access to this resource.

There are several good references to help understand and use Client Certificate technology. Some articles that are recommended include:

• "Internet Information Server 4.0 - Security for the Web-Enabled Enterprise" by Nick Evans in the Premier Edition of Security Advisor by Advisor.com publications
• "Web Project, Digital IDs" by Jon Udell in the March Edition of Byte magazine
• "Issuing digital certificates with Microsoft Certificate Server" section of the IIS Security White Paper by Microsoft

Certificate based authentication is the way to go if

• You want a high degree of certainty of the identity of the users accessing your site.
• You accept the need for SSL and don't mind paying the performance penalty.
• You already have a certificate or you don't mind paying for one and setting it up.

You won't want Certificate based authentication if

• The process of issuing a client certificate is too complex and intimidating for both you and your users.
• You do not want the performance hit of having all protected information exchanged via SSL.

Conclusion

So that is basically it! We’ve covered every single way known on password protecting your website. Remember to develop a plan that addresses the needs of your visitors and your website’s security needs. They work in conjunction with eachother, and if you neglect one for the other, you were surely have consequences.

By Kevin Flick, Flicks Software