使用更精简的代码保证 ASP.NET 应用程序的安全

直观易用的功能

按照传统做法，为新 Web 站点构建一个验证模型通常包括以下步骤：

收集受保护资源和活动的要求，并定义适当的角色和权限。

设计关系数据库表，以存储用户、角色及相关权限。

设计登录页面。

编写代码，以验证用户并收集关联的角色和权限。

添加配置，以基于角色来保护 Web 资源。

编写代码，以基于角色和权限来控制页面内容。

即使只是构建几个可重复使用的组件来封装上述某些重复性任务，您仍会感到肩上的工作负担减轻了不少。ASP.NET Whidbey 的新组件大大减少了上述步骤中的五个步骤的工作量，至少将其减少为了原来工作量的一部分。我将使用新的基于 Web 的管理向导来自动创建一组表，以处理用户、角色和权限。在同一个管理界面中，我还会就登录、成员身份和角色管理对应用程序进行配置。我将在一秒钟（或者说仅仅是在 Web 表单中拖放一个登录控件的时间）之内设计出一个登录页面，而且我根本不用编写一行用于验证用户或关联角色的代码，因为这些会自动完成。根据用户角色和登录状态的不同，呈现的菜单和页面内容也将不同，但我同样无需为此编写任何代码。

是不是有梦想成真的感觉？让我们看看这是如何实现的。

配置界面

ASP.NET Whidbey 包括一个新的基于 Web 的配置工具，它运行于特定应用程序的上下文中，这样便可以通过交互的方式来修改应用程序自身的 web.config 文件。该工具带有许多向导，其中一个可以引导您完成设置安全选项的全部步骤。使用 Visual Studio“Whidbey”完成新 Web 站点的创建后，您可以通过两种方法启动该配置工具：从“Solution Explorer”（解决方案资源浏览器）中选择“ASP.NET Configuration”（ASP.NET 配置）图标或从“Website”（站点）菜单中选择“ASP.NET Configuration”（ASP.NET 配置）。



图 1：从“Solution Explorer”（解决方案资源浏览器）或主菜单启动基于 Web 的配置实用工具。
配置 Web 界面启动时会显示一个查询字符串，指示要配置的应用程序目标。在本文中，我创建了一个名为“MySecureNewsletter”的新应用程序，并启动了管理界面，如下所示：



图 2：在我的计算机上启动管理界面的 URL 是 http://localhost:10245/ASP.NETWebAdminFiles/default.aspx?applicationPhysicalPath=H:/WebSites/MySecureNewsletter/&applicationUrl=/MySecureNewsletter。 “Security”（安全）选项卡中的一个选项是运行“Security Setup Wizard”（安全设置向导）。对于一个新应用程序，应当首先运行该向导。向导界面的左侧面板显示了将要逐步执行的步骤列表，并指出您当前所在的步骤：



图 3：安全设置向导使用 ASP.NET Whidbey 的某些其他很酷的功能，例如用于导航的向导控件。
设置过程中的步骤非常简单，所以在此仅概述我为示例应用程序所选的选项。首先，向导询问我该站点是 Intranet 站点还是 Internet 站点。前者默认使用 Windows 验证，后者（也是我的选择）将把应用程序配置为使用表单验证。下一步，向导显示创建数据库以存储用户和角色的选项。如果选择此选项，向导将询问我是选择创建 Microsoft Access 数据库还是创建 Microsoft SQL Server™ 数据库，然后引导我完成几个附加的步骤。我没有选择这个选项，所以在应用程序的 /Data 目录下将创建一个默认的 Access 数据库。在 machine.config 文件中，

<connectionString>

元素指定了 Access 数据库的默认位置：

<connectionStrings>          <add name="LocalSqlServer" connectionString="data            source=127.0.0.1;Integrated Security=SSPI" />          <add name="AccessFileName"             connectionString="~/DATA/ASPNetDB.mdb" />    </connectionStrings>

下一步，我启用了该应用程序的角色管理。此时，将创建带有大量表格的默认 Access 数据库，并且最终将由新的安全控件和成员身份 API 来使用这些表。此时，我可以选择创建角色和用户。创建每个角色时都需要使用简单的字符串值，如下所示：



