ASP.NET 安全性

本章内容

ASP.NET 是开发本指南所讨论的分布式 Web 应用程序的重心。它提供丰富而且容易访问的安全能力级，从而方便了安全的 Web 应用程序的创建。ASP.NET 被设计成与 Internet Information Services (IIS) 的现有安全能力相兼容，但同时它也非常灵活，而且可以扩展。这意味着您可以构建与自己的应用程序紧密集成的自定义安全机制。

本章提供指南和建议来帮助您解决在构建安全的 ASP.NET Web 应用程序时碰到的身份验证、授权和安全通信等问题。

注 本章所提供的大多数指南和建议同样适用于开发 ASP.NET Web 服务和由 ASP.NET 托管的 .NET Remoting 对象。

目标

利用本章来：

适用于

本章适用于以下产品和技术：

如何使用本章

要想从本单元获得最大价值，您必须：

本页内容

	ASP.NET 安全体系结构
	身份验证和授权策略
	配置安全性
	编程安全性
	Windows 身份验证
	窗体身份验证
	无 Cookie 窗体身份验证
	更多信息
	Passport 身份验证
	自定义身份验证
	ASP.NET 的进程标识
	模拟
	访问系统资源
	访问 COM 对象
	访问网络资源
	安全通信
	存储机密
	保护会话和视图状态
	网络场注意事项
	小结

ASP.NET 安全体系结构

ASP.NET 与 IIS、.NET Framework 和操作系统所提供的基础安全服务配合使用，共同提供一系列身份验证和授权机制。图 1 总结了这些机制。

图 1. ASP.NET 安全服务

图 1 阐释了 IIS 和 ASP.NET 所提供的身份验证和授权机制。当客户端发出 Web 请求时，就会发生以下一系列身份验证和授权事件：

网关守卫

ASP.NET Web 应用程序中的授权点或网关守卫是由 IIS 和 ASP.NET 提供的：

IIS

如果关闭了匿名身份验证，则 IIS 只允许来自特定用户的请求，即它可以在其自己的域或受信任域中验证这些用户的身份。

对于静态文件类型（例如 .jpg、.gif 和 .htm 文件，即没有映射到 ISAPI 扩展的文件），IIS 使用与所请求的文件相关的 NTFS 权限来执行访问控制。

ASP.NET

ASP.NET 网关守卫包括 UrlAuthorizationModule、 FileAuthorizationModule 和主体权限要求和角色检查。

UrlAuthorizationModule

可以配置应用程序 Web.config 文件中的 <authorization> 元素来控制哪些用户和用户组可以访问应用程序。授权是基于存储在 HttpContext.User 中的 IPrincipal 对象进行的。

FileAuthorizationModule

对于被 IIS 映射到 ASP.NET ISAPI 扩展(Aspnet_isapi.dll) 的文件类型，使用已验证用户的 Windows 访问令牌（可能是 IUSR_MACHINE），根据附加到所请求的 ASP.NET 文件的 ACL 自动执行访问检查。

注要进行文件授权，并不要求模拟。

FileAuthorizationModule 类只对所请求的文件执行访问检查，而不对所请求的页面中的代码所访问的文件执行访问检查，但 IIS 对这些文件执行访问检查。

例如，如果您请求 Default.aspx，并且它包含一个嵌入的用户控件(Usercontrol.ascx)，而该控件又包含一个图像标签（指向 Image.gif），则 FileAuthorizationModule 会对 Default.aspx 和 Usercontrol.ascx 执行访问检查，因为 IIS 将这些文件类型映射到 ASP.NET ISAPI 扩展。

FileAuthorizationModule 不对 Image.gif 执行访问检查，因为它是由 IIS 内部处理的静态文件。然而，由于 IIS 对静态文件执行访问检查，所以仍然使用进行相应配置的 ACL 对已验证用户授予读取该文件的权限。

图 2 显示了此方案。

注 对于系统管理员：需要给已通过身份验证的用户授予读取此方案中涉及的所有文件的 NTFS 权限。惟一的变化是使用哪个网关守卫来执行访问控制。ASP.NET 进程帐号只需要读取 ASP.NET 注册文件类型的访问权限。

图 2. IIS 和 ASP.NET 网关守卫一起使用

在此方案中，您可以在文件入口处禁止访问。如果您配置了附加到 Default.aspx 的 ACL，并且拒绝访问某个特定的用户，则 Default.aspx 中的代码无法将用户控件或任何嵌入图像发送到客户端。如果该用户直接请求图像，则 IIS 亲自执行访问检查。

主体权限要求和明确的角色检查

除了可以用 IIS 和 ASP.NET 配置的网关守卫外，还可以将主体权限要求（以声明方式或编程方式）用作附加的细分访问控制机制。通过使用主体权限检查（由 PrincipalPermissionAttribute 类执行），您可以根据各个用户的标识和组成员身份（由附加到当前线程的 IPrincipal 对象定义）控制访问类、方法或个别代码块。

注用于请求角色成员身份的主体权限要求与调用 IPrincipal.IsInRole 来测试角色成员身份不同；如果调用者不是指定角色的成员，则前者产生异常，而后者仅返回一个布尔值来确认角色成员身份。

在 Windows 身份验证中，ASP.NET 自动将一个代表已验证身份用户的 WindowsPrincipal 对象连接到当前的 Web 请求（使用 HttpContext.User）。窗体和 Passport 身份验证创建具有相应标识但没有角色的 GenericPrincipal 对象，并将它附加到 HttpContext.User。

更多信息

返回页首

身份验证和授权策略

ASP.NET 提供了若干以声明方式和编程方式进行授权的机制，这些机制可与各种身份验证方案配合使用。这样，您就可以开发深入的授权策略以及可以配置为提供各种粒度级别（例如，基于角色的每用户或每用户组）的授权策略。

本节说明一组常用身份验证选项的可用授权选项（可进行配置和编程）。

下面概述了身份验证选项：

可用的授权选项

下表列出了一组可用的授权选项。对于每个选项，该表都指出是否需要 Windows 身份验证和／或模拟。如果特定授权选项不需要 Windows 身份验证，则该选项适用于所有其他的身份验证类型。可以使用该表优化身份验证／授权策略。

带模拟的 Windows 身份验证

以下配置元素显示了如何明确启用 Web.config 或 Machine.config中的 Windows (IIS) 身份验证和模拟。

