For a Web-based application, rather than just a Web site, you'll need to be able to identify individual visitors, rather than having the IUSR account access resources on their behalf. This can be done in several ways, but ultimately comes back to linking each visitor with a valid Windows NT user account, other than the default IUSR anonymous account. This is where authentication over the Web comes into play.
Web-based User Authentication
The simplest way to limit access to a file or resource on your Web server is to use the same authentication methods as users meet when they log onto their local network. Because all anonymous access is via the special IUSR account, you can prevent IIS from being able to access any resource, such as a file, by removing the IUSR and Everyone accounts from the list of those that have access to it. The NT security manager will prevent IIS from reading the file, and IIS will send back an Access Denied error message to the browser.
Under normal circumstances, you would expect the user to simply see an Access Denied message displayed in their browser. However, modern browsers are more clever than that. When IIS sends the Access Denied message it can also include (in the HTTP headers) information about what types of authentication methods it supports. The browser can then send back a username and password, to be used instead of the default IUSR account, to access the file or resource.
Most browsers will first send back the username and password that the user logged onto the client machine with—their standard network or logon username and password. If this results in another Access Denied message, the browser will prompt them with a dialog for another username/password combination to try.
This means that assigning permission for a resource only to a specific group of users, and removing the Everyone and IUSR accounts, will force the browser to present a username/password combination that authenticates the user in NT as a member of that group (as long as one of the authentication methods are enabled—we'll look at this next).
If they are logged on to their machine and home network with a suitable username and password (i.e. one that is also in the groups that have permission for this resource), they will automatically and transparently get access—their single 'NT Integrated Security' logon will be used. If they logged onto their own local network with a different password/username combination (or, use a lone machine, and didn't log on at all) they will only be able to access the resource on this machine as an authenticated NT user when they supply an appropriate username and password.
Basic and Challenge/Response Authentication
Browsers other than Microsoft's Internet Explorer 3.0 or later transmit the username and password across the network to IIS in clear ASCII text form. This is obviously a critical disadvantage, because anyone out on the Internet monitoring the connection could read the details. This is called Basic authentication, and is usually avoided where possible.
Internet Explorer 3.0 and later also provide Challenge/Response authentication, where the client can convince the server that it knows the relevant username and password without actually transmitting it across the network—in much the same way as it does when you log on to your own LAN. Internet Explorer automatically chooses Challenge/Response over Basic authentication when talking to IIS, though will use Basic authentication if Challenge/Response is not enabled (or with other Web servers, if it is not available).
Challenge/Response authentication involves the browser proving to the server that it knows the username and password of a suitable NT account, without sending the actual password over the network. Instead it encrypts the password locally using a complex 'one way' algorithm which creates a string that cannot be unencrypted with the same algorithm. The server applies the same algorithm to the password it holds for that user, and if the results are the same the client must know the password. However, anyone obtaining the encrypted version of the password cannot deduce the original, even if they know the algorithm that created it.
You decide whether to support Basic and/or Challenge/Response authentication using the Microsoft Management Console (MMC)—in the Directory Security page of the Properties dialog for that directory. The preferred choice, if you can control which browsers will access your application, is to enable just Challenge/Response authentication. At the moment support for Challenge/Response authentication is limited to Internet Explorer 3 or higher:
Authentication In ASP And Custom Components
If you need to do more complex tasks that can be accomplished by just logging a user onto an NT account, you can take advantage of another technique. The HTTP header information that the browser sends along with each request it makes to your server can be used to get information about a logged on user.
The standard HTTP header information includes a whole list of values—such things as the client's IP address and host name, their logon string (i.e. their username) and the authentication method used to identify them, the type of browser they are using, etc. Some of the HTTP values may be blank, but you can get a lot of useful information from the ones that aren't.
The ASP ServerVariables Collection
The full set of HTTP values appears in the ASP
object's Request
collection. As an example of how we can use it, this ASP script produces a page containing the more useful ones:ServerVariables
<HTML>
<HEAD><TITLE>Reading the ServerVariables Collection</TITLE></HEAD>
<BODY>
<B>The contents of some of the ServerVariables collection are:</B><P>
<TABLE CELLPADDING=0 CELLSPACING=0>
<%
Response.Write "<TR><TD>AUTH_PASSWORD = " _
& Request.ServerVariables("AUTH_PASSWORD") & "</TD></TR>"
Response.Write "<TR><TD>AUTH_TYPE = " _
& Request.ServerVariables("AUTH_TYPE") & "</TD></TR>"
Response.Write "<TR><TD>AUTH_USER = " _
& Request.ServerVariables("AUTH_USER") & "</TD></TR>"
'... etc
%>
</TABLE>
</BODY>
</HTML>
A full list of all the
collection members is included in the IIS Help pages. Look up ServerVariables in the Index.ServerVariables
And here are the results when the client has logged on to Windows NT with an appropriate username and matching password (in other words where the Everyone and IUSR accounts had been removed from the directory's access list). Notice that because we logged in using Challenge/Response authentication, the
entry is empty:AUTH_PASSWORD
This means that we can redirect visitors, or control access to resources, using the information we obtain. In the following example, we're redirecting all connections that come in through the default port 80 to the default user areas of our site:
<%
If Request.ServerVariables("SERVER_PORT") = "80" Then
Response.Redirect "/defaultuser/welcome.htm"
End If
%>
<HTML>
<HEAD>Welcome to the Wrox Car Company Dealer Pages</HEAD>
<BODY>
... rest of page for non-default port requests ...
</BODY>
</HTML>Here, we're only including a link to the administration site if they successfully logged on to NT as user JJSmith:
<HTML>
<HEAD><TITLE>Navigation Control Using ServerVariables</TITLE></HEAD>
<BODY>
<H3>User Options:</H3>
<A HREF="">Change Display Configuration</A><BR>
<A HREF="">Change Display Colors</A><BR>
<A HREF="">Change Keyboard Configuration</A><BR>
<% If Request.ServerVariables("AUTH_USER") _
= UCase(Request.ServerVariables("SERVER_NAME")) & "\JJSmith" Then %>
<A HREF="">Administer All Users</A><BR>
<A HREF="">Administer Logon Information</A>
<% End If %>
</BODY>
</HTML>Authentication Within Custom Components
Inside a custom component we can get a reference to the ASP
object, which is the global object generated for each ASP page request. Through it, we can then get a reference to the current ScriptingContext
object. ASP will execute a method of our component named Request
and pass it the onStartPage
reference whenever a request for an ASP page is made. In Visual Basic this looks like:ScriptingContext
Dim objRequest As ScriptingContext 'to hold the ASP scripting context
Public Sub onStartPage(objContext As ScriptingContext)
Set objRequest = objContext.Request 'store reference to Request object
End Sub
Function GetUserName() 'returns the logon or username
GetUserName = objRequest.ServerVariables("REMOTE_USER")
End FunctionBear in mind that many Web users dial into the Internet via an Internet Service Provider (ISP) who allocates IP addresses on demand from their own block of addresses—hence such a user's IP address will be different each time they visit your site. It means that you can’t reliably identify users within your application from just their IP address unless you know that they have a permanent connection, or an ISP who implements non-dynamic address allocations.
For more information about using the ASP
collection check out the IIS section of the Option Pack or Windows NT5 Help pages. ServerVariables