Ensuring orderly controlled access, data integrity and user privacy in an Intranet environment requires careful analysis of the access scenarios and access patterns that a typical user of an intranet application (or Active web site) may undergo. Designed too tightly, the user may end up with an impression of a highly restrictive, and rather frustrating (i.e. repeated requests for password and user IDs) experience. Designed too loosely, the system/application may be subjected to security abuse and vicious attacks.
Before we look at how to secure IIS, ISAPI and DCOM, let's look at the state-of-the-art with respect to security in the 'normal' web page access scenario. This access pattern is fundamental to our later discussions.
Basically, we're talking about the scenario we've described in the previous section. We need to authenticate a remote user accessing a web server in order to restrict access to certain web pages. We'll look at three specific cases and see how the problem is solved. The first case will be the general case where both the browser and the server may not be a Microsoft product. The second and third cases feature a Microsoft browser and a Microsoft server, but one over the public Internet and the other over a private intranet. As we'll soon realize, even though everything looks very similar above the surface, major differences in security implementation exist under the covers.