In many ways, this type of protection is very similar to the access control that's supplied by the network operating system like Windows NT Server. What's different, though, is that the user may not be currently 'logged in' to the network serving the page. He or she may be totally remote, may not be using an ActiveX-enabled browser, and may even be running on a Macintosh computer. Yet, we still want to be able to enforce the same access control.
It's easy enough to protect specific web pages or other files from casual access. Simply use the file manager and put an explicit access control attribute on it (assuming you're in a secured installation using the NTFS file system). This, however, will prevent all users from accessing the protected pages, including the users who you have explicitly given permissions to access.
Thinking through the situation, whatever the solution may be, the web server must somehow obtain the capability to identify who the user is at the other end of the connection (sitting behind the browser) in order for it to work. This, of course, boils down to the ability for the server to authenticate a remote user accessing the web server. How would such authentication be performed, though? Even if we obtain the true identity of the user somehow, what if the network hosting the web server doesn't know about the user at all (i.e. there's no account information on the user)? In our example, consider the case where Joe Belmont of Accounting is trying to access the secured draft report (which he has access rights to) from Italy over a modem using a Unix machine at a trade show. We'll take a look at ways in which this authentication can be done today in the next section. This will give us an insight into the security problems faced by the IIS and ISAPI applications.