注 应根据每个应用程序的具体情况，在应用程序的 Web.config 文件中配置身份验证。

<authentication mode="Windows" />
<identity impersonate="true" />

在此配置中，ASP.NET 应用程序代码模拟已由 IIS 验证身份的调用者。

可配置的安全性

当您将 Windows 身份验证和模拟功能一起使用时，就可以使用下列授权选项：

<authorization>
  <deny user="DomainName\UserName" />
  <allow roles="DomainName\WindowsGroup" />
</authorization>

编程安全性

编程安全性是指 Web 应用程序代码中的安全检查。在您使用 Windows 身份验证和模拟功能时，可以使用下列程序安全设置选项：

PrincipalPermission permCheck = new PrincipalPermission(
                                       null, @"DomainName\WindowsGroup");
    permCheck.Demand();

[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName\WindowsGroup)]

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

ContextUtil.IsCallerInRole("Manager")

何时使用

使用 Windows 身份验证和模拟的情况：

在应用程序中使用模拟之前，确保将此方法与使用受信任的子系统模型进行比较，了解此方法的优缺点。“身份验证和授权”一章中的“授权方式”章节中的“选择资源访问模式”详细阐述了这些内容。

模拟的缺点包括：

更多信息

不带模拟的 Windows 身份验证

下列配置元素显示了如何在Web.config.中明确声明启用不带模拟功能的 Windows(IIS) 身份验证。

<authentication mode="Windows" />
<!-- The following setting is equivalent to having no identity element -->
<identity impersonate="false" />

可配置的安全性

当您使用不带模拟的 Windows 身份验证时，可以使用以下授权选项：

<authorization>
  <deny user="DomainName\UserName" />
  <allow roles="DomainName\WindowsGroup" />
</authorization>

程序安全性

可以使用下列编程安全选项：

PrincipalPermission permCheck = new PrincipalPermission(
                                         null, @"DomainName\WindowsGroup");
    permCheck.Demand();

