表单身份验证配置和高级主题
本文档是Visual Basic 教程（转至 Visual C# 教程）
本教程将介绍各种不同的表单身份验证设置 ，以及如何通过表单元素对它们进行修改。我们将深入地探讨如何自定义表单身份验证票证的timeout值、如何使用带有自定义URL的登录页面（例如使用SignIn.aspx ，而不是 Login.aspx ），以及无 cookie的表单身份验证票证。
有关该主题的更多详情，请参考以下视频：如何更改表单身份验证属性、如何在 ASP.NET 应用程序中设置和使用无 Cookie 的身份验证、ASP 表单登录重定位、表单登录自定义键配置、向身份验证方法添加自定义数据 以及使用自定义的主体对象。
简介在前一篇教程中 ，我们探讨了在ASP.NET 应用程序中实现表单身份验证所必需的步骤 ，包括在Web.config 文件中指定配置设置来创建一个登录页面 ，以及对已验证用户和匿名用户分别显示不同的内容。我们知道，用户可以通过将 <authentication> 元素的mode属性设置为Forms来配置网站使用表单身份验证。另外， <authentication> 元素还可以包含一个<forms>子元素，通过该子元素，我们可以指定各种表单身份验证设置。 本教程将介绍各种不同的表单身份验证设置，以及如何通过<forms>元素对它们进行修改。我们将深入地探讨如何自定义表单身份验证票证的timeout值、如何使用带有自定义URL的登录页面（例如使用SignIn.aspx ，而不是 Login.aspx ），以及无 cookie的表单身份验证票证。我们也将更仔细地研究表单身份验证票证的结构，以及ASP.NET为确保票证数据不被检测和截获而采取的措施。最后，我们将讨论如何在表单身份验证票证中存储额外的用户数据，以及如何通过一个自定义主体对象来为这些数据建模。 步骤1：了解<forms>配置设置ASP.NET中的表单身份验证系统提供一系列的配置设置，可根据应用进行自定义。这些设置包括：表单身份验证票证的生命周期；对票证实施何种保护；在哪种条件下使用无cookie的身份验证票证；登录页面的路径等等。要修改这些默认值，我们应在 <authentication> 元素中添加一个 <forms> 子元素，像对XML属性那样来指定希望自定义的属性值： 表1 对可以通过<forms> 元素进行自定义的属性进行了汇总。由于Web.config是一个XML文件，在下表左侧列中的属性名称都是区分大小写的。
表1：<forms>元素属性汇总 在ASP.NET 2.0 及更高版本中 ，默认的表单身份验证值都是.NET Framework 的FormsAuthenticationConfiguration 类中的固定值。所有修改都应在Web.config文件中根据各个应用程序进行。这与ASP.NET 1.x 不同。在ASP.NET 1.x 中，默认的表单身份验证值存储在 machine.config 文件中（因此，可以通过编辑machine.config来进行修改）。关于ASP.NET 1.x 这一主题，值得一提的是，很多表单身份验证系统设置在ASP.NET 2.0 及更高版本和在ASP.NET 1.x中的默认值是不同的。如果打算将应用程序从ASP.NET 1.x 环境中迁移出来，了解这些差异非常重要。关于这些差异，请参考<forms> 元素技术文档。 注意： 有几个表单身份验证设置，如 timeout 、domain和path ，对最终生成的表单身份验证票证 cookie进行了详细的指定。关于cookie的更多信息、它们的工作方式以及它们的各种属性等，请查阅Cookie 教程。 指定票证的Timeout值表单身份验证票证是代表身份的标记。使用基于cookie的身份验证票证时，该标记以cookie的形式存储。每次请求时，都会将该标记发送到web服务器。从本质上来说，拥有了该标记就相当于向系统宣布：“我是xxx ，我已经登录”。这样，当用户访问页面时，系统会记住用户的身份。 表单身份验证票证中不仅包含用户的身份，还包含有助于确保标记完整性和安全性的信息。毕竟，我们并不希望恶意用户创建一个假标记或偷偷地对某个有效标记进行修改。 票证中这类信息的一个示例是 到期时间，它是票证到期的日期和时间。每次 FormsAuthenticationModule 检查身份验证票证时，都要确保票证尚未过期。如果已经过期，则忽略票证，并将用户标识为匿名用户。这种安全措施可以抵御重播攻击。假如没有到期时间，如果黑客截获了用户的有效身份验证票证（可能是通过物理方式访问用户的计算机并找到用户的cookie ），他们就可以用偷来的身份验证票证向服务器发送请求，从而登录。虽然到期时间不能阻止这种情况的发生，但它能限制攻击可以成功的期限。 注意： 步骤 3将详细介绍表单身份验证系统用于保护身份验证票证的其它技术。 创建身份验证票证后，表单身份验证系统通过查询timeout设置来决定它的到期时间。正如表1中提到的那样， timeout 的默认值为30分钟，即，创建表单身份验证票证时，其到期时间被设置为自创建日期和时间起的30分钟。 到期时间定义的是表单身份验证票证到期的绝对时间。但开发人员通常希望实现可调节的到期时间，即，在用户每次访问站点时重设到期时间。我们将通过 slidingExpiration 设置来实现该行为。如果slidingExpiration设置为true （默认值），则每次FormsAuthenticationModule验证用户身份时，都更新票证的到期时间。如果设置为false ，则不在每次请求时更新到期时间，后果就是，一旦到了票证创建时设置的到期时间，票证就过期了。 注意： 身份验证票证中存储的到期时间是一个绝对的日期和时间值 ，如“August 2, 2008 11:34 AM”。并且，该日期和时间与web服务器的本地时间相关。假设web服务器所在的区域采用夏令时（ DST，将时间提前一小时），该设计方案会有一些有趣的副作用。我们来看看，如果到期时间是DST开始时（即2:00 AM）左右的30分钟， ASP.NET 站点会发生什么情况。假定某个用户在2008 年3 月11 日凌晨1:55 登录网站 ，那么系统将会为他创建一个表单身份验证票证 ，其到期时间为2008 年3 月11 日凌晨2:25（登录后的30分钟 ）。然而，到了凌晨2:00 ，由于 DST时间开始，时钟自动跳转到凌晨3:00 。当用户在登录 6分钟后（凌晨3:01 ）加载一个新页面时，FormsAuthenticationModule发现票证已经过期，因此将用户重定向到登录页面。要详细了解此事、其它身份验证票证超时趣事，以及解决方法，请参阅Stefan Schackow 所著的 专业ASP.NET 2.0安全、成员身份与角色管理(ISBN:978-0-7645-9698-8). 图1 阐述的是slidingExpiration 设置为false，且timeout 设置为30 时的工作流。注意，登录时生成的身份验证票证包含到期日期，且在以后的请求中不对该值进行更新。如果 FormsAuthenticationModule 发现票证过期，则丢弃票证，并将请求视为匿名请求。
图01：slidingExpiration 为false 时 ，表单身份验证票证到期时间的图形表示 （单击此处查看实际大小的图像） 图2 显示的是slidingExpiration 设置为true 且timeout 设置为30 时的流程。收到一个身份验证请求（且票证未到期）时，票证的到期时间被更新。
图02：slidingExpiration 为true 时 ，表单身份验证票证到期时间的图形表示 （单击此处查看实际大小的图像） 使用基于cookie 的身份验证票证 （默认值 ）时 ，问题就变得复杂了 ，因为cookie 也指定了自己的到期时间。 cookie 的到期时间（或没有指定到期时间）指示浏览器何时销毁cookie 。如果 cookie没有指定到期时间，则浏览器关闭时销毁cookie 。如果指定了到期时间，则 cookie就一直存储在用户的计算机中，直到超过到期时间中指定的日期和时间时才被销毁。 cookie 被浏览器销毁后，就不会再发送给web服务器了。因此， cookie 的销毁类似于用户从站点注销。 注意： 当然，用户也可以主动销毁存储在计算机中的cookie 。在 Internet Explorer 7 中，进入Tools 、Options ，单击 “Browsing history” 部分中的Delete按钮。然后，单击“Delete cookies” 按钮。 表单身份验证系统创建基于会话还是基于到期时间的cookie ，这取决于传递给 persistCookie参数的值。我们知道 FormsAuthentication 类的GetAuthCookie 、SetAuthCookie和 RedirectFromLoginPage 方法接受两个输入参数：username和persistCookie 。我们在前面教程中创建的登录页面包含一个“Remember me” 复选框，它决定是否创建一个永久性cookie 。永久性 cookie是基于到期时间的；而永久性cookie是基于会话的。 前面讨论的timeout和 slidingExpiration 概念应用到基于会话和基于到期时间这两种cookie时都是一样的。唯一比较大的区别在于执行方面：使用基于到期时间的cookie时，如果将 slidingTimeout 设置为true ，当指定的到期时间过了一半后，才对cookie的到期时间进行更新。 我们来对网站的身份验证票证超时策略进行改动，使票证在一个小时（ 60分钟）后过期，并使用可调节的到期时间。为此，我们需要更新Web.config文件，为 <authentication> 元素添加一个<forms>元素，标记如下：
使用Login.aspx 以外的登录页面URL由于FormsAuthenticationModule 自动将未授权用户重定向到登录页面 ，因此它需要知道登录页面的URL。该URL通过<forms>元素的loginUrl属性指定，默认值为“login.aspx” 。如果用户正在访问一个已有的网站，则可能有一个URL不同的登录页面，该URL已被搜索引擎标记和索引。不需要将已有的登录页面重命名为“login.aspx” ，也不需要断开链接和用户的书签，用户可以修改loginUrl属性，使其指向登录页面。 例如，如果用户的登录页面为SignIn.aspx ，并位于 Users目录中，我们可以将loginUrl配置设置指向 “~/Users/SignIn.aspx”，如下：
由于当前应用程序已有一个名为Login.aspx 的登录页面 ，因此不必在<forms> 元素中指定自定义值。 步骤2：使用无Cookie的表单身份验证票证默认情况下，表单身份验证系统根据访问站点的用户代理来决定是将身份验证票证存储在cookie集中还是嵌入URL中。所有主流的桌面浏览器，如Internet Explorer、 Firefox、 Opera 和Safari都支持cookie ，但不是所有的移动设备都支持 Cookie 。 表单身份验证系统使用的cookie策略取决于<forms>元素中的无cookie设置，它可设置的四个取值分别是：
AutoDetect 和UseDeviceProfile 设置都依靠一个 设备配置文件来决定是使用基于cookie 的身份验证票证还是无cookie 的身份验证票证。 ASP.NET 维护一个关于各种设备及其功能的数据库，数据库中的内容包括是否支持cookie以及支持的JavaScript版本等信息。 每次，当一个设备向 web服务器请求某个网页时，它会一起发送一个标识设备类型的 用户代理 HTTP标题。ASP.NET 会自动将设备提供的用户代理字符串与数据库中指定的相应配置文件进行匹配。 注意： 设备功能数据库存储在多个 XML 文件中 ，这些文件位于浏览器定义文件架构 中。默认的设备配置文件位于%WINDIR%\Microsoft.Net\Framework\v2.0.50727\CONFIG\Browsers中。我们也可以在应用程序的App_Browsers文件夹中添加自定义的文件。 更多信息，请参见如何在 ASP.NET 网页中检测浏览器类型。 由于默认设置为 UseDeviceProfile，当访问站点的设备的配置不支持cookie时，系统将使用无cookie的表单身份验证票证。 在URL中对身份验证票证进行编码每次对特定网站发出请求时， cookie 是存储浏览器信息的理想媒体，这也是访问设备支持cookie时表单身份验证设置默认使用cookie的原因。如果不支持cookie ，我们必须使用其它方法将身份验证票证从客户端传送到服务器。在无cookie环境中的通常做法是在URL中对cookie数据编码。 查看这些信息在URL中的嵌入方式的最好方法就是强制站点使用无cookie的身份验证票证。为此，我们可以将无cookie配置设置设为UseUri ：
完成上述更改后 ，通过浏览器访问站点。匿名访问时， URL 看起来和以前没有区别。例如，访问Default.aspx页面时，浏览器地址栏显示如下的 URL： https://localhost:2448/ASPNET_Security_Tutorial_03_CS/default.aspx 然而 ，一旦登录后 ，表单身份验证票证将嵌入到URL 中。例如，当访问登录页面并以Sam的名义登录后，系统将返回到Default.aspx页面，但此时的URL为： https://localhost:2448/ASPNET_Security_Tutorial_03_CS/(F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2))/default.aspx 表单身份验证票证已嵌入到URL 中。字符串 (F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2)是十六进制编码的身份验证票证信息，这与通常情况下存储在cookie中的数据相同。 为使无cookie的身份验证票证正常运行，系统必须对页面上的所有URL编码以包含身份验证票证数据。否则，用户单击某个链接时，身份验证票证会丢失。幸好，嵌入逻辑是自动执行的。为演示此功能，我们打开Default.aspx页面，并添加一个HyperLink控件，分别将其Text和NavigateUrl属性设置为"Test Link" 和"SomePage.aspx" 。当然，这并不是说我们的项目中真的有个页面叫SomePage.aspx 。 保存对Default.aspx的更改，然后从浏览器中访问该页面。登录该站点，这样表单身份验证票证就被嵌入到URL中了。然后，在Default.aspx中，单击“Test Link” 链接。发生了什么 ？如果不存在SomePage.aspx页面，则会发生一个404错误，不过此错误在这里并不重要。注意观察浏览器的地址栏，我们会发现 URL 中包含了表单身份验证票证！ https://localhost:2448/ASPNET_Security_Tutorial_03_CS/(F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2))/SomePage.aspx 链接中的URL “SomePage.aspx” 将自动转换成一个包含身份验证票证的URL – 我们不必写一行代码 ！表单身份验证票据将自动嵌入到任何超链接的URL 中 ，只是超链接不以"http://" 或“/” 开头。至于超链接是出现在一个对 Response.Redirect 的调用中，一个HyperLink控件中，还是一个anchor HTML 元素（即， <a href="...">...</a>）中，这都没有关系。只要URL不是 “http://www.someserver.com/SomePage.aspx” 或“/SomePage.aspx”这样的形式，系统都会对表单身份验证票证进行嵌入处理。 注意： 无 cookie的表单身份验证票证与基于cookie的身份验证票证采用相同的超时策略。但无cookie的身份验证票证更容易受到重播攻击，原因是身份验证票证被直接嵌入到URL中。设想一下，假如某个用户访问一个网站，登录后将URL复制下来通过电子邮件发送给同事。如果他的同事在票证到期之前单击该链接，那么他们都将作为发送电子邮件的那个用户登录系统！ 步骤3：保护身份验证票证表单身份验证票证在cookie 中或直接嵌入到URL 中进行有线传输。除身份信息外，身份验证票证还可以包含用户数据（我们将在步骤4中看到）。因此，对票证数据进行加密以避免窥探是很重要的。更重要的是，表单身份验证系统必须确保票证未被篡改。 为确保票证数据的私密性，表单身份验证系统可对票证数据进行加密。加密票证数据失败时会以明文的形式传递敏感信息。 为确保票证的真实性，表单身份验证系统必须 验证 票证。验证就是确保特定数据未被修改的行为，这是通过消息身份验证代码 (MAC)来实现的。简单的说， MAC 是一小段信息，用于识别需要进行验证的数据（此时为票证）。如果MAC表示的数据被改动过，则MAC和数据不匹配。此外，对某个黑客来说，既要改动数据，还要根据修改的数据生成一个自己的MAC ，这实在很困难。 表单身份验证系统创建（或改动）票证后，会生成一个MAC并将其附加在票证数据中。后续的请求到达时，表单身份验证系统将MAC与票证数据进行比较，以验证票证数据的真实性。图 3 以图表的形式阐述了该流程。
图03：通过MAC 确保票证的真实性 （单击此处查看实际大小的图像） 对身份验证票证运用何种安全措施取决于<forms> 元素中的protection设置。 protection 可设置的三个取值分别为：
Microsoft强烈推荐使用All配置。 设置验证和加密密钥表单身份验证系统加密和验证身份验证票证时使用的加密和哈希算法可以在Web.config 文件的<machineKey>元素 中自定义。表 2列出了 <machineKey> 元素的属性以及可能的取值。
表2：<machineKey>元素属性 对这些encryption 和validation 选项的深入讨论 ，以及各种算法优缺点的探讨不在本文章的范畴之内。对这些问题的深入探讨，包括使用哪种加密和验证算法、密匙的长度以及生成这些密钥的最佳方式，请参考 专业ASP.NET 2.0安全、成员身份与角色管理 。 默认情况下，系统会自动为每个应用程序生成用于加密和验证的密钥，这些密钥都存储在本地安全授权(LSA)中。简而言之，默认设置可保证对于每个web服务器和应用程序，密钥都是唯一的。因此，这种默认行为在如下两种情况下行不通：
使用web 场设置或同一服务器上的多个应用程序间共用身份验证票证时 ，用户必须在受影响的应用程序中配置<machineKey> 元素 ，保证它们的decryptionKey 和validationKey 值互相匹配。 虽然我们的示例应用程序不属于上述两种情况，我们也可以显式地指定decryptionKey和validationKey值，并定义要使用的算法。在Web.config文件中添加一个 <machineKey> 设置：
更多详情 ，请参阅如何在 ASP.NET 2.0 中配置 MachineKey。 注意： decryptionKey 和validationKey值来自Steve Gibson 的 Perfect Passwords 网页，每次访问该页面时，它生成64个随机的十六进制字符。为减少这些密钥进入产品应用程序的可能性，建议使用Perfect Passwords 页面随机生成的密钥替换上述密钥。 步骤4：在票证中存储其它用户数据很多web应用程序显示当前登录用户的信息。例如，一个web页面可能在页面上面的一角显示用户的名称以及她上次登录的日期。表单身份验证票证存储了当前登录用户的用户名，但如果需要其它的信息，页面必须到用户存储（一般为数据库）查找身份验证票证中没有存储的信息。 我们只需要编写少量代码就可以在表单身份验证票证中存储其它用户信息。可使用 FormsAuthenticationTicket 类的 UserData 属性来存储这些数据。该属性是存储最常用的与用户有关的少量信息的理想之地。 UserData 属性中指定的值是身份验证票证cookie的一部分。与其它票证域一样，该值根据表单身份验证系统的配置来进行加密和验证。默认情况下， UserData 是一个空字符串。 为了在身份验证票证中存储用户数据，我们需要在登录页面中编写一些代码，获取与用户有关的信息并存储在票证中。由于UserData是一个字符串类型的属性，因此存储在该属性中的数据必须要序列化为一个字符串。例如，假定我们的用户存储包括每个用户的出生日期和雇主名称，我们希望将这两个属性值存储在身份验证票证中。我们可以在用户的出生日期字符串后跟一个管道符(“|”) ，管道符后再跟雇主名称，从而将这些值序列化到一个字符串中。对于出生在1974年8月15日并为Northwind Traders 工作的用户，我们可用为UserData属性分配字符串： “1974-08-15|Northwind Traders”。 当我们需要访问存储在票证中的数据时，我们可以获取当前请求的 FormsAuthenticationTicket，并对UserData属性进行反序列化。在出生日期和雇员名称示例中，我们可以根据分隔符(“|”) ，将 UserData字符串拆分成两个子串。
图04：其它用户信息可存储在身份验证票证中 （单击此处查看实际大小的图像） 将信息写入UserData不幸的是 ，将与用户有关的信息添加到表单身份验证票证并不像大家期望的那么简单。 FormsAuthenticationTicket 类的UserData属性是只读属性，只能通过FormsAuthenticationTicket类的构造函数进行指定。当我们在构造函数中指定UserData属性时，我们还需要提供票证的其它值： username、 issue date 以及expiration等。在前面的教程中，我们创建登录页面时， FormsAuthentication 类自动帮我们进行了处理。在FormsAuthenticationTicket中添加UserData时，我们需要编写代码复制大部分 FormsAuthentication 类已提供的函数。 让我们更新Login.aspx页面，在身份验证票证中记录其它的用户有关信息，从而探讨处理UserData时的必需代码。假设我们的用户存储中包含用户公司的名称，以及用户的职称，而且我们想在身份验证票证中获取这些信息。对Login.aspx页面的LoginButton Click 事件处理程序进行更新，代码如下所示：
我们来逐行进行分析。该方法首先定义了4 个字符串数组 ：users、passwords、companyName 和titleAtCompany。这些数组用于存储系统中用户帐户的用户名、密码、公司名称、以及职称，这里有3个用户： Scott、 Jisun 和Sam 。在实际的应用程序中，这些值都是从用户存储中查询得到的，而不是在页面源代码中的固定值。 在前面的教程中，如果用户提供的凭据有效，我们只调用 FormsAuthentication.RedirectFromLoginPage(UserName.Text, RememberMe.Checked)，它执行以下步骤：
这些步骤在上述代码中是重复的。首先 ，我们用管道符(“|”) 将公司名称和用户职称合并成一个字符串 ，作为最终存储在UserData 属性中的字符串。 Dim userDataString As String = String.Concat(companyName(i), "|", titleAtCompany(i)) 接下来 ，调用FormsAuthentication.GetAuthCookie方法 ，该方法创建身份验证票证 ，根据配置进行加密和验证 ，并将它分配给一个HttpCookie 对象。 Dim authCookie As HttpCookie = FormsAuthentication.GetAuthCookie(UserName.Text, RememberMe.Checked) 为了处理嵌入cookie 中的FormAuthenticationTicket，我们需要调用FormAuthentication 类的Decrypt 方法 ，传入cookie 值。 Dim ticket As FormsAuthenticationTicket = FormsAuthentication.Decrypt(authCookie.Value) 然后，根据已有的 FormsAuthenticationTicket 值，我们创建一个新的FormsAuthenticationTicket实例。但这个新票证包含与用户有关的信息 (userDataString)。 Dim newTicket As FormsAuthenticationTicket = New FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, userDataString) 我们调用Encrypt方法 对新 FormsAuthenticationTicket 实例进行加密 （和验证 ），并将加密 （和验证 ）完的数据放回authCookie。 authCookie.Value = FormsAuthentication.Encrypt(newTicket) 最后，将authCookie添加到 Response.Cookies 集，并调用GetRedirectUrl方法来确定将用户导航到的页面。
所有这些代码都是必须的 ，因为UserData 属性是只读属性 ，且FormsAuthentication 类的GetAuthCookie、SetAuthCookie 或RedirectFromLoginPage 方法中都没有提供任何指定UserData 信息的途径。 注意： 我们刚刚探讨的代码在基于 cookie的身份验证票证中存储用户有关的信息。将表单身份验证票证序列化到URL是.NET Framework 内部的类完成的。简而言之，我们不能将用户数据存储在无cookie的表单身份验证票证中。 访问UserData信息此时 ，当用户登录时 ，用户的公司名称和职称都存储在表单身份验证票证的UserData 属性中。在任何一个页面上，无需查询用户存储，我们就可以从身份验证票证中访问这些信息。为演示如何从UserData属性中提取这些信息，我们对Default.aspx页面进行更新，使欢迎信息中不但包含用户名，还包含公司名称和用户职称。 目前， Default.aspx 页面包含一个AuthenticatedMessagePanel面板，里面有一个名为WelcomeBackMessage的标签控件。该面板是面向已验证身份的用户的。对Default.aspx页面的Page_Load事件处理程序中的代码进行更新，如下所示：
如果Request.IsAuthenticated 为True，则先将WelcomeBackMessage 的Text 属性设置为“Welcome back, username”。然后，将User.Identity属性分配给一个FormsIdentity对象，这样我们就可以访问基础FormsAuthenticationTicket 。一旦获取到FormsAuthenticationTicket ，我们就将 UserData属性反序列化成公司名称和职称。反序列化操作跟据管道字符来拆分字符串。然后，系统将公司名称和用户职称显示在 WelcomeBackMessage 标签中。 图5显示的是实际的屏幕截图。以Scott身份登录，屏幕将显示包含Scott的公司名称和职称的欢迎消息。
图05 ：显示当前登录用户的公司和用户职称（单击此处查看实际大小的图像） 注意： 身份验证票证的 UserData 属性是用户存储的一个缓存。与其它缓存一样，当基础数据发生改变时，需要对该缓存进行更新。例如，如果有一个网页，用户可以通过它来更新其配置文件，则缓存在UserData属性中的域必须刷新以反映用户所作的改动。 步骤5：使用自定义的主体对象每次接收到请求时， FormsAuthenticationModule 都会验证用户的身份。如果身份验证票证未到期， FormsAuthenticationModule 就将 HttpContext.User 属性分配给一个新的GenericPrincipal对象。该GenericPrincipal对象有一个FormsIdentity类型的Identity ，它包含对表单身份验证票证的引用。 GenericPrincipal 类仅包含实现IPrincipal的类所需要的最少功能–它只有一个Identity属性和一个IsInRole方法。 主体对象有两个职责：指出用户属于什么角色以及提供身份信息。这两个职责分别通过IPrincipal接口的IsInRole( roleName) 方法和Identity属性来实现。 GenericPrincipal 类允许通过它的构造函数指定角色名称字符串数组，而其IsInRole( roleName) 方法仅检查传入的roleName是否在该字符串数组中。 FormsAuthenticationModule 创建GenericPrincipal时，向GenericPrincipal的构造函数传入一个空的字符串数组。因此，调用IsInRole时，总是返回False 。 对大多数没有用到角色的、基于表单的身份验证情景而言， GenericPrincipal 类是满足其需要的。对那些使用默认角色处理无法满足需求的情况，或者需要将用户与一个自定义的IIdentity对象关联起来的情况，我们可以在身份验证流程中创建一个自定义的IPrincipal对象，并将其分配给 HttpContext.User 属性。 注意： 正如我们将在以后的教程中看到的那样，启用ASP.NET角色框架时，它创建一个类型为RolePrincipal的自定义主体对象，并覆盖表单身份验证创建的GenericPrincipal对象。这是为了对主体对象的IsInRole方法进行自定义，从而与角色框架的API相接。 由于我们现在还没有涉及到角色，我们此时创建自定义主体对象的唯一理由就是将自定义的IIdentity对象与主体对象关联起来。在步骤4中，我们探讨了如何在身份验证票证的UserData属性中存储其它用户信息（在本示例中是用户的公司名称和职称）。然而， UserData 信息只能通过身份验证票证进行访问，而且是一个序列化的字符串。这就意味着，我们想查看存储在票证中的用户信息时，必须对UserData属性进行解析。 通过创建一个实现IIdentity并包含CompanyName和Title属性的类，可以提升开发人员的体验。那样的话，开发人员就可以通过CompanyName和Title属性直接访问当前登录用户的公司名称和职称，而无需了解如何对UserData属性进行解析。 创建自定义的Identity和Principal类在本教程中，我们在App_Code文件夹中创建自定义的主体对象和标识对象。 首先，在项目中添加一个 App_Code文件夹 –在解决方案资源管理器中右键单击项目名称，选择Add ASP.NET Folder 选项，然后选择App_Code。App_Code文件夹是一个特殊的ASP.NET文件夹，用于存放与网站有关的类文件。 注意： 只有通过网站项目模型对项目进行管理时才使用App_Code文件夹。如果用户使用的是Web 应用程序项目模型，则创建一个标准的文件夹，并在其中添加类。例如，创建一个名为Classes的新文件夹，并在其中存放代码。 然后 ，在App_Code 文件夹中添加两个新的类文件 ，它们的名称分别是CustomIdentity.vb 和CustomPrincipal.vb。
图06：在项目中添加CustomIdentity 和CustomPrincipal 类 （单击此处查看实际大小的图像） CustomIdentity 类负责实现IIdentity 接口 ，而IIdentity 接口用于定义AuthenticationType、IsAuthenticated 和Name 属性。除了这些必需的属性外，我们还希望展示基础表单身份验证票证以及用户的公司名称和职称属性。在CustomIdentity类中输入以下代码。
注意 ，该类包含一个FormsAuthenticationTicket 成员变量(_ticket)，必须通过构造函数提供该票证信息。票证数据用于返回标识的Name ；其 UserData属性经过解析后返回CompanyName和Title属性的值。 接下来，创建 CustomPrincipal 类。因为此时我们不关心角色，因此CustomPrincipal类的构造函数仅接受一个 CustomIdentity 对象，其IsInRole方法总是返回False 。
将CustomPrincipal 对象分配给传入请求的安全上下文现在 ，我们有一个扩展默认IIdentity 规范的类 ，它包含CompanyName 和Title 属性 ，以及一个使用自定义标识的自定义principal 类。我们现在将进入ASP.NET管道，将自定义的主体对象赋值给传入请求的安全上下文。 ASP.NET管道收到一个请求后，通过一系列的步骤对它进行处理。每一步都会触发一个特定的事件，这就为开发人员进入ASP.NET管道并在其生命周期的某一点上对请求进行修改提供了可能。例如， FormsAuthenticationModule 等待ASP.NET触发AuthenticateRequest 事件 ，此时它针对身份验证票证检查传入请求。如果发现身份验证票证，则创建一个 GenericPrincipal 对象，并分配给HttpContext.User属性。 AuthenticateRequest事件之后， ASP.NET 管道触发 PostAuthenticateRequest 事件，在该事件中，我们可以将 FormsAuthenticationModule 创建的GenericPrincipal对象替换为CustomPrincipal对象的一个实例。图7描述了该流程。
图07：在PostAuthenticationRequest 事件中将GenericPrincipal 替换为CustomPrincipal（单击此处查看实际大小的图像） 为执行响应ASP.NET 管道事件的代码 ，我们可以在Global.asax 中创建相应的事件处理程序 ，或者创建自己的HTTP 模块。对于本教程，我们在Global.asax中创建事件处理程序。首先，将Global.asax添加到网站。在解决方案资源管理器中右键单击项目名称，添加一个名为Global.asax的Global Application Class 类型的项目。
图08：在网站中添加一个Global.asax 文件 （单击此处查看实际大小的图像） 默认的Global.asax 模板包含一些ASP.NET 管道事件的事件处理程序 ，包括Start、End 以及Error 事件等等。我们可以随意删除这些事件处理程序，因为我们的应用程序不需要使用它们。我们关心的事件是 PostAuthenticateRequest。更新Global.asax文件，其标记应如下所示：
Application_OnPostAuthenticateRequest方法只在ASP.NET 运行时触发PostAuthenticateRequest 事件时才执行 ，该事件在每个传入页面请求抵达时发生一次。事件处理程序首先检查用户是否通过了身份验证，且验证方式是否为表单身份验证。如果是，则创建一个新的 CustomIdentity 对象，并将当前请求的身份验证票证传给它的构造函数。接下来，创建一个 CustomPrincipal 对象，并将刚才创建的CustomIdentity对象传递给它的构造函数。最后，将当前请求的安全上下文分配给最近创建的 CustomPrincipal 对象。 注意最后一步–将 CustomPrincipal 对象与请求的安全上下文关联起来–将主体对象赋值给两个属性： HttpContext.User 和Thread.CurrentPrincipal 。这两个赋值是必需的，这是由 ASP.NET处理安全上下文的方式决定的。 .NET Framework 将一个安全上下文与每个运行线程关联起来。可通过 Thread 对象的 CurrentPrincipal 属性，以 IPrincipal对象的形式来获得这些信息。容易让人困惑的是ASP.NET也有自己的安全上下文信息 (HttpContext.User)。 在某些情况下，确定安全上下文时检查 Thread.CurrentPrincipal 属性；而在其它情况下，使用HttpContext.User属性。例如， .NET中有一些安全特性，允许开发人员声明哪些用户或角色可以实例化某个类或调用特定的方法（参见使用 PrincipalPermissionAttribute 向业务和数据层添加授权规则 ）。在内部，这些声明技术通过Thread.CurrentPrincipal属性来确定安全上下文。 在其它情况下，使用 HttpContext.User 属性。例如，在前面的教程中，我们使用该属性来显示当前登陆用户的用户名。显然， Thread.CurrentPrincipal 属性和HttpContext.User属性中的安全上下文必须匹配。 ASP.NET运行时自动为我们同步这些属性。然而，该同步发生在AuthenticateRequest事件之后， PostAuthenticateRequest 事件 之前。因此，在PostAuthenticateRequest事件中添加自定义的主体对象时，我们需要手动地为Thread.CurrentPrincipal赋值，不然 Thread.CurrentPrincipal 和HttpContext.User不会同步。有关该问题的更详细讨论，参见Context.User 与 Thread.CurrentPrincipal。 访问CompanyName和Title属性任何时候，当请求抵达并分派到ASP.NET引擎时，都会触发Global.asax文件中的 Application_OnPostAuthenticateRequest 事件处理程序。如果请求成功通过 FormsAuthenticationModule 的身份验证，该事件处理程序将创建一个新的CustomPrincipal对象，该对象包含一个基于表单身份验证票证的 CustomIdentity 对象。完成这些逻辑处理后，我们就可以非常方便地访问有关当前登录用户的公司名称和职称的信息。 返回到 Default.aspx 页面的 Page_Load 事件处理程序，在步骤 4 中，我们在该事件处理程序中写入了提取表单身份验证票证和解析 UserData 属性的代码，以显示用户的公司名称和职称。现在，由于使用的是 CustomPrincipal 和 CustomIdentity 对象，我们不需要解析票证的 UserData 属性值。而仅需要获取对 CustomIdentity 对象的引用，并使用其 CompanyName 和 Title 属性：
小结在本教程中 ，我们探讨了如何通过Web.config 文件来自定义表单身份验证系统的设置。我们还研究了如何处理身份验证票证的到期时间，以及加密和验证安全措施如何防止票证被窥探和修改。最后，我们讨论了使用验证票证的UserData属性在票证中存储其它用户信息，以及如何使用自定义的主体对象和标识对象来让开发人员更方便地访问这些信息。 本教程结束了对ASP.NET表单身份验证的讨论。在下一篇教程中，我们将开始探讨成员身份框架。 快乐编程！
|
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