图 4：界面左侧的向导面板显示我正在对应用程序的安全模型执行哪一步设置。
要创建用户，需要设想一下您可能希望为每个用户收集哪些字段，特别是用户名、密码、电子邮件、说明和可选密码问题及答案。如果已创建了任何角色，则这些角色显示为复选框选项的形式以供选择：



图 5：此处输入的电子邮件字段以后将用于与用户进行交互，例如在用户取回密码时。

通过以上几个简单的步骤，我们已在 /Data 目录下创建了一个新数据库（文件名为 AspNetDB.mdb），用于存储成员身份信息。刷新“Solution Explorer”（解决方案资源浏览器）以后，您还可以看到已创建了一个 web.config 文件，用于启用

<roleManager>

设置中的角色管理。这一步是必需的，因为 machine.config 中的默认设置是禁用角色管理。新的 web.config 文件如下所示：

<?xml version="1.0" encoding="utf-8"?><configuration>    <system.web>        <roleManager enabled="true">            <providers />        </roleManager>    </system.web></configuration>

在以上数个简短的步骤中，我创建了标准的成员身份和凭据管理数据库，角色和用户也创建完毕，并完成了角色管理必需的 Web 配置，现在我们就可以构建一个安全的应用程序了。

如果没有在第一次配置过程中完成角色和用户的创建，您可以随时返回到该配置工具输入或修改设置，但我现在将演示如何创建自己的管理页面。

拖放安全控件

到文章的本节为止，您依然不需要编写任何代码。我将演示如何使用 ASP.NET Whidbey 的新安全控件来生成一个基于角色的可行的验证系统。我将从我的示例电子通讯应用程序 MySecureNewsletter 开始。目前，除了我刚刚在向导中完成的步骤以外，尚未生成任何安全模型。顺便说一句，这个应用程序使用了 Whidbey 新的“母版页”功能。关于该功能的详细信息，请参阅 Master Pages in ASP.NET Whidbey（英文）。在“Solution Explorer”（解决方案资源浏览器）中，您将看到 /templates 目录下包含可重复使用的用户控件和母版页模板，而 /images 目录存储所有支持图形，根目录下则有一些应用程序页面。



图 6：示例应用程序中的所有 *.aspx 页面都将使用一个母版页作为布局模板。内容页面和 Web 表单页面一样，但前者指定了母板页模板，且所有的内容都放在内容控件中。

登录

添加名为 login.aspx 的新内容页面以后，我们可以开始享受些乐趣了。“Toolbox”（工具箱）带有“Security”（安全）选项卡，其中列出了 ASP.NET Whidbey 中与安全性相关的非常酷的新控件。



图 7：“ToolBox”（工具箱）已经针对 ASP.NET Whidbey 进行了重新组织，新的安全控件将集中到它们自己的选项卡上。
我将从刚刚拖放到新的 login.aspx 页面上的“Login”（登录）控件开始，一个个地浏览这些安全控件：



图 8：登录控件提供了编辑控件默认布局的交互式设计器界面。
您可以选择某一个“AutoFormat”（自动套用格式）选项来为控件外观选择一个已封装的格式：



图 9：目前有两个已封装格式可用，但如果应用程序使用了默认样式表，您还可以通过“Properties”（属性）窗口为控件的各个元素指定样式。
“Properties”（属性）窗口还提供了对控件各个元素的标记、值和验证错误消息的访问。您也可以自定义登录按钮的外观，并提供创建新成员的链接。现在，让我们看看使用可信任的样式表和控件默认选项会生成些什么。控件生成的源代码如下所示：

<asp:login id="Login1" runat="server"></asp:login>

这样，我的登录页面就完成了。因为我已经配置了应用程序的用户和角色，所以我仅需修改 web.config 文件，把验证模式设置为“Forms”（表单），因为默认方式是“Windows”验证。同时，为了测试登录进程，我还将拒绝匿名用户：

<authentication mode="Forms"/><authorization>         <deny users="?" />      </authorization>

注意：我早先曾提及安全设置向导将应用程序配置为使用表单验证，该向导是通过生成默认数据库以存储凭据来完成该配置的。该向导并不是（在 Whidbey Alpha 版本中）通过修改应用程序的 web.config 文件中的 <authentication> 设置来指定如上所示的表单验证模式。
现在，系统将引导所有的匿名用户前往登录页面（幸好使用了母版页和样式表，在花了一秒钟将登录控件拖动到表单后，这个页面看起来还过得去）：