[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName\WindowsGroup")]

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

何时使用

使用不带模拟的 Windows 身份验证的情况：

更多信息

使用固定标识的 Windows 身份验证

Web.config 中的 <identity> 元素支持可选的用户名和密码属性，这样，您就可以为应用程序配置特定的固定标识以进行模拟。这显示在以下配置文件片段中。

<identity impersonate="true"
          userName="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,userName"
          password="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,password" />

这个例子显示了 <identity> 元素，其中凭证在注册表中使用 aspnet_setreg.exe 工具进行加密。明文形式的 userName 和 password 属性值被指向安全的注册表项和包含加密凭证的命名值的指针所替代。有关这个工具的详细信息及下载方式，请参见 Microsoft 知识库中的文件 Q329290 “HOWTO:Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings”。

何时使用

当在运行 Windows 2000 的服务器上使用 .NET Framework 1.0 时，不建议使用固定的模拟标识。因为这需要您授予 ASP.NET 进程帐户“充当操作系统的一部分”权限，这个权限很大。 ASP.NET 进程需要这个权限，因为它使用您所提供的凭证执行 LogonUser 调用。

注 .NET 框架 1.1 版将在 Windows 2000 上提供此方案的改进版本。凭证将由 IIS 进程执行，这样 ASP.NET 就不需要“充当操作系统的一部分”权限了。

窗体身份验证

以下配置元素显示了如何在 Web.config 中以声明方式启用窗体身份验证。

<authentication mode="Forms">
  <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/">
  </forms>
</authentication>

可配置的安全性

在使用窗体身份验证时，可以使用以下授权选项：

<authorization>
<deny users="?" />
  <allow users="Mary,Bob,Joe" roles="Manager,Sales" />
</authorization>

<authorization>
  <deny users="[email protected]" />
  <allow roles ="CN=Smith James,CN=FTE_northamerica,CN=Users,
                DC=domain,DC=corp,DC=yourCompany,DC=com" />
</authorization>

程序安全性

可以使用下列编程安全选项：

PrincipalPermission permCheck = new PrincipalPermission(
                                         null, "Manager");
    permCheck.Demand();

[PrincipalPermission(SecurityAction.Demand, 
                  Role="Manager")]

IPrincipal.IsInRole("Manager");

何时使用

窗体身份验证最适合于 Internet 应用程序。如果出现以下情况，则应该使用窗体身份验证：

更多信息

Passport 身份验证

以下配置元素显示了如何在 Web.config 中以声明方式启用 Passport 身份验证。

<authentication mode="Passport" />

何时使用

如果应用程序用户没有 Windows 帐户，并且您希望实现单次登录解决方案，则应该在 Internet 上使用 Passport 身份验证。如果用户以前使用 Passport 帐户在参与的 Passport 站点进行登录，则不必登录到使用 Passport 身份验证配置的站点。

返回页首

配置安全性

本节说明配置 ASP.NET Web 应用程序安全性所需的实际步骤。图 3 总结了这些情况。

图 3. 配置 ASP.NET 应用程序安全性

配置 IIS 设置

要配置 IIS 安全性，您必须执行以下步骤：

配置 ASP.NET 设置

应用程序级别配置设置保存在 Web.config 文件中，这些文件位于应用程序的虚拟根目录或者（可选）其他子文件夹中（这些设置有时可以覆盖父文件夹设置）。

<authentication mode="Windows|Forms|Passport|None" />

<identity impersonate="true" />

<authorization>
  <allow users="DomainName\Bob, DomainName\Mary" />
  <deny users="*" />
</authorization>

URL 授权注意事项

在配置 URL 授权时，请注意以下几点：

<location path="page.aspx" />
  <authorization>
    <allow users="DomainName\Bob, DomainName\Mary" />
    <deny users="*" />
  </authorization>
</location>

URL 授权示例

以下列表列出了一些典型 URL 授权示例的语法：

<deny users="?" />

<deny users="*"/>

<deny roles="Manager"/>

<configuration>
  <system.web>
      <authentication mode="Forms">
        <forms name=".ASPXUSERDEMO" 
               loginUrl="login.aspx" 
               protection="All" timeout="60" />
      </authentication>
      <authorization>
        <deny users="[email protected]" />
        <deny users="?" />
      </authorization>
  </system.web>
</configuration>

保护资源

锁定配置设置

配置设置是分层的。子目录中的 Web.config 文件设置覆盖父目录中的 Web.config 设置。另外，Web.config 设置覆盖 Machine.config 设置。

通过将 <location> 元素与 allowOverride 属性一起使用，可以锁定配置设置以防止它们被低级别的设置覆盖。例如：

<location path="somepath" allowOverride="false" />
 . . . arbitrary configuration settings . . .
</location>

请注意：路径可以指 Web 站点或虚拟目录，并且它适用于指定的目录和所有子目录。如果将 allowOverride 设置为 false，则可以防止任何低级别的配置文件覆盖 <location> 元素中指定的位置。锁定配置设置的功能适用于所有设置类型，而不仅限于安全设置（如身份验证模式）。

在 machine.config 的上下文中，路径必须为全资格的，并且包含 Web 站点、虚拟目录名称和（可选）一个子目录和文件名。例如：

<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
 . . .
</location>

在 Web.config 的上下文中，路径只与应用程序的虚拟目录有关。例如：

<location path="SubDirName/PageName.aspx" >
. . .
</location>

禁止下载文件

可以使用 HttpForbiddenHandler 类禁止通过 Web 下载某些文件类型。该类由 ASP.NET 在内部使用以禁止下载某些系统级文件（例如，包括 Web.config 在内的配置文件）。有关以这种方式进行限制的文件类型的完整列表，请参见 machine.config 中的 <httpHandlers> 部分。

对于应用程序在内部使用但不能进行下载的文件，应考虑使用 HttpForbiddenHandler。

注 还必须使用 Windows ACL 来保护文件，控制哪些用户在登录到 Web 服务器上时可以访问这些文件。

使用 HttpForbiddenHandler 禁止下载特定的文件类型

<httpHandlers>
  <add verb="*" path="*.abc" 
    type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>

安全通信

结合使用 SSL 和 Internet 协议安全 (IPSec) 以保护通信链路。

更多信息

返回页首

编程安全性

在确定 Web 应用程序可配置的安全设置后，您需要以编程方式进一步改进和优化应用程序的授权策略。这包括在程序集中使用声明性的 .NET 属性，以及在代码中执行命令性的授权检查。

本节重点介绍在 ASP.NET Web 应用程序中执行授权所需的主要编程步骤。

授权模式

下面总结了在 Web 应用程序中对用户进行授权的基本模式：

重要 如果配置了 Windows 身份验证，则 ASP.NET 自动执行步骤 1 到 5。对于其他身份验证机制（窗体、Passport 和自定义方法），您必须编写代码以执行这些步骤（如下所示）。

检索凭证

首先，必须从用户检索一组凭证（用户名和密码）。如果应用程序没有使用 Windows 身份验证，则需要确保使用 SSL 在网络上正确保护明文凭证。

检验凭证

如果配置了 Windows 身份验证，则操作系统的基本服务就会自动对凭证进行检验。

如果使用其他身份验证机制，则必须编写代码以根据数据存储（如 SQL Server 数据库或 Active Directory）对凭证进行检验。

有关如何将用户凭证安全地存储在 SQL Server 数据库中的详细信息，请参见“数据访问安全性”一章中的“对数据库进行用户身份验证”。

将用户放到角色中

用户数据存储还应包含每个用户的角色列表。必须编写代码以检索已检验用户的角色列表。

创建一个 IPrincipal 对象

授权是针对已验证用户进行的，这些用户的标识和角色列表保存在 IPrincipal 对象中（该对象在当前 Web 请求的上下文中传递）。

如果配置了 Windows 身份验证，则 ASP.NET 会自动构造 WindowsPrincipal 对象。该对象包含已验证用户的标识以及角色列表（它等同于用户所属的 Windows 组列表）。

如果使用的是窗体、Passport 或自定义身份验证，则必须在 Global.asax 的 Application_AuthenticateRequest 事件处理程序中编写代码以创建 IPrincipal 对象。GenericPrincipal 类是由 .NET 框架提供的，在大多数情况下应该使用此类。

将 IPrincipal 对象放到当前 HTTP 上下文中

将 IPrincipal 对象附加到当前 HTTP 上下文中（使用 HttpContext.User 变量）。如果使用 Windows 身份验证，则 ASP.NET 自动完成此任务。否则，您必须手动附加该对象。

基于用户标识和／或角色成员身份进行授权

如果应用程序需要更细分的授权逻辑，请在代码中以声明方式（获取类或方法级授权）或命令性方式使用 .NET 角色。

可以使用声明性或命令性主体权限要求（使用 PrincipalPermission 类），也 可以通过调用 IPrincipal.IsInRole() 方法执行明确的角色检查。

以下示例采用 Windows 身份验证并显示了声明性主体权限要求。仅当已验证用户是 Manager Windows 组的成员时，才执行该属性后面的方法。如果调用者不是该组的成员，就会发生 SecurityException。

[PrincipalPermission(SecurityAction.Demand, 
                     Role=@"DomainName\Manager")]
public void SomeMethod()
{
}

以下示例显示代码中的明确角色检查。该示例采用 Windows 身份验证。如果使用非 Windows 身份验证机制，则代码基本上是一样的。只是将 User 对象转换成 WindowsPrincipal 对象，而不是 GenericPrincipal 对象。

// Extract the authenticated user from the current HTTP context.
// The User variable is equivalent to HttpContext.Current.User if you are using // an .aspx or .asmx page
WindowsPrincipal authenticatedUser = User as WindowsPrincipal;
if (null != authenticatedUser)
{
  // Note: To retrieve the authenticated user's username, use the 
  // following line of code
  // string username = authenticatedUser.Identity.Name;

  // Perform a role check
  if (authenticatedUser.IsInRole(@"DomainName\Manager") )
  {
    // User is authorized to perform manager functionality
  }
}
else
{
  // User is not authorized to perform manager functionality
}

更多信息

有关以上窗体身份验证模式的实现实现，请参见本章后面的“窗体身份验证”部分。

创建自定义的 IPrincipal 类

当您使用非 Windows 身份验证机制时，大多数情况下应使用 .NET 框架提供的 GenericPrincipal 类。它使用 IPrincipal.IsInRole 方法提供角色检查。

有时，您可能需要实现自己的 IPrincipal 类。实现您自己的 IPrincipal 的原因有：

CustomPrincipal.IsInAllRoles( "Role", "Role2", "Role3" )
CustomPrincipal.IsInAnyRole( "Role1", "Role2", "Role3" )

string[] roles = CustomPrincipal.Roles;

CustomPrincipal.IsInHigherRole("Manager");
CustomPrincipal.IsInLowerRole("Manager");

CustomIdentity id = CustomPrincipal.Identity;
X509ClientCertificate cert = id.ClientCertificate;

更多信息

有关创建您自己的 IPrincipal 类的详细信息，请参见“How To Implement IPrincipal”。

返回页首

Windows 身份验证

如果应用程序用户使用可由服务器进行身份验证的 Windows 帐户（例如，在 Intranet 方案中），请使用 Windows 身份验证。

如果将 ASP.NET 配置为使用 Windows 身份验证，则 IIS 使用配置的 IIS 身份验证机制执行用户身份验证。图 4 显示了这种情况。

图 4. ASP.NET Windows 身份验证使用 IIS 验证调用者的身份

已验证调用方（如果将 IIS 配置为使用匿名身份验证，则它可能是匿名 Internet 用户帐户）的访问令牌可供 ASP.NET 应用程序使用。请注意以下方面：

标识已验证身份的用户

ASP.NET 将 WindowsPrincipal 对象与当前的 Web 请求关联起来。这包含已验证身份的 Windows 用户的标识以及该用户所属的角色列表。在 Windows 身份验证中，角色列表是由用户所属的 Windows 组集组成的。

以下代码显示如何获取已验证 Windows 用户的标识，以及如何执行简单的角色授权测试。

WindowsPrincipal user = User as WindowsPrincipal;
if (null != user)
{
  string username = user.Identity.Name;
  // Perform a role check
  if ( user.IsInRole(@"DomainName\Manager") )
  {
    // User is authorized to perform manager functionality
  }
}
else
{
  // Throw security exception as we don't have a WindowsPrincipal
}  

返回页首

窗体身份验证

当使用窗体身份验证时，如果未验证身份的用户试图访问受保护的文件或资源（其中，URL 授权拒绝用户访问），该用户所触发的事件顺序如图 5 所示。

图 5. 窗体身份验证的事件顺序

以下描述图 5 所示的事件顺序：

窗体身份验证的开发步骤

以下列表重点介绍实现窗体身份验证时必须执行的主要步骤：

将 IIS 配置为使用匿名访问

必须在 IIS 中将应用程序的虚拟目录配置为使用匿名访问。

将 IIS 配置为使用匿名访问的操作步骤

将 ASP.NET 配置为使用窗体身份验证

下面显示一个配置示例。

<authentication mode="Forms">
  <forms name="MyAppFormsAuth" 
       loginUrl="login.aspx" 
       protection="Encryption"
       timeout="20" 
       path="/" >
  </forms>
</authentication>

创建登录 Web 窗体并验证提供的凭证

根据 SQL Server 数据库或 Active Directory 检验凭证。

更多信息

从自定义数据存储中检索角色列表

从 SQL Server 数据库表中获取角色，或从在 Active Directory 内配置的组／分发列表中获取角色。详细信息请参考前面的资源。

创建窗体身份验证票证

在票证中存储检索到的角色。以下代码演示了此过程。

// This event handler executes when the user clicks the Logon button
// having supplied a set of credentials
private void Logon_Click(object sender, System.EventArgs e)
{
  // Validate credentials against either a SQL Server database
  // or Active Directory
  bool isAuthenticated = IsAuthenticated( txtUserName.Text, 
                                          txtPassword.Text );
  if (isAuthenticated == true )
  {
    // Retrieve the set of roles for this user from the SQL Server
    // database or Active Directory. The roles are returned as a
    // string that contains pipe separated role names
    // for example "Manager|Employee|Sales|"
    // This makes it easy to store them in the authentication ticket

    string roles = RetrieveRoles( txtUserName.Text, txtPassword.Text );

    // Create the authentication ticket and store the roles in the
    // custom UserData property of the authentication ticket
    FormsAuthenticationTicket authTicket = new 
       FormsAuthenticationTicket(
                    1,                          // version
                    txtUserName.Text,           // user name
                    DateTime.Now,               // creation
                    DateTime.Now.AddMinutes(20),// Expiration
                    false,                      // Persistent
                    roles );                    // User data
     // Encrypt the ticket.
     string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
     // Create a cookie and add the encrypted ticket to the 
     // cookie as data.
     HttpCookie authCookie = 
               new HttpCookie(FormsAuthentication.FormsCookieName,
                              encryptedTicket);

     // Add the cookie to the outgoing cookies collection. 
     Response.Cookies.Add(authCookie); 
     // Redirect the user to the originally requested page
     Response.Redirect( FormsAuthentication.GetRedirectUrl(
                        txtUserName.Text, 
                        false ));
  }
}

创建一个 IPrincipal 对象

在位于 Global.asax 的 Application_AuthenticationRequest 事件处理程序中创建 IPrincipal 对象。除非您需要基于角色的扩展功能，否则，请使用 GenericPrincipal 类。在本范例中创建一个实现 IPrincipal 的自定义类。

将 IPrincipal 对象放到当前的 HTTP 上下文中

GenericPrincipal 对象的创建过程如下所示。

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
  // Extract the forms authentication cookie
  string cookieName = FormsAuthentication.FormsCookieName;
  HttpCookie authCookie = Context.Request.Cookies[cookieName];
  if(null == authCookie)
  {
    // There is no authentication cookie.
    return;
  } 
  FormsAuthenticationTicket authTicket = null;
  try
  {
    authTicket = FormsAuthentication.Decrypt(authCookie.Value);
  }
  catch(Exception ex)
  {
    // Log exception details (omitted for simplicity)
    return;
  }
  if (null == authTicket)
  {
    // Cookie failed to decrypt.
    return; 
  }
  // When the ticket was created, the UserData property was assigned a
  // pipe delimited string of role names.
  string[] roles = authTicket.UserData.Split(new char[]{'|'});

  // Create an Identity object
  FormsIdentity id = new FormsIdentity( authTicket ); 
  // This principal will flow throughout the request.
  GenericPrincipal principal = new GenericPrincipal(id, roles);
  // Attach the new principal object to the current HttpContext object
  Context.User = principal;
}
  

