成员关系的概念在人类社会中是一个层次比较低的概念，源于希望属于某个群组的意识。我们希望能觉得自己是某个团队的一部分，让别人知道我们是谁，因此Web搭上这个流行趋势，采用这个概念只是时间早晚的问题。如果坐下来想一想曾经登录过多少个站点并在这些站点上保存了简单的用户信息，可能会发现自己所属的群组比一开始想象的要多得多。从出售书籍和小器具的站点到讨论拥有一辆Ford Puma的好处的社区，或者宣传一个名为Look Around You的BBC TV喜剧节目的站点，作者发现自己是会员的站点多得无法一一列举。接下来就会碰到一个熟悉的困难“登录这个站点要使用哪个用户名和口令？”
Web上最成功的站点之一，Amazon.com，一开始只是一个书店，但后面经营的范围越来越大。现在当用户登录Amazon时，将发现整个页面上全是与该用户的消费习惯有关的商品。
在本章中，您将学习怎样使用ASP.NET 2.0提供的成员关系功能实现站点的个性化。本章讨论如下内容：
● 身份、验证和授权的概念
● 成员关系服务器变量，包括Login控件
● 保存成员配置文件以便取回
● 在站点的特定部分实施访问限制，只运行特定的成员访问
● 根据当前用户配置文件个性化站点
还将扩展Wrox United示例站点，以便能够登录该站点并根据一组保存起来的个人偏好个性化站点，这些信息是基于成员配置文件的。
4.1 安全基础知识
在开始开发涉及到成员关系的应用程序时，必须首先理解几个关键的概念，这些概念是身份、验证和授权。
4.1.1 身份——我是谁
在考虑身份时，我们可以用几种独一的特性来描述自己。例如，我是一个头发金黄的女人，喜欢看科幻电影和组装PC机，但这些信息对于对我的羽毛球技术感兴趣的人来说并不是必需的。保存在站点中的身份信息很可能只与一个人的某些方面相关。例如，一个购物站点会保存用户的姓名、电话号码、电子邮件地址和家庭地址，这些信息都与商品的销售有关。它们可能不会关心您的个人兴趣(除非它们和Amazon的规模一样大)，所以它们并不需要保存关于用户的这类信息，但是这并不妨碍它们拥有这些方面的身份信息。
因此身份，也就是我是谁的概念，是一组范围很广的实际情况的集合。您可能曾经在简历里写下了很多实际情况，但这些情况同样只与潜在的雇主相关。在简历中保存和删除哪些情况由自己决定。在保存一个站点的成员的信息时，情况也是一样的，必须在开发阶段就确定要保存成员的哪些实际情况。
4.1.2 身份验证——这就是我
在试图登录一个网站的时候，用户要输入某些证书；例如，邮件地址及其口令的组合。
网站接下来必须判断用户是否就是自己声明的那个人，因此用户输入的邮件地址和口令的组合必须与保存在服务器文件中特定的邮件地址和口令组合相匹配。
身份验证的过程就是证明自己是自己所声明的那个人的过程。很多站点，不论它们是零售商品还是提供社区服务，都使用邮件地址和口令的组合作为身份验证方法，这是一种经过反复考验的方法。虽然这种方法不是绝对安全，但是只要选择一个足够可靠的口令并严格保密，同时站点的代码经过严格的测试，那么用户的配置文件将只能由用户本人使用。
4.1.3 授权——这是我能做的
在向网站输入用户名和口令之后，Web服务器将不仅会验证口令和用户名是否匹配，还将查看站点管理员给用户授予了什么权限。身份验证之后的下一个步骤是授权，这个步骤将检索您所拥有的用户账户类型的更多信息。
例如，以一个银行网站为例。在用户的登录信息通过验证之后，服务器将查看用户在该站点上的权限。与大多数用户一样，您可以查询账户、在账户之间转账或者支付账单。然而，如果银行受到某个安全方面的恐吓(类似于Internet上到处流传的网络钓鱼(phishing)电子邮件)，您可能会发现自己突然无法通过这个在线应用程序添加任何第三方代理订单，直到安全危机解除为止。功能的关闭很可能是由管理员为一些或所有用户设置一个特殊的标记而进行控制的，在页面上告诉用户他们不再有权限修改他们账户的详细信息。
4.1.4 登录站点
登录站点的过程，从用户的角度看，就是输入一组证书，然后根据自己的配置文件看
到不同用户界面的过程。通常，用户所使用的证书是用户名加口令的组合；然而，对于安全性更高的站点，例如银行站点，可以使用其他的方式登录，包括PIN和安全认证。如果不考虑向服务器传送身份验证证书的方法，那么身份验证的基本原则是一样的。一旦验证完成之后，通过身份验证机制查询用户具有什么样的权限就比较简单了。
撇开理论，ASP.NET 2.0提供了一些非常强大的工具，可以帮助开发人员以最小的代价实现登录-身份验证-授权架构。在旧版的ASP.NET中，开发人员必须编写代码实现登录、根据数据库进行验证并根据当前登录的用户做出响应。虽然开发人员最终仍要编写代码对用户进行处理(如本章后面的内容所示)，但是一些强大的控件和向导已经把这个过程起始阶段的各种困难都解决了。在这一节中，将进一步学习用于处理登录的服务器控件和ASP.NET Web Application Configuration实用工具。
4.2.1 Login控件
在本小节中，首先将创建一个只有两个页面的简单模拟站点；Default.aspx是前台页面，login.aspx是登录页面。您将进行一系列的练习，然后暂停下来查看幕后发生的是什么。在本章的后面，将把其中一些规则应用到Wrox United站点以便把登录架构整合到这个应用程序中。
这一节介绍以下几个控件：
● Login控件，该控件提供文本框、按钮和内建的身份验证功能，使开发人员通过简单的拖放操作就可以向页面添加登录功能。
● LoginView控件，该控件根据用户是否登录可以改变页面的外观，或者向不同
群组的用户显示不同的页面。
● LoginStatus控件，该控件向用户显示反馈信息，提醒用户他们是否已经登录站点。
在下面的“试一试”练习中，将使用以上的一些控件。这个示例通过创建页面并添加控件来搭建站点的骨架。
(1) 打开VWD并在C:\\BegASPNET2\\Chapters\\Begin目录中创建一个空白的站点，将其命名为Chapter04。默认情况下，站点中应该已经包含了一个名为Default.aspx的页面，如图4-1所示。
图 4-1
(2) 再添加控件。切换到Design View，从工具箱的Login面板中将LoginView控件拖放到页面上(如图4-2所示)。在弹出的Common Tasks菜单中，确保选择Anonymous
Template并在主文本框中输入You are not logged in。
图 4-2
(3) 通过单击该控件右上方的小箭头再次打开Common Tasks菜单并选择LoggedInTemplate，然后在文本框中输入You are logged in。这将确保页面提醒用户是否已经登录。
(4) 将一个LoginStatus控件拖放到页面上并放置在LoginView控件的下面，如图4-3所示。这个控件将根据用户当前是否已经登录向用户显示一个登录或登出链接。
图 4-3
(5) 下一步要创建一个登录页面，因此在Solution Explorer中单击站点的根目录并选择Add New Item。在弹出的对话框中，选择Web Form并命名为Login.aspx，如图4-4所示。
图 4-4
(6) 在这个新创建的页面中，从工具箱的Login面板上拖放一个Login控件到该页面
上，如图4-5所示。
(7) 在弹出的Common Tasks菜单中，可以管理站点。到现在为止，整个架构已经搭建完毕，但在站点能够运行之前需要添加一些用户账户，因此请单击Common Tasks菜单中的Administer Website链接启动ASP.NET Web Application Configuration工具，该工具将在下一个练习中介绍。
图 4-5
操作回顾
这些控件确实非常强大，虽然现在还不能运行这个示例，但是完全可以相信，只需再进行少量的处理，就可以获得一个能够试验登录功能的完整的(目的非常单纯的)站点。这些控件是在ASP.NET 2.0中新增加的；在以前，开发人员必须手动添加文本框、按钮并编写VB.NET或者C#代码来处理这个过程、显示用户是否登录的消息、以及根据当前的用户改变页面。到目前为止，您所需做的就是向页面中拖放一些控件，这就是搭建一个应用程序的架构必须完成的所有工作。
现在，让我们来看看添加到页面中的控件，从Default.aspx页面开始。
在Source View中查看Default.aspx页面将看到如下代码：
You are logged in You are not logged in.
在代码中可以看到两个已定义的控件：用于显示登录信息的LoginView控件和用于控制登录与登出过程的LoginStatus控件。注意如果按照本例进行配置，将无法看到匿名模板消息，因为匿名用户没有访问站点的权限(而是被直接导航到登录页面)。
在Login.aspx页面中，将看到如下已添加的代码：
几乎不用编写任何代码！所有的功能都已事先编写好，所以不会看到任何文本框，也不会看到任何身份验证代码—— 而只是看到一行代码。ASP.NET 2.0中提供工具让开发人员自己创建类似这种复杂的控件，但这个内容超出了本章的讨论范围。
在前一个练习的第7步中单击管理链接之后，VWD中将显示如图4-6所示的页面(注意每回第一次启动这个站点的时候端口号都将不同)。
图 4-6
(1) 单击Security链接显示Security设置管理选项卡，如图4-7所示。
图 4-7
(2) 该页面上有一个超链接，单击该链接可以启动Security Setup Wizard。单击该链接进入向导的第一步，如图4-8所示。
图 4-8
(3) 单击Next跳过这个页面，并进入如图4-9所示的界面。选择From the Internet单选按钮允许匿名用户和已登录的用户访问这个站点。
图 4-9
单击Next进入下一步，如图4-10所示。
图 4-10
可以直接跳过该页面并单击Next继续—— 默认的提供商将提供所有的功能。在下一个界面中，向导会询问是否希望为站点定义角色。在这个示例中，可以跳过这一步—— 本章的后面将定义角色。不要选中复选框并单击Next。
(4) 在到达下一个界面之后，该向导将提示输入用户的一些详细信息，如图4-11所示。
图 4-11
(5) 如图4-12所示，输入站点的某个用户的详细信息—— 这可能是您的姓名、我的姓名或者是其他任何人的姓名！只要别忘记所输入的口令就行—— 后面要用到这个口令。单击Create User按钮将显示一个确认提示，此时可以单击Continue创建另一个用户。到现在为止，已创建了两个用户—— 一个标准用户和一个后面将用作站点管理员的用户。
图 4-12
在后面的练习中，将为这些用户指定恰当的站点访问权限。注意现在还不能为用户指定任何角色—— 这将在后面的安装过程中完成。单击Next继续。
(6) 下一步是为站点定义权限级别，定义谁能看到站点的内容，谁不能访问站点。在这个步骤中，可以直接为用户添加权限。在后面，将把这些用户添加到不同的群组并为整个群组的用户赋予权限。如图4-13所示，需要为每个用户单独赋予Allow权限，并拒绝所有的匿名用户。为了设置某个用户的权限，首先选中User单选按钮，在该按钮后面的文本框中输入用户名，选择Allow，并单击Add This Rule。要拒绝匿名用户访问，选中Anonymous Users单选按钮，在Permission区单击Deny，并单击Add This Rule。
在单击Next之后，向导也将完成，这意味着现在有了一个拥有一些用户配置文件和访问权限级别的站点。现在就只剩下运行页面了！
(7) 返回VWD，按下Ctrl+F5运行Default.aspx页面—— 将看到如图4-14所示的画面。
由于匿名用户无法访问站点，因此站点直接显示登录页面。注意页面的地址，该地址表明要查看的是Default.aspx页面。
(8) 在登录之前，试着输入一些不合法的证书(一个不存在的用户名和口令，但口令不能为空)。将看到如图4-15所示的画面。
图 4-13
图 4-14
图 4-15
(9) 现在以一个合法的用户账户登录；站点将自动把您带回Default.aspx页面，如图4-16所示。
图 4-16
单击Logout链接将把您带回Login.aspx页面—— 这个站点不允许任何未登录的人查看网页。
操作回顾
用于ASP.NET页面的Login控件是Microsoft ASP.NET小组为开发人员准备的礼物。作者已经不记得参与过多少个带有定制登录功能的站点的开发，每个站点都要编写代码实现这个功能，而现在作者所要做的只是向页面拖放几个控件。除此之外，还可以使用向导配置账户和权限，进一步简化开发。您可能希望使用自己的用户账户数据存储库，或者甚至链接到活动目录(Active Directory)用户账户，但这可以在后面的开发过程中修改。
这个练习逐步介绍了用户账户的配置。虽然这是一个必要的过程，但Website Administration工具在幕后创建的内容更让人感兴趣。首先，创建的用户账户配置文件必
须保存在某个中心存储库，因此该工具为这个目的创建了一个新的配置文件数据库。查看C:\\BegASPNET2\\Chapters\\Begin\\Chapter04目录会看到一个名为App_Data的文件夹。单击右键并选择Refresh(刷新)文件夹，应该看到一个名为AspNetDB.mdf的文件。这是一个Microsoft SQL数据库文件，可以在VWD的开发环境中查看这个数据库表格的结构和内容，如图4-17所示(在学习数据库章节的时候将了解到这个过程的更多内容)。
图 4-17
配置的另一个部分是为用户账户赋予一定的权限以便他们能够访问站点。通过使用向导，这个过程可以变得很容易。在向导完成之后，解决方案中就新增了一个名为Web.config的文件(保存在服务器上以偏爱的方式运行站点的配置文件—— 详细内容请参阅第2章)。如果查看Chapter04文件夹中的Web.config文件，将看到如图4-18所示的语句。
图 4-18
注意这个配置文件中的
值得注意的是，LoginView控件除了根据用户是否已经登录显示特定的文本以外还可以完成很多功能。在第11章中，您将看到使用这个控件不仅基于用户的身份，而且基于用户的角色来改变整个页面的外观。这个控件可以包含文本、HTML甚至其他控件。下一个“试一试”练习中将进行演示。
4.2.2 个性化
站点个性化以反映当前登录用户的偏好是实现社区化和归属感的一种好方法。虽然本章不会进行很多个性化处理，但在下一章本书将讨论一些ASP.NET开发人员提供的功能，这些功能可以为用户提供更加个性化的用户界面和浏览体验。
对于任何个性化的站点，一个有用的附加功能是向已登录的用户通过某种类型的反馈信息，告诉用户站点已经正确地确认了他们的身份。LoginName控件是添加这种功能的简单方法。在下面的“试一试”练习中，您将了解到如何使用这个控件。在这个示例中，需要授权匿名用户访问站点。
(1) 可以选择任何一种喜欢的方式为匿名用户授权—— 要么编辑Web.config文件(参考前面的“操作回顾”)，要么启动Web Site Administration Tool。要再次启动这个工具，可以在系统托盘中右击管理站点图标并选择Open in Web Browser。或者，如果选中修改Web.config文件，只需在VWD中打开该文件并修改代码中的灰色部分：
问号表示所有匿名用户，因此通过将deny改为allow，启用匿名访问。
(2) 接下来需要对网页代码进行少量的修改以便添加LoginName控件。打开Default.aspx页面并弹出LoginView控件的Common Task菜单(单击该控件右上方的小
箭头并选择LoggedInTemplate，如图4-19所示)。将文本修改为You are logged in as，然后将一个LoginName控件拖放到文本的结尾处。
图 4-19
(3) 在将LoginName控件添加到页面之后不需要对其进行任何修改，所以现在就可以保存修改并运行页面了。首先看到的是一个匿名用户访问站点时的页面，如图4-20所示。
图 4-20
现在单击Login链接并登录站点。登录成功之后，应该可以看到类似图4-21所示的页面，具体内容与登录所使用的用户账户有关。
图 4-21
操作回顾
使用LoginName控件在页面上显示当前登录用户的身份是一种快捷简单的方法。如果切换到该页面的Source View，就可以看到LoginName控件，如下代码灰色部分所示：
You are logged in as
在作者的代码中增加了一些HTML代码；因为我在LoginName控件之后按下了Return(以便LoginStatus控件能显示在下一行)，在代码中出现了一个
HTML标记。这是一个简单的HTML换行代码。在从Design View切换到Source View之后，开发人
员经常可以看到类似的标记添加到代码中。最常见的两个符号是 和
； 是一个不可中断的空格(这个空格将和紧靠在它前面和后面的内容显示在同一行上)，而
是一个简单的换行符。这个示例的重点不是HTML代码，而是LoginName控件的源代码。同样，在产生的代码中也没有任何让人兴奋的内容，因为ASP.NET在幕后完成了寻找当前登录用户名称的重任，并在服务器呈现页面的时候将其插入到页面中。
注意并没有将LoginName控件添加到Anonymous模板中，其实也没有理由要这样做—— 如果作为匿名用户访问站点，该控件不会显示任何信息。
到现在为止您已经花了一定的时间试验用户账户和站点登录。在本章的前面，我们已经讨论过角色的概念。下一小节将介绍角色是什么以及怎样使用角色细化站点成员的特征。
4.2.3 成员关系
定义哪些用户可以访问站点对于一个小型的站点来说是完全可行的，但站点必须非常小而且规模必须保持在一个可管理的范围内。一种更好的解决方案是定义一组用户角色，然后将用户账户添加到恰当的角色中。一旦用户成为某个角色的成员之后，就可以基于角色为用户授权。
例如，考虑一个典型的站点配置情景：Administrators角色的所有成员可以访问站点，而且可以访问站点的所有部分。Users角色的所有成员可以访问该站点，但不能访问某些受限的部分。所有匿名用户都将看到裁减过的页面，但没有任何个性化信息，而且理所当然不能访问受限的部分。
第11章将更详细地讨论角色，包括充分利用角色细化Wrox United站点。同时，在
下面的“试一试”练习中可以体验到角色的作用，因为其中将扩展Chapter04示例包含角色。在这个示例中将定义两种角色：Users和Administrators。在向角色添加用户之前必须先创建这些角色。
(1) 先再次启动Web Site Administration Tool。如果最近曾经使用过这个工具，那么可以右击系统托盘中该工具的图标并选择Open in Web Browser。或者，可以在VWD的主菜单条中选择Website→ASP.NET Configuration。在打开该工具之后，选择Security选项卡并单击Enable Roles链接，如图4-22所示。
图 4-22
(2) 接下来应该可以单击Create or Manage Roles链接。单击该链接进入Create
New Role界面。在这里，需要创建两个角色：users和administrators，在文本框中输入角色的名称并单击Add Role即可(如图4-23所示)。
图 4-23
(3) 单击Administrators群组的Manage链接，然后搜索Administrator用户账户，使用如图4-24所示的搜索工具。搜索Administrator账户最简单的方法是搜索所有以A开始的账户，因此在文本框中输入a*并单击Find User。只要选中User Is In Role复选框即可将Administrator账户添加到Administrators角色中。
图 4-24
(4) 以相同的方式把其他用户账户添加到Users角色中。
(5) 单击Security选项卡返回到管理工具的主要Security区域。进入该选项卡之后，单击Manage access rules链接返回管理站点访问规则的页面。在前面的示例中已经使用过相同的界面管理访问规则(如图4-13所示)，现在删除单个用户的访问规则，取而代之为Administrators和Users两个群组赋予权限。在删除规则时，将看到如图4-25所示的提示。
图 4-25
接下来可以在如图4-26所示的界面中依次为每个角色添加新的权限。
图 4-26
在添加好规则后，应该可以看到如图4-27所示的规则列表。
图 4-27
(6) 如果现在再次运行这个应用程序，应该可以像原来一样使用相同的用户账户登录站点。如果修改某个角色的权限，那么角色中的所有成员都将受到影响，因此可以限制所有非管理员用户的访问权限。
操作回顾
这个示例中所做的修改都是在强大的Web Site Administration界面中完成的，这个工具简化了添加角色定义和访问规则的过程。如果要手动完成所有修改，如稍后所示，则必须修改前面见过的AspNetDB.mdf数据库中Roles表格的内容，然后通过手动修改UsersInRoles表格的内容向这些角色添加用户。接下来必须修改Web.config文件以改变
站点的存取权限。
这个工具将自动化地完成整个配置过程，因此配置和管理都变得更加简单！然而，这是Visual Web Developer和Visual Studio 2005的功能，而不是ASP.NET的功能，因此如果不能使用VWD开发环境，那么必须手动执行这些操作。
如果返回到Web.config文件的Source View，将看到其中发生了如下改动(灰色部分)：
另外，添加角色的过程也使用户配置文件数据库发生了少许改变，在该数据库中新增了两个表：一个用于保存角色，另一个用户记录用户分别属于哪个角色(如图4-28所示)。
图 4-28
4.2.4 身份验证
一个尚未讨论的问题是应用程序的身份验证是如何实现的，以及ASP.NET为身份验证提供了哪些选择。到目前为止，所有示例都依赖一种称为Forms身份验证的技术。那么，什么是Froms身份验证，其他的身份验证技术有哪些？
● Forms身份验证：要发出登录请求，需要在网页上填写一个表单并将该表单提交到服务器。服务器在接受该请求之后，将向用户的本地机器写一个cookie，在后续的浏览中，浏览器每次发送请求时都会将该cookie送回服务器，这样用户就可以根据自己的希望保持身份验证状态。
● Windows身份验证：登录页面将用户证书发送到Web服务器(只能是IIS，而不是VWD内建的Web服务器)。然后Web服务器使用应用程序所运行的虚拟目录配置的方法处理身份验证。IIS连接到Windows操作系统和Active Directory(活动目录)域结构上，这意味着它依赖于存储在站点外部的用户配置文件，并使用标准Windows证书登
录到站点。根据站点的配置情况以及登录计算机所使用的账户，甚至可以不用直接登录站点，因为当前所使用的Windows证书会自动传递到Web服务器进行身份验证。这种方式在开发局域网应用程序时特别有用。
● Passport身份验证：登录证书被传递到某个Microsoft Passport服务器，这个服务器集中保存了用户的配置文件。登录Hotmail账户使用的就是这种方式。由于可以配置Windows在启动时登录一个Passport账户，因此在访问Hotmail收件箱时甚至都不需输入口令。
Forms身份验证模式
本节讨论Forms身份验证的工作原理。考虑以下情景：
● 用户—— 假设是Bob—— 希望查看页面A，匿名用户不可以访问这个页面，因此当Bob试图访问页面A时，浏览器取而代之显示一个登录页面，如图4-29所示。
图 4-29
● Bob现在面对着登录页面。由于Bob以前已经在该站点上注册过，因此他使用他的用户名和口令组合登录这个站点。图4-30显示了Bob的浏览器和服务器之间的交互过程。
图 4-30
● Bob现在可以浏览页面A并因此感到高兴。现在Bob希望通过页面A上的一个链接查看页面B。在发送该页面的请求时，Bob的浏览器同时将cookie的一个副本发送到服务器，让服务器知道是Bob想要查看这个页面。服务器知道Bob的身份，而且喜欢Bob，所以根据请求将页面B发送给Bob，如图4-31所示。
图 4-31
● 如果Bob现在请求站点的主页，浏览器仍会将cookie和请求一起发送到服务器，因此即使主页不是受限的内容，cookie仍会被传递回服务器。由于主页没有受到限制，服务器不会考虑cookie，直接忽略它并将主页发送给Bob。
● Bob接着返回页面A。因为Bob机器上的cookie仍然是有效的，所以该cookie仍会被送回服务器。服务器也仍然喜欢Bob，所以它允许Bob浏览这个页面。
● Bob离开计算机并享受了一杯咖啡。然后去吃午饭。当他重新回到计算机前时，已经过了25分钟。Bob现在希望再次浏览页面B，但是他机器上的cookie已经过期了。服务器在接收页面请求时没有得到cookie，所以Bob必须重新登录。
一般都会将用户机器上的cookie设置为在一定时间之后过期。在上面的情景中，服务器为cookie指定了20分钟的有效期，这意味着只要在20分钟之内向服务器发送两次请求，本地机器上的cookie就将一直保持活动状态。然而，如果20分钟之内没有向站点发出请求，用户将必须重新登录才能查看受限的内容。
您将注意到在前面的示例中创建的登录页面为用户提供了“remember my details for next time”(记住用户名)选项。选中该选项将在浏览器的cookie集中写入一个有效时间更为长久的cookie，在下次访问这个站点的时候，您的账户名将提前显示在页面上。由于不应将口令信息保存在cookie中，因此每次登录都必须输入口令，但至少不用输入用户名字段。
其他的身份验证方法(Windows身份验证和Passport身份验证)提供的终端用户都比较熟悉。例如，Windows身份验证模式依赖于Web服务器(一般情况下都是IIS)来控制站点的访问权限，但也可以同时使用过期机制阻塞空闲了过长时间的用户。要配置Windows身份验证，需要指定位于公司Active Directory(AD)域内的哪些用户或角色可以访问站点。然后这些用户就可以使用登录公司网络上的计算机时所用的登录信息访问站点。
也可以在公司的外部环境中查看使用Windows身份验证模式的站点，只不过在试图查看一个由Windows身份验证模式保护的页面时必须输入标准Windows登录证书。
Passport身份验证模式的普及率没有Microsoft期望的那么高，但确实有一些站点连
接到Passport网络处理站点的身份验证(例如，Expedia.com)。Passport身份验证依赖于存储用户账户的数据库，该数据库可以通过任意线路进行访问，有点类似于保存Web账户的中心Active Directory。
本书使用Forms身份验证处理Wrox United站点的所有身份验证。
如果希望在Wrox United站点包含一些个性化信息，那么必须为其配置安全策略。已完成的站点中(www.wroxunited.net)具有购物车功能。另外，完成后的站点中还有一个管理区，允许管理员在其中编辑预定日期、修改成员资料等。所有这些都意味着必须在某个阶段添加一些用户和角色—— 由于您已经具有使用配置工具的充足经验，现在应该可以执行这个过程的第一个步骤。下面的“试一试”练习将带领您逐步为Wrox United站点配置用户账户和角色。在这个阶段，不必担心锁定了站点的部分内容；这是本书后续部分的任务。
(1) 先在VWD中打开本章的Wrox United示例站点。在打开该站点之后，单击Website菜单并选择ASP.NET Configuration。这将启动站点的配置工具。图4-32显示已完成的站点的配置界面。
图 4-32
(2) 单击Security链接进入配置用户和角色的选项页。与在本章前面的练习中进行的操作一样，启动安全设置向导。在操作该向导的过程中，选择如下内容：
● 该应用程序将使用在Internet上。
● 激活角色。
● 如果不存在角色，创建以下角色：Administrator、FanClubMember、Manager、Owner和Reporter(如图4-33所示)。
图 4-33
● 最后，创建用户账户—— 最少创建5个用户账户以便在每个角色中至少有一个账户。Wrox United应用程序预定义的用户账户如图4-34所示。
图 4-34
查看一下完整应用程序的配置可以看到预定义的用户账户分属于不同的角色，所以ChrisH账户是Reporter角色的成员，Jim是Owners角色的成员，而Lou是Fan Club角色的成员。
(3) 向导结束之后，需要在WroxUnited目录内创建一些子文件夹，它们将包含站点的特定部分—— Admin和FanClub部分。
(4) 现在可以进入管理Access Rules的区域添加以下规则：
● 对WroxUnited主文件夹，允许匿名访问。
● 对FanClub文件夹，首先拒绝所有用户访问，然后添加一个规则，只允许
FanClub角色的成员进行访问。
● 对Admin文件夹，拒绝所有用户访问。
由于现在还不会用到这些用户账户和角色，因此暂时不必对站点进行其他处理。然而，在创建站点的其他页面时这些准备工作将为以后的工作打下很好的基础。
操作回顾
在Wrox United应用程序中，可以看到一个功能完整的Web应用程序的配置信息。可以使用管理工具和Web.config文件任意查看这些配置，从而弄清楚这些基本权限是怎么设置的。这个示例只是简单介绍本书后面的内容，因为第11章详细讨论基于角色的权限控制并介绍其他通过使用角色允许和限制内容的技术。
用于过滤FanClub文件夹访问权限的代码已添加到FanClub文件夹内的Web.config文件中。如下所示：
注意FanClubMember角色被定义成惟一能够访问该文件夹内的内容的角色。
这个示例中创建的目录级别的权限已经在站点内创建了一个受限区域。第11章将在Administration小节和Fan Club小节中带领您进行一些练习，演示ASP.NET 2.0技术的不同组成部分。这些示例是基于对本节内容的理解之上的。
本章讨论了安全的基础内容、身份的概念以及登录站点的过程。有些概念对于任何使用Internet在网上冲浪、参加社区讨论或者在线购物的人来说都是很熟悉的，而且由于这些概念的使用范围是如此广泛，因此ASP.NET 2.0专门针对这些功能进行了设计，从而简化站点的创建工作。
需要理解的核心概念包括：
● Identity：身份，一个个体由一组属性进行描述，这些属性保证个体的惟一性。
● Authentication：身份验证，向服务器传送一组证书信息从而使服务器标识用户的身份。如果服务器可以标识试图进行连接的用户，那么用户将通过验证。
● Authorization：授权，将已通过验证的用户证书和一组访问控制规则进行比较，从而针对“这个用户能够访问所请求的资源吗？”这个问题给出答案。
● Personalization：个性化，根据当前登录的用户提供特定的信息。
● Membership：成员关系，表示归属的概念。本章讨论了用户属于特定角色的概念。
下一章将扩展个性化的概念介绍怎样实现ASP.NET站点的个性化。
(1) 修改本章中Wrox United应用程序的访问权限，允许匿名用户访问，但拒绝某个特定用户账户访问。
(2) 本章的示例站点中添加一个名为Admin的子文件夹。在该文件夹中，添加一个带有LoginName控件的页面，将其命名为MainAdmin.aspx，还可以在该页面上放置其他控件。修改这个文件夹的访问权限使得只有Administrators群组的成员能够访问它。
因篇幅问题不能全部显示，请点此查看更多更全内容