图 10：在没有修改任何属性的情况下，这是在页面模板中显示的登录控件的默认外观。

谁已经登录了？

如果输入了有效的用户名和密码，“Log In”（登录）按钮将自动验证用户，并将其重定向到最初请求的页面。当然，登录以后，习惯上要为用户显示个性化的欢迎页面，并提供注销的途径。我将把这两个功能添加到显示在每个页面中的 menus.ascx 用户控件。“LoginName”（登录名）控件显示了已验证的用户名，而“LoginStatus”（登录状态）控件则提供了一个方便的超级链接，它会根据当前验证状态，在登录和注销操作之间切换。以下是将这两个新控件添加到 menus.ascx 文件的适当位置后的 HTML 源代码：

当前您已登录为: <asp:loginname id="LoginName1"  runat="server"></asp:loginname><asp:loginstatus id="LoginStatus1" runat="server"></asp:loginstatus>

噢，这太粗略了。现在有了登录页面，让我们看看用户登录以后显示的个性化欢迎页面，同时我们还为用户提供了注销的途径，所有这些都不需要编写代码。



图 11：在 Login（登录）/Logout（注销）之间切换
登录名控件只执行一个任务：显示已验证用户的名称。默认情况下，登录状态控件自动在 Login（登录）/Logout（注销）之间切换，但可以使用模板进一步自定义。注销的实际进程也由该控件进行封装。

关于此个性化欢迎页面的唯一问题是：在登录之前，页面会显示空白用户名，我们可能需要编写一些代码来控制这一部分。不过，也许我们同样可以不用编写代码就能做到。

控制对内容的访问

如果使用以前的 ASP.NET 版本来显示当前已验证的用户，我们需要编写代码来访问当前上下文的用户标识。要仅在用户验证后显示该信息，还需要编写更多的代码来检查用户的状态。“LoginView”（登录视图）控件可能是最有意思的新安全控件之一，它让我们能够基于验证状态和角色来控制页面内容。为了检验这一点，我向 menu.ascx 文件添加了一个登录视图控件。通过与设计环境进行交互，您可以编辑希望匿名用户（尚未登录）或已验证用户所看到的信息。



图 12：“Common LoginView Tasks”（通用登录视图任务）使您可以在视图之间切换，或通过单击“Edit Templates”（编辑模板）超级链接开始编辑模板。
您始终可以通过“Source”（源文件）视图直接修改 HTML。以下代码显示了向 menus.ascx 文件的个性化欢迎页面中添加登录视图控件时所做的修改：

<asp:loginview id="LoginView1" runat="server">    <anonymoustemplate>        您目前尚未登录。    </anonymoustemplate>    <loggedintemplate>    当前您已登录为：<asp:loginname id="LoginName1"       runat="server">                </asp:loginname>    </loggedintemplate></asp:loginview>

登录视图控件在用户尚未通过验证时显示

<anonymoustemplate>

节的内容，用户通过验证后显示

<loggedintemplate>

节的内容。所以，没有编写任何代码，我们已利用安全控件为用户提供了登录页面、注销功能、个性化欢迎页面和基于验证状态的自定义页面内容。

什么？忘记了密码？

您肯定会觉得难以置信，自动管理密码就是如此简单。“PasswordRecovery”（密码取回）控件提供了功能完善的密码取回系统，包括基于密码问题查找密码以及自动重设密码，并通过电子邮件将密码发送给用户。我在应用程序根下创建了密码取回页面，在将密码取回控件拖放到页面后，我看到了以下内容：



图 13：“Common PasswordRecovery Tasks”（通用密码取回任务）使您可以自定义该过程中的每一步骤的外观。
密码管理设计的大量活动都是可以配置的。例如，您可以要求用户创建密码问题和答案，并将其作为密码安全模型的一部分。PasswordRecovery 控件包括这样一个界面，要求用户回答他们在创建帐号时提供的密码问题。如下所示，您可以编辑密码取回的每一部分的设置，包括请求用户名、询问密码问题，以及完成该过程后显示对用户的响应。