基于用户名或角色成员身份对用户进行授权

使用声明性主体权限要求来限制对方法的访问。使用命令性主体权限要求和／或明确的角色检查 (IPrincipal.IsInRole) 在方法中执行细分的授权。

窗体实现原则

更多信息

承载多个使用窗体身份验证的应用程序

如果在同一台 Web 服务器上承载多个使用窗体身份验证的 Web 应用程序，则在某个应用程序中已验证身份的用户可以请求另一个应用程序，而无需重定向到该应用程序的登录页。第二个应用程序中的 URL 授权规则可能会拒绝该用户的访问，而不会提供使用登录窗体提供登录凭证的机会。

这种情况只在以下情况下会发生：多个应用程序的 <forms> 元素的名称和路径属性相同，而且每个应用程序在 Web.config 中使用相同的 <machineKey> 元素。

更多信息

有关此问题的详细信息以及解决方法，请参见以下知识库文章：

返回页首

无 Cookie 窗体身份验证

如果您需要无 Cookie 窗体身份验证解决方案，请考虑使用 Microsoft Mobile Internet Toolkit 所使用的方法。移动窗体身份验证建立在窗体身份验证之上，但使用查询字符串来传递身份验证票证，而不是使用 Cookie。

返回页首

更多信息

有关移动窗体身份验证的详细信息，请参见 Microsoft 知识库文章 Q311568“INFO：How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit”。

