For this sample I've created a new IIS application within the IIS 6.0 admin tool called "wildcardtest".  It points to a directory that will contain a few files: "default.aspx", "login.aspx", "test.asp" and "test.htm" (these last two files being resources not usually handled by ASP.NET):

Figure 1

By default when a URL request for a .aspx page comes to the application, the ASP.NET ISAPI will process the request.  By default when a URL request for test.asp comes to the application, the classic ASP ISAPI will process the request - and no ASP.NET code will run.  When a URL request for test.htm comes to the application, IIS6 will process the request internally - and again no ASP.NET code will ever run.

We'll change this by enabling wildcard mappings for this application, and configure ASP.NET to run code before and after all requests to the server.  To-do this, right-click on the application within the IIS Admin Tool and select the "properties" context menu item on it.  This will bring up the application properties dialog:

Figure 2

You can then click the "configuration" button to pull up the URL mapping rules for the application:

Figure 3

Note how the top of this dialog lists the default ISAPI extension mappings (each URL extension is mapped to an ISAPI responsible for processing it).  The bottom half of the dialog lists the "wildcard application map" rules.  We can add a application wildcard mapping to the ASP.NET ISAPI by clicking the "insert" button, and pointing at the ASP.NET 2.0 ISAPI extension on disk:

Figure 4

Very, Very Important: Make sure that you uncheck the "Verify this file exists" checkbox.  If you don't do this ASP.NET URL resources like WebResource.axd and other URL's handled by ASP.NET that aren't backed by a physical file won't work anymore.  This will lead to errors within your pages.

Now close out all of the dialogs by clicking "ok" to accept the changes.  You've now configured ASP.NET to be able to run code before and after each URL request into the application.

Enabling Forms Authentication and Url Authorization for non-ASP.NET resources

Once we've completed the above steps to register ASP.NET 2.0 as a wild-card mapping for all URLs into our IIS application, we can then use the standard ASP.NET authentication and authorization techniques to identify users in our application and grant/deny them access to it.

For example, we could add a web.config file to our application that enables ASP.NET's forms authentication feature for this application, and sets up two URL Authorization rules that deny "anonymous" users access to both the test.asp and test.htm URLs:

Listing 1

<span lang=EN><?xml version="1.0"?>
 <configuration>
     <system.web>
         <authentication mode="Forms" />
     </system.web>
     <location path="test.asp">
         <system.web>
             <authorization>
                 <deny users="?"/>
                 <allow users="*"/>
             </authorization>
         </system.web>
     </location>
     <location path="test.htm">
         <system.web>
             <authorization>
                 <deny users="?"/>
                 <allow users="*"/>
             </authorization>
         </system.web>
     </location>
 </configuration> </span>

Now, when I attempt to access either "test.asp" or "test.htm", the ASP.NET authentication and authorization system will execute first to check whether I'm logged into the application with forms-authentication, and if not redirect me to the login.aspx page within my application for me to login:

Figure 5

Note how the "ReturnUrl" used by ASP.NET's forms authentication system above has automatically set the "test.asp" url to redirect back to once I'm logged in (this works just like it would for a .aspx page).  Once I successfully enter a username/password, I'll then have access to the test.asp page:

Figure 6

Since the above page is a classic ASP file, I obviously don't have a "User.Identity.Name" property that I can use to identify the logged in user like I would in an ASP.NET page.  However, I can retrieve the "AUTH_USER" ServerVariable value within classic ASP to obtain the username (ASP.NET automatically populates this before delegating the processing back to the classic ASP ISAPI). 

The code to use this from within classic ASP would look like below:

Listing 2

<html>
     <body>
         <h1>Classic ASP Page</h1>
         <h3>
             You are logged in as: 
             <u>
                 <%=Request.ServerVariables("AUTH_USER") %>
             </u>        
         </h3>
     </body>
 </html> 

Click here to download a complete sample application that implements the above solution.  By default it will use a SQL Express database to store ASP.NET 2.0's Membership and Role Management data.  Alternatively, you can create and register a SQL 2000 or SQL 2005 database to store the membership and role management values.  This older ASP.NET Security tutorial I did shows how to-do this.