Overview:

The AccessControl tool that provides a simple way to add simple access control to an W2K server.  The intended usage is to provide some small number of folders which access is to be controlled.   Each such URL folder is called a "restricted path".   By default,  IIS clients do not have access to any restricted URL paths.  

To grant a client access to a restricted path, the local server ASP scripts simple use the Object.Grant().  Once granted access the client can use any URL that is part of the restricted path for which it has been granted access.   The security of when to grant a client access is not part of the AccessControl tool.  That determination is done by the server's ASP scripts.  The demo scripts (available for download) uses an ASP script that has a hard-coded username & password check; however, the script could just as easily use an ADODB object to check a database or a test file, or even use some other means then a username and password to determine when to grant the session access.

The AccessControl tool comes in two parts.  The first is an ISAPI filter, AccessFilter.dll, which monitors the client requests to see if they overlap with a restricted path and if so check the sessions access to the path.  

The second is a COM object, AccessControl.dll, that provides programmatic access to the methods needed to control access.

It should be noted that the implementation of the access control tool assumes that there are a limited number of restricted paths (I.e., remember everything under the path is restricted).  It is not intended for a access control system where access is to be individually controlled on hundreds of individual files or locations.  While this doesn't fit everyone's needs, this is the usage I needed.  I can use this tool to easily control access to large portions of my web site where the ASP script controls any write-accesses and the AccessControl tool stops unwarranted read accesses from the entire tree. 

When access to a restricted path is attempted and not granted, the ISAPI filter redirects the request to a NoAccess URL and appends the original URL onto the address as a query string.  The NoAccess URL is configured as part of the restricted path.

Installation:

1. Make a directory and copy the "AccessControl.dll" and "AccessFilter.dll" file into it.

2. Install the ISAPI filter on any web site that you want to control access to.   This is done by

• By starting the "Internet Service Manager" mmc from the Administrative Tools.
• Then under the "properties" dialog for each web site goto the "ISAPI Filters" tab.
• Here you can add the AccessFilter.dll to the servers.

Note that under properties for the server you can select Edit for the "WWW Service" and find the ISAPI filters for the entire server.  You can install the filter here if you prefer instead of on each site.

3. Install the AccessControl.dll by running "regsrv32 AccessControl.dll"

4.  Install the AccessAdmin.asp page on your server to configure the restricted path settings.

AccessControl

There are two object types that can be created from the AccessControl COM module.  The first is the AccessControl.SessAcc object which is used to track the session and to grant or revoke access to the restricted paths on the server for the session. One such object needs to be allocate for each session and stored in a session variable.  This causes the object to stay around until IIS closes the session (or until the ASP scripts free it).  In addition, the ID property of the object needs to be stored in a memory-only style cookie called SessAcc.  This last step allows the ISAPI filter to identify the session making the URL requests.

The controls for a SessAcc object are:

The next AccessControl object type is the AccessControl.Paths object which is used to administrator the servers restricted path settings.  The AccessAdmin.asp page included with the binaries provides easy access to the maintenance functions. 

The controls for a Path object are:

The follow are used to enumerate the restricted paths:

SessionObject.ID

This property is the ID of the session object assigned by the Access Control tool.  The ID is a string of random characters.  To use the AccessControl tool the ASP script needs to allocate a session object for the session, and assign this ID into the memory-only SessAcc cookie.  The ISAPI filter uses the cookie value to determine the Access Control ID of the session.

Example:

The proper way to allocate the Session object and store the ID is shown below:

//
// If we don't already have an access control
// session object allocate one now.
//

if (!Session("SessAcc")) {
    var Sess;
    Sess = Server.CreateObject("AccessControl.SessAcc");
    Session("SessAcc") = Sess;
    Response.Cookies("SessAcc") = Sess.ID;
}