返回页首

Passport 身份验证

如果应用程序使用 Passport 帐户，而且您要在其他支持 Passport 的站点上实现单次登录解决方案，则应使用 Passport 身份验证。

当将 ASP.NET 配置为使用 Passport 身份验证时，就会提示用户登录并将该用户重定向到 Passport 站点。成功检验凭证之后，用户就会被重定向回您的站点。

将 ASP.NET 配置为使用 Passport 身份验证

要将 ASP.NET 配置为使用 Passport 身份验证，请使用以下 Web.config 设置。

<authentication mode="Passport">
  <passport redirectUrl="internal" />
</authentication>
<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

将 Passport 标识映射到 Global.asax 中的角色

要将 Passport 标识映射到角色，请按如下所示在 Global.asax 中实现 PassportAuthentication_OnAuthentication 事件处理程序。

void PassportAuthentication_OnAuthenticate(Object sender, 
                                           PassportAuthenticationEventArgs e)
{
  if(e.Identity.Name == "0000000000000001")
  {
    string[] roles = new String[]{"Developer", "Admin", "Tester"};
    Context.User = new GenericPrincipal(e.Identity, roles);
  }
}
  

测试角色成员身份

以下代码片段显示了如何在 aspx 页中检索已验证身份的 Passport 标识和检查角色成员身份。

PassportIdentity passportId = Context.User.Identity as PassportIdentity;
if (null == passportId)
{
  Response.Write("Not a PassportIdentity");
  return;
}
Response.Write("IsInRole: Develeoper? " + Context.User.IsInRole("Developer"));
  

返回页首

自定义身份验证

如果 .NET 框架提供的身份验证模块均不能满足您的确切身份验证需要，则可以使用自定义身份验证并实现您自己的身份验证机制。例如，您的公司可能已经制订了一个可由其他应用程序广泛使用的自定义身份验证策略。

要在 ASP.NET 中实现自定义身份验证，请执行下列操作：

<authentication mode="None" />

更多信息

有关如何实现自定义 HTTP 模块的详细信息，请参见 Microsoft 知识库文章 Q307996“HOW TO:Create an ASP.NET HTTP Module Using Visual C# .NET”。

返回页首

ASP.NET 的进程标识

使用权限最少的帐户运行 ASP.NET （具体来说就是 Aspnet_wp.exe 辅助进程）。

使用权限最少的帐户

使用权限最少的帐户可以减少与进程攻击相关的威胁。如果某个顽固的攻击者设法破坏了运行 Web 应用程序的 ASP.NET 进程，则这些应用程序可以轻易地继承和使用授予该进程帐户的特权和访问权限。配置为权限最少的帐户可以限制可能的潜在危害。

避免作为 SYSTEM 运行

不要使用高权限的 SYSTEM 帐户运行 ASP.NET，也不要授予 ASP.NET 进程帐户“充当操作系统的一部分”的权限。您可能很想使用其中的一种方法，通过代码调用 LogonUser API 以获取固定的标识（通常用于网络资源访问）。有关替代方法，请参见本章后面的“访问网络资源”。

不要以 SYSTEM 的身份运行或不授予“充当操作系统的一部分”权限的原因包括：

更多信息

有关“充当操作系统的一部分”权限的详细信息，请参见 1999 年 8 月 Microsoft Systems Journal Security Briefs 专栏文章。

域控制器和 ASP.NET 进程帐户

一般情况下，不建议在域控制器上运行 Web 服务器，因为对服务器的攻击就是对域的攻击。正如 Microsoft 知识库文章 Q315158“BUG:ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller”中所概述的，如果需要在域控制器上运行 ASP.NET，则需要授予 ASP.NET 进程帐户相应的权限。

使用默认的 ASPNET 帐户

已将本地 ASPNET 帐户明确配置为使用尽可能最少的权限集运行 ASP.NET Web 应用程序。如果可能，尽量使用 ASPNET。

和 Machine.config 中的 <processModel> 元素所配置的一样，默认情况下，ASP.NET Web 应用程序使用此帐户运行。

<processModel userName="machine" password="AutoGenerate" />

注machine 用户名表示 ASPNET 帐户。当安装 .NET 框架时，使用加密型密码创建该帐户。除了在安全帐户管理器 (SAM) 数据库中进行配置外，密码还存储在本地计算机上的本地系统授权 (LSA) 中。当系统启动 ASP.NET 辅助进程时，系统就会从 LSA 中检索密码。

如果应用程序访问网络资源，则 ASPNET 帐户必须能够由远程计算机验证身份。您有两种选择：

元素

Machine.config 文件中的 <processModel> 元素包含 userName 和 password 属性，这些属性指定应该使用哪些帐户来运行 ASP.NET 辅助进程 (Aspnet_wp.exe)。

注与传统 ASP 应用程序的运行方式相比，ASP.NET 代码从不在 dllhost.exe 进程中运行或作为 IWAM_MACHINENAME 帐户运行，即使在 IIS 中将应用程序保护级别设置为“高（独立）”。

