Using the System.Web.Security Namespace

The System.Web.Security namespace is the one that you’ll use for the majority of your Web security needs—no matter what type of application you want to create. For example, this namespace contains the PassportIdentity class demonstrated in Listing 11.5. Some of the classes provide general functionality that you could use in both wireless and desktop application. When you want to use the classes in a general way, you need to implement the functionality on the server, rather than on the client. The following sections describe these three classes of interest.

Tip

Web security takes a number of forms. While the classes in the System.Web.Security namespace can help you keep your data safe locally (to a large extent) and remotely (to a lesser extent), most applications will still require additional security measures such as the WS-Security standard (http://www-106.ibm.com/developerworks/webservices/library/ws-secure/). You can read about a number of products on the market today to help developers make the most of the potential of WS-Security in the InfoWorld article at http://www.infoworld.com/article/03/04/15/15appnews_1.html.

Defining File Security Using the FileAuthorizationModule Class

The FileAuthorizationModule class doesn’t look like very much from the description in the help files. However, this class is exceptionally important because it’s one of the few distinct links between Windows security and the security employed by the .NET Framework. Whenever a caller requests a resource such as a file, the FileAuthorizationModule class authenticates the caller against the Windows Access Control List (ACL). This isn’t the role-based or code access security that a .NET application normally relies on to authenticate a caller.

The tie-in with older Windows technology is important. For example, without this link, ASP.NET impersonation (the use of a default account in place of the standard user account to access a resource) wouldn’t work. This class also provides a way for you to restrict access to certain resources such as a file to specific callers using standard security measures. This means that someone who accesses the site using a PDA will have the same rights to that file as if they were accessing it from their desktop—a good feature when used to deny or grant access to a resource based on credentials, rather than other factors.

An alternative to using the FileAuthorizationModule class is to rely on the Url AuthorizationModule class. Although this option might seem more in line with the .NET way of working with security, you must manually enter the information used for authorizations purposes in the Web.CONFIG file. Here’s an example of an authorization entry:

<authorization>     <allow users="John"/>     <allow roles="Administrators"/>     <deny users="Guest"/>     <deny roles="Guests"/> </authorization>

In this case, the user named John and anyone in the Administrators role would gain access to the resource, but CLR would deny the user named Guest and anyone in the Guests role access. The problem with this technique is that it doesn’t necessarily work well with all callers (including wireless devices where the username or role is ambiguous at times) and it keeps the authorization information in plain text form on the Web server. In short, using the FileAuthorizationModule class method is the more secure choice in this case. CLR uses the FileAuthorizationModule class automatically when you fail to include an <authorization> section in the Web.CONFIG file. You can learn more about the various roles of these two classes in security in Microsoft Knowledge Base article 306590 at http://support.microsoft.com/default.aspx?scid=kb;[LN];306590. Note that using the FileAuthorizationModule class can result in errors due to a bug in the .NET Framework implementation. See Knowledge Base article 317955 at http://support.microsoft.com/default.aspx?scid=kb;[LN];317955 for details.

Defining Form Security Using the FormsAuthentication Class

The FormsAuthentication class can help you overcome some of the issues with authenticating clients who can’t use the more secure Windows login. For one thing, it helps you create an environment in which ASP.NET authenticates the caller, but it doesn’t matter quite as much who the caller is, where the caller is located, or what device the caller is using. This form of authentication relies on special server configuration, application configuration, and a few programming tricks. Listing 13.5 shows the first part of this application. (You can find this example in the \Chapter 13\C#\FormAuth or \Chapter 13\VB\FormAuth folder of the source code located on the Sybex Web site.)

Listing 13.5 Defining the Login Page

private void btnLogin_Click(object sender, System.EventArgs e) {    HttpCookie  AuthCookie; // Authorization cookie.    // Initialize forms authentication.    FormsAuthentication.Initialize();    // Verify the user has proper access.    if (!FormsAuthentication.Authenticate(txtName.Text,                                          txtPassword.Text))       throw new SecurityException(txtName.Text +                                   " is not authorized!");    // If the user is authenticated, generate a cookie.    AuthCookie = FormsAuthentication.GetAuthCookie(txtName.Text, true);    // Place the cookie in the response.    Response.Cookies.Add(AuthCookie);    // Redirect to the default page.    Response.Redirect("Default.ASPX"); }

The code begins by initializing the FormsAuthentication object using the Initialize() method. Always initialize the authentication environment; otherwise, you could get some strange results. The code calls on the FormsAuthentication.Authenticate() method next to authenticate the user against the data stored in the Web.CONFIG file. This method of authentication doesn’t rely on the standard Windows names and passwords—a caller must appear in a separate credential database to access the page.

At this point, ASP.NET has authenticated the user or the application has generated a SecurityException and the caller hasn’t gained access to anything. The code stores the authentication information in a cookie and redirects the caller to the target page.

You can’t ask for forms authentication and not provide any data to support it. The Web.CONFIG file requires additional entries to make this type of authentication work. Listing 13.6 shows the changes you’ll need to make.

Listing 13.6 Modifying the Web.CONFIG File

<!-- Use the Login.ASPX form for authentication. --> <authentication mode="Forms">   <forms loginUrl="Login.ASPX" requireSSL="true">      <!-- Create a list of credentials. -->      <credentials passwordFormat="SHA1">         <user name="John"               password="AAF4C61DDCC5E8A2DABEDE0F3B482CD9AEA9434D" />      </credentials>   </forms> </authentication> <!-- Deny access to users who aren’t authenticated. --> <authorization>     <deny users="?" /> </authorization>

You need to pay careful attention to several features of this configuration file. First, notice the requireSSL=”true” attribute. It’s extremely dangerous not to include this entry because the user’s name and password appear in plain text otherwise. You should also set the server to use SSL by changing the Secure Communications entry on the Directory Security tab of the application Properties dialog in the Internet Information Services console. (You could also change just the entry for the particular file, but securing the entire application is better.)

Second, notice the passwordFormat=”SHA1” attribute. All of the passwords in the credentials list are hashed using the SHA1 encryption standard. Listing 13.7 shows one technique you can use to obtain the required information. Because the cracker could access the configuration file, you want to keep all sensitive data encrypted.

Third, notice the <authorization> element now contains a <deny> child. This entry specifically denies access to any unauthenticated callers.

Once ASP.NET authenticates the user, the application redirects them to the Default.ASPX page. In this case, the page shows several of the other FormsAuthentication object features. Listing 13.7 shows the code for this portion of the example.

Listing 13.7 Generating Forms Authentication Statistics

private void Page_Load(object sender, System.EventArgs e) {    // Get the information for the current user and display it.    lblOutput.Text = "Forms Cookie Name: " +       FormsAuthentication.FormsCookieName +       "<BR/>Forms Cookie Path: " +       FormsAuthentication.FormsCookiePath +       "<BR/>Is SSL Required? " +       FormsAuthentication.RequireSSL;    // Hash a password for storage in the configuration file.    lblHashPwd.Text = "Hashed Password for hello:<BR/>" +       FormsAuthentication.HashPasswordForStoringInConfigFile(          "hello", "SHA1");    // Sign out.    FormsAuthentication.SignOut(); }

The code begins by listing a few statistics for the page. Notice that you can determine the SSL status of the page before you do anything. Always check the FormsAuthentication.RequireSSL property to ensure that the application uses SSL. The code uses the FormsAuthentication .HashPasswordForStoringInConfigFile() method to generate a hash for the password for user John using the SHA1 standard. Finally, the application logs off using the FormsAuthentication .SignOut() method.