Note that the allocated object is stored into an ASP Session variable.  This causes the object to persist until ASP closes the session.  The default cookie attributes are for the client to maintain the cookie only for the duration of the session.  Using a cookie to store the session ID has some issues but this is basically the same way the IIS server itself identifies each session for its usage so we are not adding any issues that ASP code doesn't already have.

SessionObject.Grant()

This function grants the current session object access to the restricted path.

Syntax:
Object.Grant( Server, URL, Subpaths )

Parameters:

Remarks:

Calling Grant() with Subpaths=true gives the session access to any restricted path that is in the area specified. If Subpaths=false then Server and URL must exactly match the registered restricted path.

Example:

// Grant access to any restricted path where the
// URL starts with "/photos" and the Server name starts
// with "www.reneris" 
Session("SessAcc").Grant("www.reneris", "/photos", true);

SessionObject.Revoke()

This function operates just like Grant() expect that it revokes access on the specified restricted paths.

Syntax:
Object.Revoke( Server, URL, Subpaths )

Parameters:

Remarks:

Calling Revoke() with Subpaths=true revokes the session access to any restricted path that is in the area specified. If Subpaths=false then Server and URL must exactly match the registered restricted path.

Example:

// Revokes access to any restricted path where the
// URL starts with "/tools" and the Server name starts
// with "www.reneris" 
Session("SessAcc").Revoke("www.reneris", "/tools", true);

// Revokes access to all restricted path where the
// Server name starts with "www.reneris" 
Session("SessAcc").Revoke("www.reneris", "/", true);

PathObect.Add()

This functions adds a new restricted path to the server.

Syntax:
Object.Add( Server, URL, NoAccess )

Parameters:

Remarks:

Calling Add() adds a new restricted path.  The Server and URL supply the path that is to be restricted.  The Server is the first part of the URL  and the URL is the virtual path on that server.  For example the follow address of:

    http://www.sitename.com/dir1/dir2/file 
yields:
    Server: "www.sitename.com"
    URL: "/dir1/dir2/file"

And access where the Server name of the access starts with the Server name of the restricted path and the URL or the access starts with the URL of the restricted path is subject to access control.   If requested URL is not accessible to the current session, the session is redirected to the NoAccess page and the original URL is pass as a query variable "url" to the NoAccess page.

Note that restricted paths are persistent.  The access control tool keeps track of all such paths in the "rpath.txt" file and reads this file at initialization time.

Example:

// Adds a restricted path for and request where the server
// name starts with "www.reneris" and the URL starts with
// "/tools/demo/".  Any non-granted sessions will be 
// redirected to the "/tools/logon.asp" page

Path = Server.CreateObject("AccessControl.Paths");
Path.Add("www.reneris", "/tools/demo/", "/tools/logon.asp");

The above example will catch access to anything starting with /tools/demo/ when the server name starts with www.reneris.  As the server response to www.reneris.com and www.reneris.net both paths are protected with one restricted path entry.

PathObect.Remove()

This functions removes a restricted path from the server.

Syntax:
Object.Add( Server, URL )

Parameters:

Remarks:

Calling Remove() removes a restricted path. The path being removed must match exactly to one that is current in effect. 

PathObect enumeration

The functions Start() and Next() along with the EOF, Server, URL, NoAccess provide the means to enumerate the restricted paths on the system.

Syntax:
Object.Start( )
Object.Next( )
Object.EOF
Object.Server
Object.URL
Object.NoAccess

Remarks:

Calling Start() will set the position to the first restricted path.  Calling Next() will advance to the next restricted path.  EOF is true when there are no more restricted paths. 

Example:

// Display the restricted paths
for (Path.Start(); !Path.EOF; Path.Next()) {
    Response.Write("Server: " + Path.Server + " ");
    Response.Write("URL: " + Path.URL + " ");
    Response.Write("NoAccess: " + Path.NoAccess + "<br>");
}

PageObject.BasePath

The base path is a local path name to the directory that the AccessFilter.dll is located.  (I use this in my ASP code to find a text file that contains user id's, etc..)