Securing a Web Application with Forms Authentication

For varying kinds of risk you need varying kinds of security. For an intranet application it may be suitable to use Windows authentication (see Chapter 13 for more information), but for Internet applications you may want to use a more aggressive approach. For example, you may elect to have users log in using forms authentication and further restrict access based on assigned roles for those users. The first step is to authenticate the user . I will demonstrate forms authentication here. (For a good example of forms authentication and roles-based security, refer to the IBuySpy portal code available for download from Microsoft at http://www.asp.net.com.)

Forms authentication is just what it sounds like. You are going to provide a login form for the user to enter a user name and password; authenticate that user, and allow access if the person provides valid credentials. There are a few pieces to this puzzle. The first two occur in the Web.config file. We need to modify the Web.config file for the application that requires authentication; specifically we need to modify the <authentication> and <authorization> tags. Additionally, we will need to provide some sort of login form. Finally, we need to set an authorization cookie if the user is authenticated. Listing 15.31 shows the Web.config modifications.

Listing 15.31 Modifying the Web.config File for Forms Authentication

 <authentication mode="Forms">   <forms name=".ASPXAUTH"     loginUrl="Login.aspx"     protection="All">     timeout="20"   </forms> </authentication> <authorization>   <deny users="?" /> </authorization> 

The authentication mode is set to Forms . (The default is Windows integrated.) When we change authentication to Forms we need to include a nested <forms> tag, which specifies the cookie name, a login URL , a protection attribute that describes how the cookie is stored, and an expiration attribute, timeout . In Listing 15.31 we have indicated that the user should be redirected to a page named Login.aspx for authentication. The protection value All means that the authentication cookie is validated and encrypted, and the authentication cookie will expire after 20 minutes.

The authorization section is very simply set to deny all unauthenticated users. (The wildcard ? means unauthenticated users.) With these settings all users will be redirected to the Login.aspx page for authentication. (The Login.aspx page is included in CachingDemo.sln .)

As mentioned above, if the user is authenticated, we need to set an authorization cookie. Listing 15.32 shows some very basic code for that.

Listing 15.32 Setting an Authentication Cookie for Authorized Users

 Private Sub Button1_Click(ByVal sender As System.Object, _   ByVal e As System.EventArgs) Handles Button1.Click   ' Authenticate here!   FormsAuthentication.SetAuthCookie(TextBox1.Text, True)   Response.Redirect(Request.ApplicationPath + "/WebForm1.aspx") End Sub 

The Button1_Click code is from the Login.aspx page. The code simply authenticates everyone. In a production application you would read the user name and password from some repository. If the supplied user name and password were valid, you would call FormsAuthentication.SetAuthCookie and redirect the user to the requested path .

In the listing the second argument to SetAuthCookie indicates that the authorization cookie is persisted , which means the user will still be authenticated after the browser closes and until the cookie expires . Pass False if you want the cookie to reside in-memory and expire when the user closes the browser. Finally, in the Redirect statement I had to add the name of the page because I didn't use one of the default pages for my instance of IIS. Had the page been named default.aspx , I could return the user to the originally requested page with Response.Redirect(Request.ApplicationPath) .

This section covers basic forms authentication. To go beyond that, you will need to create an instance of a class that implements IPrincipal , add a string list of roles, and assign this principal object to the Context.User property. The string roles can be used to verify the roles of an authenticated user.

There are many levels of security. Necessity will dictate how much more exploration you will need to apply to your specific application. For more on another kind of security, code access security, refer to Chapter 18. For everything you ever wanted to know about .NET security, pick up a copy of .NET Framework Security by Brian LaMacchia et al. [2002].