图 14：密码问题和答案的形式可由成员身份提供程序（本文稍后将介绍）进行配置。
此控件自动重设密码，并将新密码发送到用户的电子邮件帐号。生成的电子邮件的属性可通过控件的公共属性进行配置。在示例程序中，我自定义了电子邮件的主题标题和发件人的地址。所生成的 HTML 如下所示：

<asp:passwordrecovery id="Passwordrecovery1" runat="server">        <maildefinition bodyformat="Html" subject="Password Recovery for          MySecureNewsletter" from="mailto:mailadmin@dotnetdashboard.com">        </maildefinition>    </asp:passwordrecovery>

如果正确地配置了用于发送电子邮件的 SMTP 服务器，我将接收到包含新密码的电子邮件：



图 15：通过在“Properties”（属性）窗口中设置“BodyFilename”和“BodyFormat”属性，可以提供电子邮件的 HTML 模板。
在示例中，我使用自己的 SMTP 服务器测试了该功能，而您将在 web.config 文件中看到 SMTP 设置的这个示例：

<smtpMail            serverName="smtp.mysmtpserver.com"            serverPort="25">        </smtpMail>

这是一个奇妙的功能，为处理密码管理提供了快速的安全方案。但对于大型站点，您很可能希望进一步了解组件的体系结构。例如，您希望确保生成电子邮件的组件具有可伸缩性，您还可能想编写一些代码来控制如何通过电子邮件向成员发送密码：也许是提供对显示解密密码的已过期 Web 页面的链接。

按角色过滤内容

大多数应用程序依赖角色来控制对资源的访问、信息显示方式和可允许的活动。此前，我创建过许多用户，并使用安全管理工具来为其指定角色。如果是在 ASP.NET 的以前版本中使用这些角色，我就得编写代码，以从已验证的用户的凭据存储中手动检索角色。LoginView 控件通过配置的成员身份提供程序（或者是成员身份 API）与这些角色进行交互，并支持为任何有效角色提供内容模板。

假定我将把一组仅能由管理员访问的管理页面添加到应用程序。如果向标题中一个“Admin”（管理）菜单项，我很可能希望其仅对管理员显示。为了实现这一点，我将把另一个登录视图控件添加到菜单界面。LoginView 控件的某个属性（可通过“Properties”[属性] 窗口访问）支持通过对话框界面将角色列表添加到“RoleGroups”（角色组）集合：



图 16：“RoleGroup Collection Editor”（角色组集合编辑器）要求手动输入角色。您也可以为角色编组，这样多个组可以共享同样的模板界面。
在“Design”（设计）视图中，LoginView 控件现在将角色列表显示为模板选项：



图 17：“HTML”视图将更新，显示您为每个角色所设计的所有模板。
从以下 HTML 源文件中可以看出，“Admin”（管理）和“Member”（成员）角色使用了新的内容模板。在验证以前仍将使用

<anonymoustemplate>

，但验证以后，将使用与某个用户角色匹配的第一个模板。如果未找到匹配项，默认使用

<loggedintemplate>

设置。

<asp:loginview id="lvMenu" runat="server">    <anonymoustemplate>        <asp:loginstatus id="anonLoginStatus" runat="server">        </asp:loginstatus>    </anonymoustemplate>    <rolegroups>        <asp:rolegroup roles="Admin">            <contenttemplate>    <tr>       <td class="OtherTabs">        <asp:hyperlink id="adminHome" runat="server"          navigateurl="~/default.aspx">Home</asp:hyperlink>             | </td>        <td class="OtherTabs">         <asp:hyperlink id="adminAbout" runat="server"           navigateurl="~/about.aspx">About</asp:hyperlink>              | </td>        <td class="OtherTabs">        <asp:hyperlink id="adminAdmin" runat="server"          navigateurl="~/admin/manageMembers.aspx">Admin            </asp:hyperlink> | </td>        <td class="OtherTabs">        <asp:loginstatus id="adminLoginStatus" runat="server">        </asp:loginstatus>        </td>    </tr>            </contenttemplate>        </asp:rolegroup>        <asp:rolegroup roles="Member">            <contenttemplate>    <tr>       <td class="OtherTabs">        <asp:hyperlink id="memberHome" runat="server"           navigateurl="~/default.aspx">Home</asp:hyperlink>             | </td>        <td class="OtherTabs">         <asp:hyperlink id="memberAbout" runat="server"            navigateurl="~/about.aspx">About</asp:hyperlink>              | </td>        <td class="OtherTabs">        <asp:loginstatus id="memberLoginStatus" runat="server">        </asp:loginstatus>        </td>    </tr>            </contenttemplate>        </asp:rolegroup>    </rolegroups>    <loggedintemplate>   <tr>       <td class="OtherTabs">        <asp:hyperlink id="authHome" runat="server"           navigateurl="~/default.aspx">Home</asp:hyperlink>             | </td>        <td class="OtherTabs">         <asp:hyperlink id="authAbout" runat="server"            navigateurl="~/about.aspx">About</asp:hyperlink>              | </td>        <td class="OtherTabs">        <asp:loginstatus id="authLoginStatus" runat="server">        </asp:loginstatus>        </td>    </tr>    </loggedintemplate></asp:loginview>