发送到 IIS 的 ASP.NET 请求被直接路由到 ASP.NET 辅助进程 (Aspnet_wp.exe)。ASP.NET ISAPI 扩展 Aspnet_isapi.dll 在 IIS (Inetinfo.exe) 进程地址空间中运行。（这是由 InProcessIsapiApps 元数据库项控制的；不要修改该元数据库项）。ISAPI 扩展负责将请求路由到 ASP.NET 辅助进程。然后，ASP.NET 应用程序在 ASP.NET 辅助进程中运行，其中应用程序域提供隔离边界。

在 IIS 6 中，您可以通过配置应用程序池来隔离 ASP.NET 应用程序，其中每个池都有自己的应用程序实例。

您可以使用多种方法来配置 <processModel> userName 属性。例如：

存储加密的凭证

如果您使用自定义凭证，请使用 aspnet_setreg.exe 工具在注册表中存储加密的凭证。避免在 machine.config 中存储明文凭证。

有关这个工具的详细信息及下载，请参见 Microsoft 知识库文章 Q329290“HOWTO:Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings”。

以下示例显示了这个工具使用前和使用后 userName 和 password 属性的格式。请注意该属性值如何指向安全的注册表项和包含加密凭证的命名值。

<!-- Before -->
<processModel userName="SomeCustomAccount"
              password="ClearTextPassword" . . ./>

<!-- After -->
<processModel
        userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,userName"
        password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,password" . . ./>

更多信息

返回页首

模拟

随时 FileAuthorizationModule 的引入以及网关守卫和信任边界的有效使用，现在看来，模拟技术在 ASP.NET 中是弊大于利。

模拟和本地资源

如果使用模拟并且从 Web 应用程序代码访问本地资源，则必须配置附加到每个受保护资源的 ACL，以包含一个至少授予已验证用户“读”访问权限的 ACE。

更好的方法是避免使用模拟，将权限授予 ASP.NET 进程帐户，并使用 URL 授权、文件授权以及基于角色的声明性和命令性检查组合。

模拟和远程资源

如果您使用模拟，然后从 Web 应用程序代码访问远程资源，则除非使用基本身份验证、窗体身份验证或 Kerberos 身份验证，否则访问将会失败。如果您使用 Kerberos 身份验证，则必须将用户帐户相应地配置为使用委派。在 Active Directory 中，必须将它们标记为“敏感帐户，不能被委派”。

更多信息

有关如何配置 Kerberos 委派的详细信息，请参见：

模拟和线程

如果某个正在模拟的线程创建了一个新线程，则该新线程将继承 ASP.NET 进程帐户的安全性上下文，而不是继承被模拟帐户的安全性上下文。

返回页首

访问系统资源

默认情况下，ASP.NET 不执行模拟。因此，如果 Web 应用程序访问本地系统资源，则它使用与 Aspnet_wp.exe 辅助进程相关联的安全性上下文完成此任务。安全性上下文是由运行辅助进程使用的帐户决定的。

访问事件日志

权限最少的帐户拥有足够的权限，能够使用现有事件源将记录写入事件日志中。但是，它们没有足够的权限来创建新的事件源，这要求在下面的注册表配置单元底下设置一个新项。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>

为了避免出现这种问题，请在安装时创建由应用程序使用的事件源（如果可以使用管理员权限的话）。一个好的办法是使用可由 Windows Installer（如果使用 .msi 部署的话）或 InstallUtil.exe 系统实用程序（如果没有使用 .msi 部署）实例化的 .NET 安装程序类。

如果在安装时无法创建事件源，则必须将权限添加到以下注册表项中，并授予某个被模拟帐户的 ASP.NET 进程帐户访问权限（如果应用程序使用模拟的话）。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog 

帐户必须拥有以下最少权限：

在将权限应用于注册表后，可以使用以下代码从 ASP.NET 写入应用程序事件日志：

string source = "Your Application Source";
string logToWriteTo = "Application";
string eventText = "Sample Event";

if (!EventLog.SourceExists(source))
{
  EventLog.CreateEventSource(source, logToWriteTo);
}
EventLog.WriteEntry(source, eventText, EventLogEntryType.Warning, 234);
  

访问注册表

应用程序访问的任何注册表项要求在 ACL 中使用 ACE，以便至少授予 ASP.NET 进程帐户“读”访问权限。

更多信息

有关安装程序类和InstallUtil.exe 实用工具的详细信息，请参见 MSDN 上的 .NET 框架 SDK 的“.NET 框架工具”部分。

返回页首

访问 COM 对象

在传统 ASP 中，使用单线程单元 (STA) 线程池中的线程来处理请求。在 ASP.NET 中，使用多线程单元 (MTA) 线程池中的线程来处理请求。这会给调用单元模型对象的 ASP.NET Web 应用程序造成不利影响。

单元模型对象

当 ASP.NET Web 应用程序调用单元模型对象（如 Visual Basic 6 COM 对象）时，需要注意以下两个问题：

<%@ Page Language="C#" AspCompat="True" %>

需要 AspCompat 指令

默认情况下，ASP.NET 使用 MTA 线程处理请求。在从 ASP.NET 调用单元模型对象时，将会导致线程切换，这是因为 MTA 线程不能直接访问单元模型对象（COM 将使用 STA 线程）。

如果指定 AspCompat，则会由 STA 线程处理页面。这可以避免从 MTA 到 STA 的线程切换。如果 Web 应用程序使用模拟功能，从安全角度讲这是非常重要的，因为线程切换将会导致丢失模拟令牌。新线程将没有关联的模拟令牌。

ASP.NET Web 服务不支持 AspCompat 指令。这意味着，在从 Web 服务代码调用单元模型对象时，将会发生线程切换并且丢失线程模拟令牌。这通常导致出现“拒绝访问”异常错误。

更多信息

不要在特定 Page 事件以外创建 COM 对象

不要在特定 Page 事件处理程序以外创建 COM 对象。以下代码片段阐释了不要执行哪些操作。

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
  // COM object created outside of Page events
  YourComObject obj = new apartmentObject();
  public void Page_Load()
  {
    obj.Foo()
  }
</script>

在使用单元模型对象时，一定要在特定 Page 事件（例如 Page_Load）中创建对象（如下所示）。

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
public void Page_Load()
{
  YourComObject obj  = new apartmentObject();
  obj.Foo()
}
</script>

更多信息

