ASP.NET —

Web-Based Security

Software security is a prevalent topic these days, especially with ever increasing public awareness of security issues such as privacy. When a Web application runs on the Microsoft platform, several security issues arise immediately. They include (1) IIS's security context, (2) being sure your clients are who they say they are, and (3) specifying what those clients may and may not do with your application.

Managing Web-based security is similar to managing normal network security in that you still need to manage the authentication and authorization of users. However, Web-based security involves managing clients running different platforms in an open system. That is, you may not have any idea who your site clients are.

While not quite a trivial problem, Windows security is at least a solved problem. Anyone's who's configured a Windows network knows there are myriad issues involved in getting all the users of a network set up appropriately. But a Windows network is a closed system, and everyone on the network is connected and has a baseline level of trust between them (that is, they're all on the network). When you log on to a Windows network, you prove who you are (you authenticate) by providing your user name and password. If the security subsystem believes you are who you say you are, it issues a security token to your Windows session, and every application you start runs with that security token.

The resources (files, folders, drives, applications, etc.) on your computer and on your network are associated with Discretionary Access Control Lists (DACLs). If the security context under which your application runs belongs to a resource's DACL, then you may use it. Otherwise, the system will prevent you from using the resource. This is known as authorization.

In a closed system such as a Windows network, an administrator can effectively survey the whole system and assign users access to various resources. Because it's a closed system, the system can determine very easily whether or not a user belongs in the system and what that user may do.

Contrast this with a Web application. When considering a Web application, you realize first that the range of users of your application is quite wide. They are not necessarily part of your network. That means you need another way (outside of the Windows infrastructure) of authenticating and authorizing the users of your Web application.

Securing IIS

The first security issue you encounter in programming Web applications on the Windows platform is understanding the security context for IIS. Virtually all access to your Web site will be directed through IIS. As with all Windows applications, IIS runs under a specific context. When you install IIS on your machine, the install process creates a separate security identity specifically for IIS.

You can see the identity under which your version of IIS runs by starting the IIS control panel, selecting a virtual directory, right-clicking to get the properties, and then selecting the directory security tab. On my computer, the name of the user is IUSR_D6XXH351, as you can see in Figure 10-1.

Figure 10-1 Managing IIS's authentication settings.
Figure 10-1 Managing IIS's authentication settings.

Notice the top left corner of the dialog box includes a check box labeled Anonymous access. When this box is checked, IIS uses the principle identified in the User name field as its security principle. That is, IIS runs with access to the resources as being available for IUSR_D6XXH351.

If you turn off the Anonymous access check box, you may apply Windows authentication to your Web application. In this case, you'd need to give all the potential clients a Windows user name and password. This only works when the clients are running on Windows-based platforms. Users logging on to your site are challenged (meaning they'll be asked to authenticate themselves). They'll see a Windows login dialog box when they log on to your Web site (perhaps you've run into this type of site before). This method of authentication does work well if you're writing an enterprise-wide site and you can count on your audience running Windows-based browsers. However, for a Web site with a wider audience, you'll want to use other means of authentication.

Fortunately, ASP.NET includes Forms Authentication, a straightforward means of authenticating clients. The Forms Authentication subsystem in ASP.NET 1.0 and 1.1 was a huge improvement from having to write your own authentication subsystem. ASP.NET 2.0 includes and improves upon the Forms Authentication model by adding an Authorization subsystem as well.

Let's start by taking a look at Forms Authentication in the raw.