将按照显示的顺序分析这些模板，并将第一个匹配的角色用作该登录控件的内容。这意味着必须仔细地为角色安排适当的顺序。我的示例程序的结果是将新的“Admin”（管理）菜单项限制为只对分配了管理角色的用户显示。

我们还可以指定

<authorization>

规则拒绝或允许特定的角色，从而实现使用角色来控制对其他资源的访问。可以使用

<location>

标记在 web.config 文件的应用程序级别实现这一点，或是将 web.config 文件添加到受保护的子目录。我在示例程序的 /admin 目录下放置了以下

<authorization>

设置，只允许那些指定为管理角色的用户访问：

          <authorization>              <allow roles="Admin" />               <deny users="*" />            </authorization>

现在，可以创建一些管理页面来管理成员，并根据 ASP.NET Whidbey 提供的成员身份 API 来编写代码。

成员身份和角色提供程序

至此，我所显示的大多数内容都是基于使用新的安全控件。但是，有一些基础组件允许我们直接管理用户和角色。这些组件提供了从数据库访问层抽象而来的层。为了进行演示，我将在 /admin 目录下创建一个新的内容页面 (manageMembers.aspx)。该页面将显示电子通讯成员的列表，并提供了一个中心界面，用于添加、编辑或删除电子通讯成员。

我将“DataView”（数据视图）控件拖放到页面中，目的是使用用户列表填充此控件。Page_Load 事件包含了利用内部成员身份对象检索所有用户的代码。新的 Membership 类的方法和属性提供了对默认创建的成员身份数据库的直接访问。例如，GetAllUsers() 返回了应用程序的 MembershipUser 对象的集合。以下代码将返回的集合转换为可以绑定到 DataView 控件的格式（用于 Alpha 版本的解决方案，因为该版本中不能绑定集合）：

MembershipUserCollection members = Membership.GetAllUsers ();ArrayList arr = new ArrayList ();foreach (MembershipUser member in members){arr.Add (member);}GridView1.DataSource = arr;GridView1.DataBind ();

在该页面中，用户可以添加、编辑或从列表删除成员。删除链接需仅执行以下代码行：

Membership.Provider.DeleteUser(user);

添加和编辑成员由所创建的另一个新页面 (newMembers.aspx) 来处理。添加新成员时，该页面收集要添加到成员数据库的新成员的必需信息。就我的电子通讯而言，我将收集新成员的电子邮件地址和密码，仅此而已。但是，数据库支持一个用户名和一个电子邮件地址，所以我同时使用电子邮件地址来填充这两个字段。此外，我将收集新用户的角色选择。这意味着我必须编写代码，以动态列出应用程序中所有可用的角色。

Page_Load 事件包含用于加载可用角色的代码。我将使用“Repeater”控件来动态构建一个复选框列表（与安全配置向导中的列表类似）。

// 从 newMember.aspx

<asp:repeater runat="server" id="roleRepeater"> <itemtemplate> <asp:checkbox runat="server" id="chkRole" text='<%# Container.DataItem.ToString()%>' checked="<%# m_theUser == null ? false : Roles.IsUserInRole(m_theUser.Username, Container.DataItem.ToString())%>"/> <br/> </itemtemplate></asp:repeater>

// 从 newMember.aspx.cs

roleRepeater.DataSource = Roles.GetAllRoles ();roleRepeater.DataBind ();[/code]
所生成的输入页面如下所示：