有关详细信息，请参见 Microsoft 知识库文章 Q308095“PRB:Creating STA Components in the Constructor in ASP.NET ASPCOMPAT Mode Negatively Impacts Performance”。

COM+ 中的 C# 和 VB .NET 对象

Microsoft C#_ 开发工具和 Microsoft Visual Basic_ .NET 开发系统支持所有的线程模拟（自由线程、中性、两者和单元）。默认情况下，将 COM+ 中驻留的 C# 和 Visual Basic .NET 对象标记为“两者”。因此，当 ASP.NET 调用它们时，可以直接进行访问，而不会发生线程切换。

返回页首

访问网络资源

应用程序可能需要访问网络资源。一定要能够标识以下内容：

可以使用以下任一种方法，从 ASP.NET 应用程序中访问远程资源：

使用 ASP.NET 进程标识

如果没有将应用程序配置为使用模拟，在应用程序试图访问远程资源时，ASP.NET 进程标识就会提供默认标识。如果使用 ASP.NET 进程帐户访问远程资源，您有三种选择：

更多信息

有关配置 ASP.NET 进程帐户的详细信息，请参见“How To Create a Custom Account to Run ASP.NET”。

使用服务组件

可以使用配置为以固定标识运行的进程外服务组件来访问网络资源。图 6 显示了这种方式。

图 6. 使用进程外服务组件为网络资源访问提供固定标识

使用进程外服务组件（在 Enterprise Services 服务器应用程序中）具有以下优点：

使用匿名 Internet 用户帐户

如果将 IIS 配置为使用匿名身份验证，则可以使用匿名 Internet 用户帐户访问网络资源。如果以下任一种情况属实，就会发生这种情况：

使用匿名帐户访问远程资源

<identity impersonate="true" />

重要如果您模拟匿名帐户（例如，IUSR_MACHINE），则必须禁止该帐户访问资源（使用进行适当配置的 ACL）。对于应用程序需要访问的资源，必须（至少）授予匿名帐户“读”访问权限。应该拒绝匿名帐户访问所有其他资源。

承载多个 Web 应用程序

对于 Web 站点中的每一个虚拟根目录，可以使用一个单独的匿名 Internet 用户帐户。在承载环境中，这允许您分别授权、跟踪和审核来自不同 Web 应用程序的请求。图 7 显示了这种方式。

图 7. 为每个应用程序模拟不同的匿名 Internet 用户帐户 (v-dir)

为特定的虚拟目录配置匿名 Internet 用户帐户

使用 LogonUser 并模拟特定的 Windows 标识

可以使用以下方法模拟特定的标识：在 Web.config 中的 <identity> 元素上配置用户名和密码属性，或者在应用程序代码中调用 Win32_ LogonUser API。

重要 正如本章前面所提到的，当在 Windows 2000 服务器上使用 .NET Framework 1.0 时，不推荐使用 LogonUser 和固定的模拟标识，因为它强制给 ASP.NET 进程帐户授予“充当操作系统的一部分”权限。

Microsoft Windows .NET Server 2003 将取消这一限制。另外，在 Windows 2000 中，.NET Framework 1.1 版会为此方案提供一个增强功能。登录会由 IIS 进程执行，因此 ASP.NET 不需要“充当操作系统的一部分”权限。

使用原调用者

要使用原调用者的标识访问远程资源，您必须能够将调用者的安全性上下文从 Web 服务器委派到远程计算机。

可扩展性警告 如果使用原调用者的模拟标识访问应用程序的数据服务层，则会严重影响应用程序的可扩展性，这是因为数据库连接池的效率非常低。对于每个用户而言，数据库连接的安全性上下文是不同的。

以下身份验证方案支持委派：

使用原调用者访问远程资源

<authentication mode="Window" />
<identity impersonate="true" />

更多信息

访问 UNC 文件共享上的文件

如果应用程序需要使用 ASP.NET 访问统一命名约定 (UNC) 共享上的文件，则一定要添加共享文件夹的 NTFS 权限。您还需要设置共享的权限，以便授予 ASP.NET 进程帐户或模拟的标识至少“读”访问权限（如果将应用程序配置为使用模拟的话）。

访问非 Windows 网络资源

如果应用程序需要访问非 Windows 资源（例如位于非 Windows 平台上的数据库或大型机应用程序），则需要考虑以下问题：

如果资源需要能够对原调用者进行身份验证（并且不能选用 Windows 身份验证），则可以选择以下方法：

返回页首

安全通信

使用 SSL 保护浏览器和 Web 服务器之间通信链路的安全。SSL 提供消息机密性和消息完整性。使用 SSL 和／或 IPSec 提供从 Web 服务器到应用程序服务器或数据库服务器的安全通道。

更多信息

有关安全通信的详细信息，请参见“Secure Communication”一章。

返回页首

存储机密

Web 应用程序通常需要存储机密。需要妥善保管这些机密，以防止不道德的管理员和有恶意的 Web 用户进行访问，例如：

机密的典型示例包括：

<identity impersonate="true" userName="bob" password="inClearText"/>

<process userName="cUsTuMUzerName" password="kUsTumPazzWerD" >

<sessionState … stateConnectionString="tcpip=127.0.0.1:42424"
                sqlConnectionString="data source=127.0.0.1;
                user id=UserName;password=MyPassword" />

在 ASP.NET 中存储机密的选项

.NET Web 应用程序开发人员可以使用多种方法来存储机密。它们是：

更多信息

有关详细信息，请参见 MSDN 上 Platform SDK 中的加密技术、CryptoAPI 和 CAPICOM 条目。

考虑将机密存储在单独逻辑卷上的文件中

考虑将 Web 应用程序目录安装到操作系统所在卷以外的逻辑卷上（例如 E: 而不是 C:）。这意味着 Machine.config（位于 C:\WINNT\Microsoft.NET 下）和其他可能包含机密的文件（例如通用数据链接 (UDL) 文件）都位于 Web 应用程序目录以外的逻辑卷上。

此方法的基本原理是防止出现可能的文件规范化和目录遍历错误，因为：

返回页首

保护会话和视图状态

Web 应用程序必须管理各种类型的状态，其中包括视图状态和会话状态。本节讨论 ASP.NET Web 应用程序的安全状态管理。

保护视图状态

如果 ASP.NET Web 应用程序使用视图状态：

<% @ Page enableViewStateMac=true >
  

保护 Cookies

