In ASP.NET security lingo, two key terms are authentication and authorization. Authentication mechanisms help ASP.NET figure out who you are. Once that is determined, authorization mechanisms figure out whether you're allowed to access the pages you're requesting.
Two of the three types of ASP.NET authentication rely on technology outside of your Web application:
- Windows authentication integrates with the operating system (Windows NT/2000/XP) authentication mechanisms.
- Passport authentication requires interactions with a Microsoft Passport server.
But you can define the third authentication mechanism, forms authentication, completely within the confines of your own ASP.NET application. We’ll focus on that type of authentication here.
One of the advantages of forms authentication is its simplicity. You can have a rudimentary authentication system up and running very quickly. At its simplest, forms authentication requires you to follow these steps:
- Edit Web.config <authentication> and <authorization> elements.
- Create a standard ASPX page that someone will try to visit.
- Create a login page with username and password text boxes, and a button to submit the form.
- Handle the button’s Click event and call the forms authentication’s Authenticate and RedirectFromLoginPage methods.
The <authentication> element of Web.config lets you tell ASP.NET that you want to use forms authentication. It has a child element, <forms>, that allows you to specify the login page. Within the <forms> element, you can optionally add a <credentials> element that directly assigns usernames and passwords, as in Listing A. It’s important to note that I’m explaining the simplest use of forms authentication, which means I’m willing to store the user credentials directly inside Web.config. This is not a good idea for large Web sites. More on that later.
For the user authentication to be useful in your application, you must explicitly deny access to anonymous users. This is where the <authorization> element comes in. Use a <deny> subelement with the users attribute set to “?,” as shown in Listing A.
Now whenever someone attempts to access an ASPX page in the application that is governed by this Web.config file, ASP.NET will ensure that the user has been authenticated. Unauthenticated users will be sent automatically to the login page specified in the <forms> element.
A standard page
To test whether your authentication settings are actually doing anything, you should create at least one ASPX page besides the login page. The sample in Listing B creates a page that simply shows the authenticated user’s username. This is nice proof that authentication actually worked. When you’re ready to test, you will try to access this page directly in your browser. If your authentication system is working, you’ll be redirected to the login page you create below.
The simplest login page has a username text box, a password text box, and a button, as the markup in Listing C shows. You must handle the button’s Click event in code to call the methods that perform authentication and redirect the user (if authenticated) back to the originally requested page.
Listing D shows the Click event handler in the codebehind class for the ASPX page in Listing C. It uses the System.Web.Security namespace’s FormsAuthentication class. The first method call, Authenticate, passes the username and password. .NET compares these to the credentials that were put directly into the <forms> element inside the Web.config file. If the username and password are valid, the RedirectFromLoginPage method is called. The nice thing here is that you don’t need to tell ASP.NET what the originally requested page was—it knows where to go when you tell it to redirect.
The parameters for the RedirectFromLoginPage method are the user’s name and a Boolean value indicating whether the authentication cookie is persistent or not. A persistent cookie will survive browser sessions until the user is specifically signed out (the SignOut method of the FormsAuthentication class).
After compiling all of this, if you try to use a browser to access the standard page, you will be redirected to the login page. As long as you do not authenticate properly, you will continue to sit at that login page. When you provide the correct credentials, you will be taken to the page you requested.
As I mentioned, you won’t want to store usernames and passwords directly in the Web.config file for long. For one thing, you can’t dynamically accept new user information, such as from a sign-up form, since you can’t really use runtime code to append the new usernames and passwords to the <credentials> list inside Web.config. Also, whenever you manually change Web.config, your application restarts, which can cause all sorts of interesting anomalies for your current visitors.
So you'll want to use a separate file or database for your usernames and passwords. Once you do that, you can’t use the FormsAuthentication.Authenticate method anymore, because it looks directly to Web.config for the credentials. Instead, your database or file access code will be responsible for checking the username and password. If you find a match, you can then use the RedirectFromLoginPage method.
You might also want to think about encrypting the passwords in case someone manages to gain access to your user and password lists. The FormsAuthentication class’s HashPasswordForStoringInConfigFile can help you do this. Though its name suggests that you should use it only if you are putting credentials directly in the Web.config file, this is not really the case. It simply returns the hashed string, which can be used anywhere you like.
Finally, it’s important to note that hashing the password does not mean anything at all when it comes to “over-the-wire” security. Unless your users access your site via SSL, their passwords will be passed from browser to Web server in clear text. The password encryption described earlier is performed after the password is received from the user.
Simple and secure in a hurry
Using forms authentication, you can have a simple and secure Web application within minutes. You don’t have to place any code in your application’s ASPX files to try to determine whether the visiting user has already been authenticated. If you have forms authentication turned on in the Web.config file, ASP.NET simply won’t let the unauthenticated visitor see any of your ASPX pages. If you spent a lot of time in classic ASP developing your own authentication code, you’ll know what a big improvement this is.