图 18：您也可以为自己的成员管理进程添加重设密码、更改密码和密码问题及答案功能。
我必须手动设计该页面，但其中添加新用户所需的代码很少，因为可以再次使用成员身份组件：

Membership.CreateUser(email.Text, pw.Text, email.Text);

我们需要多编写几行代码，以从 Repeater 控件中提取角色选择，然后用该用户的提取结果填充角色表。同样，访问角色数据库是很容易的，这次使用的是“Roles”（角色）组件：

string[] users = {email.Text};string[] addRoles = new string[roleRepeater.Items.Count];string[] remRoles = new string[roleRepeater.Items.Count];int addIndex = 0;int remIndex = 0;foreach (RepeaterItem itm in roleRepeater.Items){CheckBox c = (CheckBox)itm.FindControl ("chkRole");string role = c.Text;if (c.Checked && ![code]Roles.IsUserInRole(users[0], role)

) addRoles[addIndex++]=role;else if (!c.Checked &&

Roles.IsUserInRole(users[0], role)

) remRoles[remIndex++]=role;}if (addIndex > 0){string [] theRoles = new string[addIndex]; Array.Copy (addRoles, 0, theRoles, 0, addIndex);

Roles.Provider.AddUsersToRoles (users, theRoles)

;}if (remIndex > 0){string [] theRoles = new string[remIndex]; Array.Copy (remRoles, 0, theRoles, 0, remIndex);

Roles.Provider.RemoveUsersFromRoles (users, theRoles)

;}[/code]
同一 newMembers.aspx 页面可以用于编辑用户，查询字符串则用于指示当前的模式。在编辑模式中，Page_Load 将使用用户信息和当前角色填充界面。同样，Membership 类提供了查找特定用户记录和更新已更改用户记录的方法。如果我使用纯文本密码，并且在成员身份提供程序配置设置中启用了密码检索，那么以下代码将更新用户的密码更改：

MembershipUser user = Membership.GetUser (email.Text);  user.ChangePassword (user.GetPassword (), this.pw.Text);

默认情况下，GetPassword() 将失败，因为对所添加的安全性安装了每个成员身份提供程序的 machine.config 设置。此外，散列密码是提供程序的默认、也是推荐的方式。因为散列密码不可检索，所以您将必须从用户界面收集用户的旧密码，以调用 ChangePassword() 函数。

但是，这个程序是可扩展的吗？

至此，我一直侧重于如何才能更轻松地实现验证和基于角色的访问控制。虽然这些已封装的功能可以满足您百分之八十的需求，您还可以非常容易地扩展该模型。

数据库创建

例如，可以直接通过安全配置向导将数据库创建过程扩展为支持 SQL Server 数据库，或是另一个自定义的 Access 数据库。如果在向导的步骤中选择创建一个新数据库，您将看到如下的示例图：



图 19：安全向导将在您所选择的本地或远程数据库中创建默认的一组成员身份管理表。
您可以在应用程序的 SQL Server 数据库中直接创建成员身份表，而不是使用无法进行任何扩展的 Access 数据库。这是我认为有进步的地方。也许您的祖母无法知道完成该步骤所需的数据库名称和凭据，但您的开发小组肯定知道。系统将封装所创建的表，以匹配成员身份和角色提供程序（这两者用于实现上述功能）的需要。但如果计划编译自己的提供程序，您可以使用其他表设计，并跳过这一步。

身份管理

您可能从我们编写的、用于构建某些管理功能的代码中发现，对凭据存储的访问由成员身份和角色提供程序进行处理。System.Web.Security 命名空间现在包括新的 SqlMembershipProvider 和 AccessMembershipProvider 组件，以管理各自对默认凭据表的数据访问需求。默认情况下，machine.config 文件的

<membership>

元素包括两个提供程序，分别用于 SQL Server 数据库和 Access 数据库。

<providers>

节可用于添加或删除提供程序，这允许您在应用程序级别删除这些默认的提供程序，并配置自己的提供程序。从以下设置中可以看到，有一些与向导创建的表结构直接相关的预定义设置，包括密码加密设置、密码重设和检索设置、密码问题及答案的要求设置，以及电子邮件字段输入内容的唯一性设置。其中的每一项都由各自的默认成员身份（或数据库）提供程序来强制执行，这使您可以使用多种方法使用已封装的表结构，而不是通过创建自己的表和提供程序。您也可以替代各个提供程序所用的连接字符串。