在传递过程中，应该使用 SSL 保护包含身份验证或授权数据或其他机密数据的 Cookie。对于窗体身份验证，可以使用 FormsAuthentication.Encrypt 方法加密以 Cookie 形式在客户端和服务器之间传递的身份验证票证。

保护 SQL 会话状态

默认（进程内） ASP.NET 会话状态处理程序会受到某些限制。例如，它不能在网络场中的其他计算机上运行。为了克服此限制，ASP.NET 允许在 SQL Server 数据库中存储会话状态。

可以在 Machine.config 或 Web.config 中配置 SQL 会话状态。machine.config 的默认设置如下所示。

<sessionState mode="InProc" 
              stateConnectionString="tcpip=127.0.0.1:42424" 
              stateNetworkTimeout="10"
              sqlConnectionString="data source=127.0.0.1;user id=sa;password="
              cookieless="false" timeout="20"/>

默认情况下， SQL 脚本 InstallSqlState.sql （用于生成 SQL 会话状态使用的数据库）安装在以下位置：

C:\WINNT\Microsoft.NET\Framework\v1.0.3705

在使用 SQL 会话状态时，需要考虑以下两个问题。

保护数据库连接字符串

如果使用 SQL 身份验证连接到服务器，则连接字符串在包含用户名和密码的 sqlConnectionString 属性中指定。使用 aspnet_setreg.exe 实用工具在注册表中存储加密的连接字符串。以下示例显示了使用 aspnet_setreg.exe 前后的 <sessionState> 元素。

<!-- Before -->
<sessionState 
    mode="SQLServer", 
    sqlConnectionString="data source=Server;user id=userID;password=pwd" . . . />
<!-- After -->
<sessionState mode="SQLServer"
              sqlConnectionString="registry:HKLM\SOFTWARE\YourSecureApp\
              sessionState\ASPNET_SETREG,sqlConnectionString" />

注 如果您使用 ASP.NET 状态服务，也可以使用 aspnet_setreg.exe 来加密 stateConnectionString 属性。

如果可能，应该对 SQL Server 状态数据库使用 Windows 身份验证。这将带来其他一些优点：连接字符串不包含凭证，凭证不通常网络传递到数据库服务器。

要使用 Windows 身份验证，可以使用 ASP.NET 进程标识（通常是 ASPNET）

sqlConnectionString="server=127.0.0.1;
                     database=StateDatabase;
                     Integrated Security=SSPI;"

在网络上保护会话状态

在通过网络将会话状态传递到 SQL Server 数据库时，可能需要对会话状态进行保护。这取决于承载 Web 服务器和数据服务器的网络的安全性。如果已在受信任环境中对数据库进行物理保护，则可能不必采取这一额外的安全措施。

可以使用 IPSec 保护 Web 服务器和 SQL Server 之间的所有 IP 通信，或者使用 SSL 保护到 SQL Server 的链路。通过使用此方法，您可以选择只加密用于会话状态的连接，而不是在计算机之间进行的所有通信。

更多信息

返回页首

网络场注意事项

在网络场方案中，不能保证来自同一个客户端的后续请求由同一个 Web 服务器提供服务。对于状态管理和任何取决于 Machine.config 中 <machineKey> 元素所保存的属性的加密而言，这会产生不利影响。

会话状态

默认 ASP.NET 进程内会话状态处理（它镜像以前的 ASP 功能）产生服务器关系，并且不能在网络场方案中使用。对于网络场部署，必须在进程外将会话状态存储到 ASP.NET 状态服务或 SQL Server 数据库中（如前所述）。

注 不能依赖应用程序状态来保存网络场（将 Web 应用程序配置为在多台服务器上运行）或网络园（将 Web 应用程序配置为在多个处理器上运行）方案中的全局计数器或惟一值，因为在进程或计算机之间不能共享应用程序状态。

DPAPI

DPAPI 能够与机器存储或用户存储（需要一个已加载的用户配置文件）配合使用。如果您将 DPAPI 和机器存储一起使用，那么加密字符串是给定计算机所特有的，因此您必须在每台计算机上生成加密数据。不要在网络场或群集中的计算机之间复制加密数据。

如果将 DPAPI 和用户存储一起使用，则可以用一个漫游的用户配置文件在任何一台计算机上解密数据。

更多信息

有关 DPAPI 的详细信息，请参见“数据访问安全性”一章。

在网络场中使用窗体身份验证

如果使用窗体身份验证，则网络场中的所有服务器必须共享一个通用机密密钥，此密钥用于身份验证票证的加密、解密和验证。

机密密钥保存位于 Machine.config 的 <machineKey> 元素中。默认设置如下所示。

<machineKey validationKey="AutoGenerate" 
            decryptionKey="AutoGenerate" 
            validation="SHA1"/> 

此设置导致每台机器生成一个不同的检验和解密密钥。必须更改 <machineKey> 元素，并将通用密钥值放在网络场中的所有服务器上。

元素

可以使用 Machine.config 中的 <machineKey> 元素，配置用于加密和解密窗体身份验证 Cookie 数据和视图状态的密钥。

在调用 FormsAuthentication.Encrypt 或 FormsAuthentication.Decrypt 方法以及创建或检索视图状态时，将参考 <machineKey> 元素中的值。

<machineKey validationKey="autogenerate|value"
            decryptionKey="autogenerate|value"
            validation="SHA1|MD5|3DES" />

validationKey 属性

validationKey 属性值用于创建和检验视图状态和窗体身份验证票证的 MAC 代码。此检验属性表明在执行 MAC 生成时使用哪种算法。请注意以下方面：

decryptionKey 属性

decryptionKey 属性值用于加密和解密窗体身份验证票证和视图状态。可以使用 DES 或 Triple DES (3DES) 算法。具体的算法取决于服务器上是否安装了 Windows 2000 高度加密包。如果安装了该程序包，则使用 3DES，否则使用 DES。请注意以下方面：

Validation 属性

此属性规定检验、加密和解密时使用哪种算法。它可以采用 SHA1、MD5 或 3DES 值。以下是这些值的描述：

更多信息

返回页首

小结

本章介绍了各种保护 ASP.NET Web 应用程序的技术和方法。本章提供的大多数指南和建议同样适用于开发 ASP.NET Web 服务和由 ASP.NET 驻留的 .NET Remoting 对象。概括如下：

本文地址：http://com.8s8s.com/it/it43836.htm