Key concepts in this chapter are:
Adding a secure section to a Web site
Using Forms authentication
Using Windows authentication
Using Passport authentication
Perhaps you write your Web applications in a darkened room mumbling quietly to yourself, with the shades drawn and the door locked. Furthermore, you undoubtedly have a policy of "no one comes in, no one goes out." It goes without saying that your computer is disconnected from the Internet, has no Ethernet connection or floppy disk drive, and is used by no one else—not even your mother. Does this sound like you? If so, you probably have no need for ASP.NET authentication and can safely skip to the next chapter. Everyone else should read on.
If you’re still reading, you probably have a real-world Web application either deployed on the Internet or a company intranet. The same security challenges apply to both Internet and intranet Web applications. In both cases, you never know who will try to use your application and what their intentions are—for example, some might use your application for legitimate purposes whereas others might try to break into it to get to sensitive data, to hijack your machine, or simply for kicks. Web applications differ from Windows applications in that anyone with a browser who knows the right URL can access your application. This chapter looks at ways to keep such intruders out.
In ASP.NET applications, you can specify that all or part of a site is secured, and that it is accessible only to authenticated users. In this case, authentication is automatic88—if the user hasn’t yet been authenticated, then as soon as they try navigating to a secured page, ASP.NET will force them to log on. Each Web application can choose one of the four types of ASP.NET authentication. Table 4-1 defines the four types.
Table 4-1. Authentication Types for ASP.NET Applications
None | No authentication. All resources in the Web site are available to the anonymous user. This is the default.[a] |
Forms | Forms-based authentication. The first time the user tries to navigate to a secured page, she is redirected to a logon page you have provided. Form redirection works even if users know the URL of the secure page—unless your logon page has granted access, they cannot access secured areas. We’ll tell you more about Forms authentication shortly. |
Windows | Windows integrated security. The first time the user navigates to a secure page, ASP.NET checks the user account used to log in to Windows. This option is very easy to implement and makes the authentication process invisible to the user. It’s a great option for intranet Web applications, but it’s usually not practical for public Web sites. |
Passport | Microsoft .NET Passport security. The first time the user navigates to a secure page, ASP.NET redirects him to the Microsoft .NET Passport login site. The user will use his .NET Passport to log in to your system. This is a good option for public Web sites because your users are spared from creating yet another username and password. It also moves the task of managing usernames and passwords from your site to Microsoft .NET Passport (http://www.passport.net/). However, of the four types of authentication, this takes the most effort to implement. |
[a] The default is actually Windows authentication with anonymous authorization. The net result of this combination is no authentication. | |
After your site has authenticated that the user is who he says he is, it can also restrict areas of the site to selected users or roles. This type of security is called authorization, and the concept as it applies to ASP.NET applications was covered in Chapter 2. In this chapter, you’ll use Forms authentication to secure a Web site that allows users to edit and view information in the EmployeeData.mdb database, and you’ll also learn how to use Windows and Passport authentication. For simplicity, all examples in this chapter assume the Web server is also your development machine, which is also the machine you are using to test the applications. Also for simplicity, the examples in this chapter assume you are using Microsoft Internet Explorer 5.5 or later on Microsoft Windows XP. (All these authentication techniques are also available to Netscape products—except Windows authentication, which requires Internet Explorer.)
The Forms authentication exercise in this chapter secures a Web application named EmployeeManagementWeb. This application allows the user to view and edit her personal profile information. Like many real-world Web applications, it has a public section available to everyone and a secured section available only to authenticated and authorized users. The practice files are a fully functioning ASP.NET application; however, there is no security yet—the secured section is not secure! You’ll work on securing this part of the application in the first half of this chapter. The application consists of some classes and the four ASP.NET pages described in Table 4-2.
Table 4-2. ASP.NET Pages in the EmployeeManagementWeb Application
default.aspx | The public, nonsecure welcome page from which users navigate to the myprofile.aspx page. |
myprofile.aspx | The page for viewing profile information: first name, last name, full name, and bank account information. This page is fully functional except for the Log Out button, which does nothing. |
editmyprofile.aspx | The page for updating profile information. This page is fully functional except for the Log Out button, which does nothing. |
login.aspx | The login page. This page has the design layout for a login page, but does nothing yet. This is where you will be adding authentication logic. |
The practice files are hard-coded to view and edit profile information for RKing. Along with securing the application, you’ll change the pages to view and edit information for any logged-in user.