<membership defaultProvider="AspNetAccessProvider"   userIsOnlineTimeWindow="15" >            <providers>               <add name="AspNetSqlProvider"                    type="System.Web.Security.SqlMembershipProvider,                       System.Web, Version=1.2.3400.0, Culture=neutral,                         PublicKeyToken=b03f5f7f11d50a3a"                    connectionStringName="LocalSqlServer"                    enablePasswordRetrieval="false"                    enablePasswordReset="true"                    requiresQuestionAndAnswer="false"                    applicationName="/"                    requiresUniqueEmail="false"                    passwordFormat="Hashed"                    description="从本地 Microsoft SQL Server 数据库中存储和检索成员身份数据"                />                <add name="AspNetAccessProvider"                    type="System.Web.Security.AccessMembershipProvider,                       System.Web, Version=1.2.3400.0, Culture=neutral,                         PublicKeyToken=b03f5f7f11d50a3a"                    connectionStringName="AccessFileName"                    enablePasswordRetrieval="false"                    enablePasswordReset="true"                    requiresQuestionAndAnswer="false"                    applicationName="/"                    requiresUniqueEmail="false"                    passwordFormat="Hashed"                    description="从本地 Microsoft Access 数据库中存储和检索成员身份数据"                />            </providers>        </membership>

实际上，还有另一个成员身份提供程序组件 System.Web.Security.ADMembershipProvider。该组件对 Active Directory 存储执行上述同样的活动，但目前这只是内部功能。

<roleManager>

节中的配置设置可以控制使用何种数据存储来访问相关的角色信息。默认情况下有三种配置设置：SqlRoleProvider、AccessRoleProvider 和 WindowsTokenRoleProvider。这些组件用于处理用户所有的角色管理。同样，将为 SQL Server 数据库和 Access 数据库创建一组默认表，WindowsTokenRoleProvider 调用未托管的代码来访问为操作系统凭据存储而定义的角色。

        <roleManager                enabled="false" cacheRolesInCookie="true"                   cookieName=".ASPXROLES" cookieTimeout="30"                cookiePath="/" cookieRequireSSL="false"                   cookieSlidingExpiration="true"                cookieProtection="All"                   defaultProvider="AspNetAccessProvider" >           <providers>              <add  name="AspNetSqlProvider"                  type="System.Web.Security.SqlRoleProvider, System.Web,                    Version=1.2.3400.0, Culture=neutral,                      PublicKeyToken=b03f5f7f11d50a3a"                     connectionStringName="LocalSqlServer"                     applicationName="/"                     description="从本地 Microsoft SQL Server 数据库中存储和检索角色数据" />               <add name="WindowsToken"                    type="System.Web.Security.WindowsTokenRoleProvider,                       System.Web, Version=1.2.3400.0, Culture=neutral,                         PublicKeyToken=b03f5f7f11d50a3a"                    description="从请求的 Windows 已验证令牌检索角色数据" />                <add name="AspNetAccessProvider"                    type="System.Web.Security.AccessRoleProvider,                       System.Web, Version=1.2.3400.0, Culture=neutral,                         PublicKeyToken=b03f5f7f11d50a3a"                    connectionStringName="AccessFileName"                    applicationName="/"                    description="从本地 Microsoft Access 数据库文件中存储和检索角色数据" />           </providers>        </roleManager>

虽然此提供程序模型主要旨在简化 Web 应用程序的表单验证，但也可用于创建并管理用户和角色的任意验证方案，还可执行通用活动，如密码重设、密码加密和用户验证。

小结

ASP.NET Whidbey 中的新组件和体系结构功能令人赞叹不已。新功能真正让人欣赏之处在于，您可以轻易地把各种功能组合在一起，构建成一个完整的应用程序，此外，对于需要具有可伸缩性的企业级应用程序，您可以非常容易地扩展这些功能。安全性也有了显著的加强。使用新模型使我们可以和使用 XML 配置文件开发可怜的“演示代码”说再见（这些 XML 配置文件保存未加密的凭据，并增加了服务器的文件访问负载）。当截至日期临近时，我们经常冒险发行演示代码。为什么不在第一次就开发出正确的代码呢？现在唯一欠缺的是心灵感应设备驱动程序，可以将我的想法实时转换成代码。