Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Build Your Own ASP.NET 2.0 Web Site Using CSharp And VB (2006) [eng].pdf
Скачиваний:
74
Добавлен:
16.08.2013
Размер:
15.69 Mб
Скачать

Chapter 13: Security and User Authentication

Figure 13.12. Creating the admin account

Click the Security tab to return to the main Security window. Now click the Create user link and add a user named admin, whose password is Dorknozzle!. Check the checkbox to assign this user the Administrators role, and complete the other fields shown in Figure 13.12, which are not optional.

Previously, the settings you specified using the ASP.NET Web Site Administration Tool always affected the Web.config file. Not this time, though! In accordance with the connection string in Web.config, roles and users are stored directly in the membership data structures that we added to the Dorknozzle database.

Changing Password Strength Requirements

By default, you won’t be allowed to enter passwords that aren’t considered sufficiently secure. The default security requirements for

AspNetSqlMembershipProvider, as defined in machine.config, require the

556

Changing Password Strength Requirements

password to be at least seven characters long, and to include at least one non-al- phanumeric character (which is why the exclamation mark was included in the example above). Also, passwords are stored in a hashed format by default.

To change the password strength requirements, we must override the default settings for the AspNetSqlMembershipProvider by adding a <membership> tag to the Web.config file. As you might expect, we must first remove the default settings inherited from machine.config, then define our own settings. Here’s an example:

<configuration

xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

<system.web>

<membership>

<providers>

<remove name="AspNetSqlMembershipProvider" /> <add name="AspNetSqlMembershipProvider"

type="System.Web.Security.SqlMembershipProvider"

connectionStringName="LocalSqlServer"

enablePasswordRetrieval="false"

enablePasswordReset="true"

requiresQuestionAndAnswer="false"

applicationName="/"

requiresUniqueEmail="false"

passwordFormat="Hashed"

maxInvalidPasswordAttempts="10"

minRequiredPasswordLength="7"

minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" />

</providers>

</membership>

</system.web>

</configuration>

The settings in the example above are self-explanatory. For example, we’ve increased the maxInvalidPasswordAttempts from the default of 5 to 10, to help many users avoid being locked out of their accounts if they repeatedly enter an incorrect password. We’ve also removed the constraint that required us to have at least one alphanumeric character in the password, and the function that facilitated lost password retrieval by means of a secret question and answer.

557

Chapter 13: Security and User Authentication

What Does your Project Need?

Don’t take these security settings as recommendations for your own projects. These kinds of decisions need to be taken seriously, and the choices you make should relate directly to the specific needs of your project.

Using Regular Expressions

Advanced programmers can make use of an additional setting, passwordStrengthRegularExpression, which can be used to describe complex rules that ensure password strength.

After you make this change in Web.config, start the ASP.NET Web Site Configuration Tool again and add another user named cristian with the password cristian; assign this user the Users role.6As Figure 13.13 illustrates, the fields for specifying a security question and answer no longer appear in the form.

Figure 13.13. Creating a user

6 Feel free to use another username and password that match the new password strength require- ments—the purpose of this exercise is to see for yourself that the new settings are in place.

558

Securing your Web Application

Securing your Web Application

Now we have two roles, and two users (admin and cristian), but we still need to secure the application. You should have restricted access earlier in this chapter by modifying Web.config like this:

File: Web.config (excerpt)

<authorization> <deny users="?" />

</authorization>

If you haven’t already done so, you can add this code now, or use Visual Web Developer to add it for you. Open the ASP.NET Web Site Administration Tool, click the Security tab, and click Create access rules. Create a new access rule for the Dorknozzle directory, as shown in Figure 13.14, to Deny all Anonymous users.

Figure 13.14. No anonymous users in Dorknozzle

559

Chapter 13: Security and User Authentication

Check the options indicated in Figure 13.14 and click OK. If you look at your updated Web.config file, you’ll see the new authorization element that denies anonymous access.

Creating Access Rules Using the Administration Tool

Note that, while useful, this tool can be misleading. When you add a new access rule using the ASP.NET Web Site Administration Tool, the new rule is added to Web.config—even if it existed before! If you used the tool multiple times in the previous example, you could end up with repetitions like this:

<authorization> <deny users="?" /> <deny users="?" /> <deny users="?" />

</authorization>

Also, keep in mind that the new rules you add using the tool are appended to the bottom of the list. This is important because these rules are applied in sequence! For example, adding a new rule that allows anonymous users doesn’t change the line created previously. Instead, it creates a new entry:

<authorization> <deny users="?" />

<allow users="?" />

</authorization>

As these rules are processed in sequence, all anonymous users would be rejected even after we added the new rule. The tool isn’t smart enough to detect such logical contradictions, so you must be careful with your rule-setting.

Before moving on, make sure your authorization element looks like this:

File: Web.config (excerpt)

<authorization> <deny users="?" />

</authorization>

At this point, no unauthenticated users can access your application. Since this is an intranet application that is supposed to be accessed only by Dorknozzle’s employees, this security requirement makes sense.

However, we’d like to impose more severe security restrictions to the AdminTools.aspx file, which is supposed to be accessed only by administrators. Unfortunately, the ASP.NET Web Site Application Configuration tool can’t help you

560