ASP .NET 中的身份验证：.NET 安全指导

摘要
本文讨论了设计服务器应用程序时考虑安全性的重要性。Internet Information Services 和 ASP .NET 均提供了安全模型，以便您对用户进行适当的身份验证，并在应用程序中获得正确的安全环境。

--------------------------------------------------------------------------------

目录
简介
安全性考虑
IIS 和 ASP .NET 之间的关系
身份验证方法
Web 服务的安全性
代码访问安全性
通道安全性
其他信息
附录 A

--------------------------------------------------------------------------------

简介
不论对应用程序设计者还是开发人员，安全性都是关注的主要问题。您需要保护存储敏感信息的应用程序，既要防止恶意攻击，又要防止竞争对手窃取信息或知识产权。在为您的应用程序设计安全模型时，您需要从业务角度了解安全要求，以及选定的安全模型在性能、可伸缩性和部署上所具有的含义。

--------------------------------------------------------------------------------

安全性考虑
如果您在设计服务器应用程序，那么您的设计规范应包含一个解决安全问题的部分。在应用程序的功能规范中，您应当考虑以下项目并尽可能给出解决方案：
安全目标。理解您要保护的对象并确保您可以说明它。
安全风险。理解您的应用程序的弱点。您还必须理解这些弱点对业务的潜在危害程度。
身份验证。这一过程接受用户凭据，并根据指定的颁发机构来验证凭据。用户的（或者潜在的应用程序或计算机的）标识被称为安全当事者。客户端必须提供凭据，以便服务器验证当事者的标识。确认标识后，应用程序就能授权当事者访问系统资源。本文档的下一节将讲述各种标准，它们有助于您选择恰当的身份验证机制。
权限。这一过程确定已证实的标识是否可以访问某一特定资源。
保护数据传输。在数据通过网络时对数据进行加密，可以确保数据在传输过程中不被查看和修改。您必须考虑传输过程中需要的数据加密级别。
模拟。这一机制允许服务器进程使用客户端的安全凭据来运行。当服务器模拟客户端时，服务器的所有操作均使用客户端的凭据进行。模拟不允许服务器代表客户端访问远程资源。该操作需要使用代理。
代理。和模拟一样，代理允许服务器进程使用客户端的安全凭据来运行。但是，代理的功能更加强大，它允许服务器进程以客户端方式来呼叫其他计算机。
操作系统安全性。它指建立适当的访问控制列表 (Access Control List, ACL) 和网络安全措施，以防止入侵者访问受保护的资源。您必须为适当的资源设置适当的 ACL，从而只允许相关的当事者进行访问。
保护物理访问。是指将您的服务器计算机放在一个安全的房间中。您不应忽视这个基本问题。
代码访问安全性。它允许根据代码的来源及代码标识的其他特征来确定代码的可信度。您应当了解如何创建自己的访问许可。

--------------------------------------------------------------------------------

IIS 和 ASP .NET 之间的关系
在设计应用程序时，您应理解 Internet Information Services (IIS) 身份验证和 Microsoft ASP .NET 安全结构之间的关系。这将允许您恰当地验证您的用户，并在应用程序中获得正确的安全环境。请注意，ASP .NET 应用程序的安全配置和 IIS 的安全配置是完全独立的，它们可以单独使用，也可以结合使用。
IIS 在 IIS 元数据库中维护与安全性相关的配置设置，而 ASP .NET 在 XML 配置文件中维护安全（或其他）配置设置。这一般会在安全性方面简化应用程序的部署，但应用程序采用的安全模型则需要通过配置文件 (Web.config) 正确配置 IIS 元数据库和您的 ASP .NET 应用程序。
图 1 说明了 IIS 和 ASP .NET 之间的关系。


图 1：IIS 和 ASP .NET 之间的安全性关系
ASP .NET 身份验证提供程序和 IIS 安全性
ASP .NET 通过使用身份验证提供程序来实现身份验证，身份验证提供程序是验证凭据和实现其他安全功能（例如生成 Cookie）的代码模块。ASP .NET 支持以下三种身份验证提供程序：
表单身份验证。使用该提供程序，可以使用客户端重定向将未通过身份验证的请求重定向到指定的 HTML 表单。然后，用户可以提供登录凭据，并将表单发送回服务器。如果应用程序验证了请求（使用应用程序特定的逻辑），ASP .NET 将发出一个 Cookie，其中包含凭据或用于重新申请客户标识的密钥。后续发出的请求在标头携带该 Cookie，这就意味着以后不再需要身份验证。
Passport 身份验证。这是一个由 Microsoft 提供的集中身份验证服务，它为参与的站点提供单一的登录程序和成员服务。ASP .NET 与 Microsoft Passport 软件开发包 (SDK) 相结合，为 Passport 用户提供了类似表单身份验证的功能。
Windows 身份验证。该提供程序利用了 IIS 的身份验证功能。当 IIS 完成身份验证后，ASP .NET 使用已验证标识的标记来授权访问。
要在 ASP .NET 应用程序中使用某种指定的身份验证提供程序，您必须在应用程序配置文件中创建如下项：
// web.config 文件
<authentication mode = "[Windows/Cookie/Passport/None]">
</authentication>
除身份验证外，ASP .NET 还提供了模拟机制以建立应用程序线程的安全标记。能否获得正确的标记取决于您是否恰当地配置了 IIS 身份验证、ASP .NET 身份验证提供程序和 ASP .NET 模拟设置。图 2 显示了 IIS 身份验证和 ASP .NET 提供程序之间最可能的组合。


图 2：ASP .NET 和 IIS 安全设置矩阵
使用 Windows 帐户进行身份验证
如果您计划使用 Microsoft Windows NT 域控制器或 Microsoft Windows 2000 Active Directory 帐户来进行用户身份验证，您应当结合使用 IIS 身份验证和 ASP .NET Windows 提供程序（见图 2）。使用该方法，您不必编写任何特定身份验证代码。当使用该方法验证时，ASP .NET 根据已验证用户在应用程序环境中构造并附加一个 Windows Principal 对象。这样，ASP .NET 线程就能够作为已验证用户运行，并可获得用户的组成员身份。
在某些情况下，您可能希望忽略 IIS 身份验证，而实施自定义的解决方案。使用 ASP .NET 也可以实现这一目标。例如，您可以编写自定义 ISAPI 过滤器，根据 Active Directory 检查用户凭据，并手动创建 Windows Principal 对象。除这种方法外，还有其他一些方法可以使用，但是与直接使用 .NET 提供程序相比，它们都需要编写更多的代码。
使用非 Windows 帐户进行身份验证
如果您计划在应用层进行用户身份验证，并且用户没有 Windows 帐户，则一般应将 IIS 配置为使用匿名验证。在这种配置下，请考虑以下 .NET 身份验证模块：
无：在根本不验证用户时或开发自定义验证代码时使用。
表单：在需要为用户提供登录页时使用。
Passport：在使用 Passport 服务时使用。
模拟和代理
在模拟情况下，ASP .NET 应用程序能够使用客户端标识以客户端的身份有选择地执行。模拟一般用于资源访问控制。您应仔细考虑是否需要模拟，因为它将消耗额外的服务器资源。代理是一种比模拟更强大的形式，它允许服务器进程以客户端的身份访问远程资源。
如果启用模拟，ASP .NET 将从 IIS 收到模拟标记。与传统的 Active Server Pages (ASP) 相比，使用 ASP .NET 将使您在 Web 应用程序中更广泛地控制模拟。这种控制是通过在应用程序的 Web.config 文件中指定值来实现的。
在指定所需的模拟设置时，有以下三个选项：
启用模拟。在这种情况下，ASP .NET 将模拟由 IIS 传递给它的标记，该标记可能是已验证的用户，也可能是匿名 Internet 用户帐户。
<identity impersonate="true"/>
启用模拟，使用指定的特定模拟标识。在这种情况下，ASP .NET 将模拟使用配置的标识生成的标记。此时不使用客户端标记（即使有）。
<identity impersonate="true" username="domain\user" password="pwd"/>
禁用模拟。此选项是默认设置，以便与 ASP 向后兼容。在这种情况下，ASP .NET 线程将使用应用程序辅助进程的进程标记（默认情况下为 IIS 系统帐户）来运行，而不考虑采用的是 IIS 和 ASP .NET 身份验证的何种组合。
<identity impersonate="false"/>
如果应用程序驻留在 UNC 共享中，ASP .NET 将一直模拟 IIS UNC 标记以访问该共享，除非使用了配置帐户。如果提供了显式配置的帐户，ASP .NET 将优先使用该帐户。
表 1 显示了根据三种不同的 Web.config 配置来执行请求的线程标记。请注意，IUSR_SERVER 帐户表示已配置用于匿名访问当前 URL 的帐户（即，该帐户不必是 IUSR_ 帐户）。进程帐户是应用程序辅助进程运行时使用的帐户：默认情况下，该帐户为系统帐户，除非进行专门配置。
表 1：ASP 和 IIS 配置的 ASP 线程标记


应用程序标识
建议您使用专门配置的帐户来运行 ASP .NET 应用程序辅助进程 (aspnet_wp.exe)，该帐户的权限比默认系统帐户低。主要原因有两个。第一，如果出现安全问题，入侵者没有管理权限。第二，它允许应用程序服务提供者 (ASP) 使用较低权限的帐户运行应用程序，因此寄宿的应用程序不会破坏服务器计算机的完整性或执行需要管理员权限的操作。
要使用指定帐户运行 ASP 辅助进程，需要在 \WINNT\Microsoft.NET\Framework\Version\Config 文件夹下的根配置文件 (machine.config) 中添加一个 <processModel> 元素，如下所示：
<system.web>
<processModel enable="true" username="domain\user" password="pwd"/>
</system.web>
除指定特定的用户帐户外，您还可以将 username 属性设置为两个专门识别的值“SYSTEM”和“MACHINE”之一。无论设为哪个值，密码属性必须设为“AutoGenerate”，因为不需要指定凭据。“SYSTEM”设置（默认）使用系统帐户运行辅助进程，而“MACHINE”使用名称中带前缀 ASPNET 的特殊帐户运行辅助进程。该帐户与 IWAM_MACHINENAME 帐户相同，IIS 寄放标准 ASP 应用程序时使用 IWAM_MACHINENAME 帐户来运行 dllhost.exe 的实例。ASPNET 帐户在 .NET 的安装过程中创建。
如果您使用自定义帐户，该帐户必须具有对以下目录的必要访问权限。
对 %installroot%\ASP .NET 临时文件目录具有读/写访问权限。该根目录下的子目录用于动态编译输出。
对 %temp% 目录具有读/写访问权限。在动态编译过程中，编译器将使用该目录。
对应用程序目录具有读访问权限。
对 %installroot% 层次结构具有读访问权限，以允许访问系统程序集。
请注意，相关的 ACE 是在安装 ASPNET 帐户的过程中定义的。
如果您使用专门配置的进程帐户，您应了解它对使用模拟的限制。虽然您可以继续模拟客户端标识，但您不能使用模拟的扩展形式（其指定的模拟帐户已在应用程序的 Web.config 文件中定义）。这是因为该选项要求辅助进程具有 SE_TCB_NAME (“作为操作系统的一部分运行”) 权限，而权限较低的进程标识一般不具有此权限。针对每个请求的模拟仍然有效，因为 IIS 创建了登录会话，并将模拟标记直接传递给辅助进程。请注意，此限制仅适用于 Windows 2000 和 Windows NT 4。Microsoft Windows XP 包含有增强功能，允许在不具有此权限的情况下生成特定的登录会话。
详细信息，请阅读《.NET 框架开发人员指南》的以下章节：
ASP .NET 安全性的工作原理
ASP .NET 身份验证
ASP .NET 配置概念
结合使用 IIS 身份验证与 ASP .NET 模拟
有关 IIS 5.0 中身份验证的详细信息，请参阅文章 Internet Information Services 5.0 身份验证方法（英文）。

--------------------------------------------------------------------------------

身份验证方法
在 .NET Web 应用程序中可以采用各种身份验证选项。例如，您可以选择使用某种受支持的 IIS 身份验证机制，或在应用程序代码中执行身份验证。选择身份验证方法时，应考虑以下部分或所有因素：
服务器和客户端操作系统
客户端浏览器类型
用户数量、位置、用户名以及密码数据库类型
部署考虑，如应用程序是基于 Internet 还是 Intranet，及其是否位于防火墙之后。
应用程序类型，如，是交互式网站还是非交互式 Web 服务
要保护的数据的敏感度
性能和可伸缩性因素
身份验证要求。例如，您希望所有用户均可使用应用程序；或希望限制某些区域仅供注册用户使用，而另一些区域“仅限管理员使用”。
确定身份验证方法
使用附录A中的流程图，有助于您根据具体应用程序的要求确定最适合的身份验证方法。要使用该流程图，请先回答有关用户群和部署模型性质的问题。图的结尾处为适当的备选身份验证方法。
检查完流程图后，您应研究以下小节。这些小节提供了关于各种身份验证方法的更详细信息，并提供进一步的指导以帮助您优化决策程序。在本节将要结束之际，您应该能够选出一个备选身份验证方法。
流程图决策点解释
用户是否必须登录？是否需要用户名和密码以访问站点或服务？
是否需要个性化？站点是否可以不需要用户登录而提供个性化内容？
用户帐户？用户帐户是存储于 Windows NT 域帐户、Active Directory，还是其他数据存储区，例如关系型数据库、其他 LDAP（轻便目录访问协议）目录服务或 XML 文件？
需要单一登录还是无缝登录？您是否希望用户从登录页登录，或需要自动进行身份验证？例如，在自动化的企业对企业 (B2B) 交易中可能需要自动身份验证。
您是否需要安全登录？您的系统是否需要使黑客极难通过网络来盗用用户名和密码？这个决策一般是根据站点上可用数据的敏感度来做出的。
应用程序将在 Internet 上运行吗？应用程序是否位于防火墙之后（用户未经过域身份验证），或应用程序将基于 Intranet（最终用户可能已经过域身份验证）？
您是否需要代理安全环境？您是否需要业务组件与呼叫方标识共同运行？如果是这样，则需要模拟。而且，如果您需要访问系统资源（例如消息队列、数据库或远程计算机中的文件系统），则需要代理级别的模拟。
服务器和客户端是否仅运行 Windows 2000？运行环境中的计算机是同样运行 Windows 2000，还是会有客户端运行着其他操作系统（如 Windows 9x 和 Windows NT 4.0）？
匿名身份验证
使用匿名身份验证，服务器不请求客户端向其发送用户凭据。如果您的站点或服务可供公开使用，而您不必知道呼叫方的标识，那么这就是一个好的选择。同时，也不会由于与支持的身份验证机制不兼容而造成浏览器限制。所有用户均可访问配置为匿名身份验证的站点。值得注意的是，尽管您可能已配置了 IIS 以进行匿名身份验证，但身份验证可能是在 ASP .NET 层进行，而这并不是真正的匿名身份验证。本节假设 IIS 和应用程序均不要求登录。
典型应用方案
以下情况下，您应考虑使用匿名身份验证：
无论是对于登录还是业务逻辑组件，您都不需要知道呼叫方的名字和/或密码。
您所保护的信息被认为是“公有的”。
以下情况下，您不应考虑使用匿名身份验证：
您要求使用登录名和密码以限制用户群。
其他考虑
选择匿名身份验证时，您还应考虑以下问题。
站点中仅包含个性化内容
如果您设计的站点仅包含个性化内容，则匿名身份验证可能是一个好选择。例如，新闻站点可以根据用户的邮政编码来提供当地信息，而不需要用户明确登录。个性化功能可以通过使用独立于身份验证的 Cookie 来执行。有关 Cookie 的详细信息，请参阅本文档后面的 Cookie 一节。
模拟
当使用匿名身份验证时，应用程序线程将运行为：
内部匿名 Internet 帐户 IUSR_MACHINENAME。
在 IIS 中为匿名用户配置的帐户。
IIS 系统帐户。
如果您的应用程序使用其他资源，例如 COM+ 组件、数据库、消息队列或 UNC 文件共享，您需要为匿名用户启用相应权限。如果是这样，请考虑以下选项：
设置域控制器以包含所有 Web 和应用程序服务器。配置匿名用户以作为域用户运行，并具有访问相应资源的权限。此方法中的帐户管理是集中进行的，因此更易于管理。
如果您不在域中运行，则可以在每个 Web 和应用程序服务器中创建一个具有相同名字和密码的用户。由于重复帐户的管理比较复杂，所以并不推荐这种方法。
性能
使用匿名网站而不使用 ASP .NET 模拟将带来最佳性能，但是应用程序配置的安全性最差。
实现
要实现匿名身份验证，应为匿名身份验证配置 IIS 并配置适当的匿名用户帐户。使用 Web.config 文件配置 ASP .NET 以使用无身份验证。
//web.config 文件
<system.web>
<authentication mode="None" />
</system.web>
基本身份验证
当 IIS 配置为基本身份验证时，它将指示浏览器通过 HTTP 发送用户凭据。密码和用户名使用 Base64 编码方法进行编码。尽管密码已经编码，但由于其解密相对较容易，所以仍然是不安全的。浏览器将通过对话框提示用户，然后重新发出原始匿名请求和提供的凭据（包括用户名和密码）。弹出式登录对话框不一定适合您的用户界面设计要求。大多数 Internet 浏览器支持基本身份验证。
典型应用方案
以下情况下，您应考虑使用基本身份验证：
您的用户具有 Windows NT 域或 Active Directory 帐户。
您需要支持多个浏览器类型，包括 Netscape Navigator 和所有版本的 Internet Explorer（包括 Pocket PC 和 Windows CE 平台）。
您需要支持通过 Internet 进行身份验证。
您需要在应用程序代码中访问明文密码。
您需要支持代理。
以下情况下，您不应考虑使用基本身份验证：
需要安全登录且不使用安全通道，例如由安全套接字层 (SSL) 提供的通道。
您的用户存储在自定义数据库中，并且没有 Windows 帐户。
您需要一个自定义表单作为登录页提供给用户。
其他考虑
选择基本身份验证时，您还应考虑以下问题：
使用基本身份验证代理
您可以使用基本身份验证从一个计算机代理另一个（但不要超过一个）。代理会发生是因为 IIS 服务器将通过调用 Win32 API LogonUser 实现本地登录。由于 IIS 拥有用户的明文密码，它可以响应远程计算机的挑战，允许 Web 服务器代表客户端操作。如果您需要代理其他计算机的安全环境（超过单个跃点)，则必须本地登录到呼叫链中的其他计算机。通过使用基本身份验证能够实现这一点，因为您可以访问用户的名字和明文密码，而名字和明文密码可以传递给其他应用程序（例如基于 ISAPI 或 CGI 的应用程序）。
保护基本身份验证
值得注意的是，密码的破译相对容易，因此您应将基本身份验证的使用限制在非安全或至多是半安全的应用程序中。
您可以通过与 SSL 结合来保护基本身份验证。这将防止密码被破译。目前的许多 Internet 应用程序都结合使用了基本身份验证和 SSL。
实现
要实现基本身份验证，应在 IIS 内对其进行配置，并确保您的用户在 Web 服务器上具有“本地登录”权限。如果您的 ASP .NET 应用程序需要作为经过基本身份验证的用户来运行，请使用以下 Web.config 文件配置。
// web.config 文件
<system.web>
<authentication mode="Windows" />
</system.web>

简要身份验证
简要身份验证是 Windows 2000 和 IIS 5.0 的新功能。这种身份验证形式能够加密用户的密码信息并提供一种机制以便防止某些常见的服务器攻击（如重放攻击）。简要身份验证不像基本身份验证那样使用明文通过网络发送凭据。相反，它使用一种由 RSA 开发的散列机制，称为 MD5。（有关详细信息，请参阅位于 http://www.ietf.org/rfc/rfc1321.txt ;的“MD5 消息简要算法” 。）尽管它对于 Internet 来说是一个可行的身份验证选择，但客户端和服务器的要求限制了它的广泛使用。IIS 与基本身份验证不同，而与 NTLM 和 Kerberos 类似。它不在本地登录 Web 服务器，因此不能执行代理。
典型应用方案
以下情况下，您应考虑使用简要身份验证：
您的 Web 服务器运行 Windows 2000，并且您的用户在 Active Directory 中存储有 Windows 帐户。
您所有的客户端均使用 .NET 平台或 Internet Explorer 5.x。
您需要比基本身份验证更强大的密码加密方法。
您需要支持通过 Internet 进行身份验证。
以下情况下，您不应考虑使用简要身份验证：
您的某些客户端使用非 .NET 或 Internet Explorer 5.0（或更高版本）的平台。
您的用户在 Active Directory 中没有存储 Windows 帐户。
您需要代理。
其他考虑
选择简要身份验证时，您还应考虑以下问题。
保护简要身份验证
简要身份验证的目的是提供比基本身份验证更安全的登录方法。然而，它没有与 SSL、NTLM、Kerberos 或证书身份验证相结合的基本身份验证安全。
通过 SSL 使用简要身份验证是一个安全的解决方案，但是其部署要求目前限制了它的广泛使用。
简要身份验证的特定平台要求
简要身份验证要求客户端运行 .NET 或 Internet Explorer 5.x。用户帐户必须存储在 Active Directory 中，且 Active Directory 必须针对简要身份验证进行配置。
实现
您必须为简要身份验证配置 IIS。有关详情，请参阅 Microsoft 知识库文章 Q222028，设置简要身份验证以使用 Internet Information Services 5.0（英文）。
如果您的 ASP .NET 应用程序需要作为已进行 IIS 简要身份验证的验证用户来运行，请使用以下 Web.config 配置：
// web.config 文件
<system.web>
<authentication mode="Windows" />
</system.web>

要在 Windows 2000 中使用简要身份验证，服务器必须能访问设置为进行简要身份验证的 Active Directory 服务器。
有关简要身份验证的详细信息，请参阅 RFC 2069 规范 http://www.ietf.org/rfc/rfc2069.txt)。
集成 Windows 身份验证
集成 Windows 身份验证（使用 NTLM 挑战/响应或 Kerberos）涉及对具有 Windows NT 域或 Active Directory 帐户的用户进行身份验证。与基本身份验证和简要身份验证不同，在该方法中加密密码不通过网络发送，因而非常安全。如果服务器中安装有 Active Directory 服务，且浏览器与 Kerberos V5 身份验证协议兼容，则将使用 Kerberos V5 协议和挑战/响应协议，否则将仅使用挑战/响应协议。该方法最适合 Intranet 环境。在这种环境中，用户和 Web 服务器计算机在同一个域中，管理员可以保证每台计算机均运行 Microsoft Internet Explorer 版本 3.01 或更高版本。
典型应用方案
以下情况下，您应考虑使用集成 Windows 身份验证：
您的用户具有 Windows NT 域或 Active Directory 帐户。
您的应用程序运行于 Intranet 上（在防火墙后）。
所有客户端均运行 Internet Explorer 版本 3.01 或更高版本。
您需要执行代理（这需要 Kerberos）。
您需要为域用户采用无缝登录程序（例如，没有弹出式登录对话框）。
以下情况下，您不应考虑使用集成 Windows 身份验证：
您的用户帐户是存储在外部数据库中，而不是存储在 Windows NT 域数据库或 Active Directory 中。
您需要支持通过 Internet 进行身份验证。
您的客户端使用 Netscape Navigator 或其他非 Microsoft 浏览器。
您需要获得客户的明文密码。
其他考虑
选择集成 Windows 身份验证时，还应考虑以下问题。
NTLM 和 Kerberos 的安全级别
这两种协议均高度安全。对于 NTLM 和 Kerberos 协议，密码不通过网络传输。NTLM 使用一种挑战/响应机制。Kerberos 甚至更加安全，因为它支持互相验证（即，客户端可以验证其与之通讯的服务器）。
代理问题
NTLM 协议不支持代理。当客户端的凭据传送到 IIS 服务器之后，它们不能被传送到后端服务器进行身份验证。但是，Kerberos 支持代理，允许多个下游计算机的其他进程代理客户端凭据。例如，您可以使用 Kerberos 将 Web 用户的凭据提供给 COM+ 中间层，并通过该层到达 Microsoft SQL Server 数据库（配置为 Windows 集成安全性）。Active Directory 的默认配置中未启用 Kerberos 身份验证。在决定将其作为代理解决方案之前，您必须确保您的环境支持 Kerberos。
Internet 的使用
NTLM 和 Kerberos 协议在 Internet 中均不常用。要在 Internet 中使用 Kerberos，关键问题是安全授权需要集中并对所有用户可用。只有基础设施到位才能实现这一点。部署 Internet 的另一个问题是非 Microsoft 浏览器不支持这些协议。对于特定的客户群，这可能会是一个限制因素。
性能和可伸缩性
Kerberos 比 NTLM 快。但是，这两种协议均比基本身份验证或某些自定义身份验证方法慢。如果您希望大量用户同时登录，就需要仔细设计 Active Directory 的配置。如果您拥有数百万的潜在用户，则您可以考虑使用高性能数据库（如 SQL Server）来存储用户的名字和密码。如果您在多层应用程序中代理安全环境，就很可能会遇到可伸缩性问题。特别是，不能使用数据库连接池等中间层解决方案。
实现
要实现 Kerberos 或 NTLM，您需要配置 IIS 以使用集成 Windows 身份验证。如果您需要支持运行非 Internet Explorer 的客户端，则可以启用基本身份验证以结合 NTLM 或 Kerberos。
配置 Kerberos 时，您需要考虑这些特定细节：
客户端和服务器必须都在同一 Windows 2000 域中运行 Windows 2000。
必须启用客户端的用户帐户以使用代理。
必须启用服务器的帐户以使用代理。
如果您的 ASP .NET 应用程序需要作为已由 IIS 使用集成 Windows 身份验证进行过验证的用户来运行，请使用以下 Web.config 配置：
// web.config 文件
<system.web>
<authentication mode="Windows" />
</system.web>
有关使用 Kerberos 的详细信息，请参阅：
Windows 2000 中的 Kerberos 组件（英文）
Kerberos 说明（英文）
证书身份验证
证书是安装在计算机中的数字“密钥”。计算机试图访问服务器时，密钥将自动传送以对用户进行身份验证。客户端证书可被映射到域或 Active Directory 中的 Windows 帐户。如果您在 ASP .NET 中使用 Windows 身份验证提供程序，应用程序线程将作为证书所映射的用户运行。您也可在 ASP .NET 中实现自定义身份验证，例如，您可以使用证书内包含的电子邮件地址（或类似的唯一字段）。从客户端的观点来看，安全性是无缝的，因为客户端不需要使用登录页来登录。这就使得证书在自动化业务流程方面成为一个有吸引力的选择。
典型应用方案
以下情况下，您应考虑使用证书身份验证：
您所保护的数据非常敏感，您需要非常安全的解决方案。
您需要互相身份验证。
您希望第三方能够管理服务器和证书拥有者之间的关系。
您希望实现无缝的客户端交互，例如自动 B2B 交易。
以下情况下，您不应考虑使用证书身份验证：
发布和管理客户端证书的成本超过了增加安全性所获得的价值。
其他考虑
选择证书身份验证时，您还应考虑以下问题。
部署
您需要将客户端证书物理部署在客户端工作站中。有多种方法可以进行此部署，从 Web 部署到从 CD-ROM 安装证书。通常是部署的问题导致了证书模式的使用不如其他与 SSL 相结合的身份验证模式广泛。
映射到 Windows 帐户
可以将证书映射到域或 Active Directory 帐户。如果需要对个别用户进行身份验证，可以使用一种称为“一对一映射”的技术，将证书映射到单独帐户。如果使用 Active Directory 映射，则对一对一映射没有限制。
如果需要验证来自特定组或组织的所有用户，则可以使用多对一映射，例如，将所有包含同一公司名称的用户映射到一个帐户。
例如，考虑以下 B2B 方案：
公司 A 允许其合作公司 B 查看其部分内部网站。
公司 B 的计算机安装有证书。
多对一映射的结果是，ASP .NET 应用程序将作为通用的“CompanyB” Windows 帐户运行。
有关证书的深入信息，请参阅由 Michael Howard 所著的《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》。
实现
您必须配置 IIS 以进行证书身份验证。有关将公共密钥证书映射到 Windows 2000 用户帐户的详细信息，请参阅将证书映射到用户帐户的循序渐进指南（英文）。
Passport 身份验证
Passport 身份验证是由 Microsoft 提供的集中身份验证服务。使用 Passport 时，在某些情况下您不必实现自己的身份验证代码、登录页和用户表。Passport 使用 Cookie 机制工作。如果客户端以前已经通过了 Passport 验证，则允许它们访问您的站点。否则，它们将被自动重定向到 Passport 站点以进行身份验证。
如果您需要在多个域之间进行单一登录（这些域也支持 Passport），那么 Passport 是一个好选择。Passport 不仅提供身份验证服务，还提供包括配置文件管理和采购服务在内的其他服务。
在 Windows 2000 平台上，Passport 没有直接集成到操作系统内部的任何身份验证和授权机制。.NET 框架确实会检查 Passport Cookie，但如果您维护自己的数据库，您必须实现自己的代码，以将 Passport 用户映射为自己的用户，同时还要实现自己的授权机制。
典型应用方案
以下情况下，您应考虑使用 Passport 身份验证：
您的站点要与其他启用 Passport 的站点结合使用，同时您希望访问这些站点的用户能够进行单一登录。
您不想维护用户名和密码数据库。
以下情况下，您不应考虑使用 Passport 身份验证：
您希望使用已经存储在自己的数据库或 Active Directory 中的用户名和密码。（尽管有可能使用额外的代码将 Passport ID 映射为用户帐户。）
您的客户端是通过编程来访问站点的其他计算机。
其他考虑
选择 Passport 身份验证时，您还应考虑以下问题。
启用 Passport
使用 Passport 身份验证要求站点注册 Passport 服务并在服务器中安装 Passport SDK。
代理
在 Windows 2000 中，不可能从一个服务器将用户的 Passport 安全凭据代理到另一个。
映射到用户帐户
Passport 用户 ID (PUID) 仅仅是一个标识。如果您的用户帐户是在 Active Directory 或任何自定义数据库中定义的，并且您需要将 PUID 映射为用户，则您需要实现自己的自定义代码。Windows 的未来版本可能会提供将 PUID 映射到 Windows 帐户的本机支持。
保护 Passport
当 Passport 作为单机身份验证方法使用时，加密 Cookie 的本质使得 Passport 比较安全。然而，为了避免重放攻击并维持最高安全级别，Passport 需要与 SSL 结合使用。
实现
要实现 Passport，您需要在服务器中安装 Passport SDK。您还需要向 Passport 注册以使用服务。您必须按如下方法配置 web.config 文件：
// web.config 文件
<system.web>
<authentication mode="Passport" />
</system.web>
有关 Passport 服务的详细信息，请参阅：
Passport 身份验证提供程序（英文）
Passport 技术白皮书（英文）
Passport 开发人员信息（英文）
表单身份验证
表单身份验证是指接受用户凭据的自定义用户界面组件，例如，一个用户名和密码。现在使用的许多 Internet 应用程序具有这种供用户登录的表单。值得注意的是，表单本身并不执行身份验证，它仅仅是一种获得用户凭据的方法。身份验证是通过使用自定义代码访问用户名和密码数据库来实现的。
验证用户身份后，服务器一般会通过某种方式向客户端表明其已经通过身份验证，可以进行后续请求。如果需要，您可以强制用户验证每个请求，但这样会影响性能和可伸缩性。您应考虑两种基本方法来识别以前登录过的客户端：
Cookie。Cookie 是最初由服务器向客户端发送的一小段数据。随后，由客户端随每个 HTTP 请求将其发送回服务器。它可以用作客户端已经通过身份验证的标志。ASP .NET 通过 CookieAuthenticationProvider 模块为您提供了使用 Cookie 进行表单身份验证的机制。大多数 Web 浏览器（包括 Internet Explorer 和 Netscape Navigator）均支持 Cookie。
自定义。您可以实现自己的自定义机制来向服务器标识客户端。如果您的客户端禁用了 Cookie，您可以考虑在每个 URL 查询字符串中存储一个唯一标识符。或者使用存储在永久性顶级或不可见框架中的隐藏表单域。无论如何，您要确保黑客不能通过编程模拟成已经通过应用程序身份验证的用户。
Cookie 广泛应用于使用表单身份验证的网站。.NET 的最初版本将仅支持使用 Cookie 的表单身份验证。
典型应用方案
以下情况下，您应考虑使用表单验证：
用户名和密码存储在 Windows 帐户以外的位置。请注意，Windows 帐户也可以使用表单身份验证。
您要在 Internet 上部署应用程序。
您需要支持所有浏览器和客户端操作系统。
您希望为用户提供自己的用户界面表单作为登录页。
以下情况下，您不应考虑使用表单验证：
您要为公司 Intranet 部署应用程序，并且可以利用集成 Windows 身份验证。
您不能通过编程访问来验证用户名和密码。
其他考虑
选择表单身份验证时，您还应考虑以下问题。
保护表单身份验证
如果用户是通过登录页来提交密码的，您可以使用 SSL 来保护通道，以防密码被盗。如果您使用 Cookie 来维护用户在各个请求之间的标识，您应当了解黑客通过网络监视程序“盗用”用户 Cookie 的潜在危险。使用 Cookie 时，要使站点真正安全，唯一的方法是站点内的所有通讯都使用 SSL。对大多数商业网站来说，由于这种方法的运行开销太大，所以不切实际。使用 ASP .NET，您可以使服务器定期重生成 Cookie。这种使 Cookie 过期的策略是为了防止其他用户盗用 Cookie 访问站点。
性能和可伸缩性
设计大流量网站时，您需要考虑验证用户身份所带来的性能影响。如果您预计会有大量用户同时登录，您需要尽快完成凭据确认过程。
如果使用 SSL，由于必须执行额外的加密步骤，性能会明显下降。在 Web 中，您应将实现安全登录的服务器和内容服务器分开，以满足性能要求。
检查 Cookie 的存在
如果您使用的是 .NET，则检查 Cookie 存在的进程是自动实现的。但如果不使用 .NET，则有两种基本方法：
实现 ISAPI 筛选器，它确认客户端请求中 Cookie 的存在，证明客户端已经通过身份验证。如果 Cookie 存在，则允许请求继续。如果 Cookie 不存在，则将客户端重定向到登录页。如上所述的 ISAPI 筛选器可以由 Microsoft Commerce Server 2000 实现。
您可以在每个 Web 页的开始处编写代码检查 Cookie 是否存在，或编写由 Web 页传递的其他自定义值。如果标记不存在，代码可将用户重定向到登录页。这一实现方法很简单；但是，您可能无法保护除 ASP 页以外的资源。例如，图像文件可能仍然可以访问。
如果您使用的是 ASP .NET，则可以利用表单身份验证提供的内置功能。
使用表单身份验证与 Windows 帐户
如果您部署的是 Internet 应用程序，而您的用户在服务器中具有 Windows 帐户，则可以使用表单身份验证或 SSL 上的表单身份验证，以替代基本身份验证和简要身份验证。
如果您的应用程序基于 Intranet，并且已经在使用集成 Windows 身份验证，则表单身份验证可能并非好的解决方案。您公司的安全策略可能也不允许用户将密码输入 HTML 表单。
实现
要实现表单身份验证，您必须创建自己的登录页并重定向未验证客户端的 URL。您还必须创建自己的帐户查找方案。使用 ASP .NET，可以使用以下 Web.config 配置：
// web.config 文件
<system.web>
<authentication mode="Forms" />
</system.web>

因为您实现的是自己的身份验证，一般可以将 IIS 配置为匿名身份验证。
有关实现 SSL 的详细信息，请参阅以下文章。
Web 安全性揭密：最大限度地利用 IIS 安全性（英文）
《Internet Information Services 5.0 资源指南》中的“配置 IIS 5.0 安全性”
Cookie
Cookie 是由 Web 服务器放在您的硬盘驱动器上的一个小文本文件。其主要目的是让服务器能够识别返回的客户端。无论是否存在身份验证机制，您都可以使用 Cookie。请考虑以下应用方案：
与表单身份验证结合使用。服务器根据身份验证向客户端发布一个 Cookie，并根据提交回服务器的 Cookie 来验证后续请求。
仅用于向用户提供自定义内容的个性化站点。
ASP .NET 提供了一种机制来创建 Cookie 并自动检查客户端请求中是否存在 Cookie。可以使用 .NET 框架支持的三级 DES 方案对由 ASP .NET 创建的 Cookie 进行有选择的加密。您也可以实现自己的 Cookie 提供程序并在表单身份验证中使用。
有关 Cookie 的详细信息，请参阅关于 Cookie 的信息（英文）。
其他考虑
不同浏览器类型可能对 Cookie 的大小有不同的限制。RFC 2019 指定的大小限制为 4 KB。Internet Explorer 5 对 Cookie 没有大小限制。浏览器的安全设置必须配置为接受 Cookie，程序才能正常工作。

--------------------------------------------------------------------------------

Web 服务安全性
Web 服务是基于 ASP .NET 结构的应用程序，可以通过 Internet 编程调用。从安全角度看，它存在的问题与开发交互式网站的问题类似。您需要使用与保护 ASP .NET 资源相同的机制来保护 Web 服务（如 IIS 和 ASP .NET 身份验证提供程序）。但是，设计过程中您还需要考虑这些额外因素：
客户端交互。您的 Web 服务可能没有连接和输入安全凭据的交互用户。而您的“用户”可能是应用程序。
方法级别安全性。您可能需要在方法级别授权用户，以限制使用特定方法，您可以采用类似于 COM+ 组件方法级别安全性的方法来实现这一目的。
代理。您的 Web 服务可能需要（也可能不需要）呼叫其他服务并维护原始呼叫方的安全环境。
Web 服务身份验证
Web 服务需要以某种方式接受用户凭据。如果服务是非交互式的，则需要获得呼叫方的安全标记，或需要显露适当的方法以允许提供凭据。以下身份验证方法容易使用，不需要用户输入凭据，对于可编程 Web 服务来说是很好的选择：
基本、简要和集成 Windows 身份验证
证书映射身份验证
应用程序专用或自定义身份验证
以下的选项也有应用潜力：
Internet 协议安全性
Passport
使用 Windows 帐户和 IIS 身份验证
您需要考虑的问题与本文身份验证方法一节中所述的问题一样。本实现方法所需的自定义代码最少，同时，您可以使用 Windows ACL 授权对其他资源的访问。
使用证书和证书映射
当使用证书身份验证时，客户端和服务器之间可以进行无缝交互；即，客户端不必通过编程提供用户名和密码。而且，这是一种高度安全的机制。B2B 交易（如提交订单）是使用证书的理想场合。如果您使用证书映射来获取 Windows 用户帐户，您也可以使用 Windows ACL 来授权对资源的访问。
自定义身份验证
您可以实现自定义身份验证解决方案。与集成 Windows 身份验证方法相比，此解决方案的优点是，不再需要应用程序来为每个用户维护各自的帐户。您还可以一起忽略 IIS 身份验证，而在 Web 服务代码中使用自己的自定义方法，并根据应用程序特定的要求进行优化。
可能的 Web 服务自定义身份验证解决方案包括：
接受用户名和密码作为方法调用的参数。
提供一种必须在调用其他方法之前调用的登录方法。您可以使用 Microsoft .NET 框架的 Cookie 功能来验证对登录方法的调用。
使用 SOAP 标头或 SOAP 正文来存储凭据。
创建自定义 HTTP 标头或正文来存储凭据。
Internet 协议安全性
如果您知道客户端的 IP 地址，例如，客户端是调用封装在 Web 服务业务逻辑的中间层 Web 服务器，则可以选择 Internet 协议安全性 (IPSec)。此方法允许您根据 IP 地址来限制连接到 Web 服务的计算机。
该方法在 Internet 方案中不可行，因为您预先不知道客户端的 IP 地址。
有关 IPSec 的详细信息，请参阅 MSDN 文章 Microsoft Windows 2000 服务器的 IP 安全性（英文）。
在 Web 服务中使用 Passport
有时 Web 服务可能会使用 Passport 进行身份验证。但是，它的使用很有限，因为它要求将未通过验证的客户重定向到 Passport 站点。对非交互式客户端来说，重定向会出现问题，除非专门为此编程来处理重定向到 Passport 服务器的情况。
授权
完成用户身份验证后，您可能需要授权其访问 Web 服务。以下是几种授权选项：
使用 Windows ACL
使用 URL 授权
使用 .NET Principal 对象
使用 Windows ACL
使用 Windows ACL，您可以创建特定应用程序文件的文件系统许可。如果您的 Web 服务对用户进行 Windows 帐户身份验证并使用模拟，则可以使用此解决方案。
使用 URL 授权
URLAuthorizationModule 将用户和角色映射到 URI 名称空间中的元素。该模块同时实现肯定和否定的授权声明。也就是说，该模块可以根据用户的某种身份（例如角色关系），选择性地允许或拒绝该用户访问 URI 名称空间中的任意元素。下面的例子为某些域用户授权，但拒绝其他用户。
<configuration>
<system.web>
<authentication mode="Windows" />
<authorization>
<allow users="domain1\user, domain2\user2, domain1\user3 />
<deny users="*" />
</authorization>
</system.web>
</configuration>
Windows Principal 对象
.NET 框架类库 (BCL) 中的 System.Security.Principal 名称空间提供了一个 WindowsPrincipal 对象来表示代码运行的安全环境。使用 IIS 中的 Windows 身份验证时，该对象将自动创建。它允许您检查 Windows 用户的 Windows 组成员，并相应地限制访问权限。
Generic Principal 对象
Generic Principal 对象可根据您自己的自定义角色来创建。如果您拥有自己的用户/角色数据库，则可以使用它。Principal 对象在 OnAuthenticate 事件中填充。您可以将自定义表映射到在此事件中映射的 Windows 帐户。无论如何，您都可以为该特殊用户创建一个自定义 Principal 对象。
对于已经通过身份验证的返回用户，您可以使用 Cookie 来重新为返回用户重新创建 Principal 对象。
角色和方法级别安全性
您可能需要使用方法级别安全性来限制由特殊客户端当事者调用的特殊方法。有许多方法可以处理该问题。
如果您使用 Windows 帐户，可以以 Windows 组的形式为用户创建角色。因为 ASP 线程将模拟客户端，您将获得一个 Windows Principal 对象；请使用以下方法：
为 ASP .NET 线程访问的受保护资源创建 ACL。
从每一种方法调用 WindowsPrincipal 对象中的 IsInRole 方法，以验证调用方具有适当的权限。您还可以在代码中实现逻辑语句，根据客户端的组成员身份调用特定的子例程。
如果您使用自定义数据库中的用户和角色创建 Generic Principal 对象：
您可以通过编程调用 Principal 对象的 IsInRole 方法以检查角色成员身份，其方式与上文所述的 Windows Principal 对象相同。
如果您不使用 Principal 对象，则可以选择其他选项：
接受用户凭据作为方法调用的参数并进行查找。
方法调用的第一项操作是验证 Cookie 的存在。
创建一个登录方法返回自定义键值。后续的方法将接受此键值作为参数。这与使用受浏览器支持的 Cookie 类似，但是它在客户端不支持 Cookie 的情况下也可以使用。
代理
和 ASP .NET 网站一样，Web 服务也存在同样的代理问题。要将安全环境代理到 Web 服务，您需要使用 Kerberos 身份验证，或者必须传递凭据以便于运行在其他计算机上的 Web 服务能够调用 LogonUser（对于 Windows 服务器）或等价身份验证 API（对于非 Windows 服务器）。
客户端访问
如果您通过编程与 Web 服务连接，您可以利用 .NET 类进行客户端连接。.NET 客户端支持的身份验证协议有：
基本
简要
Windows 集成（NTLM 和 Kerberos）
证书
自定义

--------------------------------------------------------------------------------

代码访问安全性
为了保护计算机系统不受恶意代码的干扰，也为了保证移动代码的安全运行，.NET 框架提供了一种称为代码访问安全性 (CAS) 的安全机制。CAS 是一种 .NET 安全特征，适用于所有 .NET 托管代码，如 ASP .NET Web 应用程序。尽管如此，在编写以下特定代码时您需要牢记这一点：
设计浏览器承载的控件
承载第三方应用程序
在共享服务器上承载来自不同供应商的程序集
您希望保护某些本机功能（如文件写 API）以供某些程序集使用
根据代码的来源和代码标识的其他特征（如强加密程序集名），CAS 允许代码有不同的可信度，这取决于您的安全策略。CAS 减少了您的代码被其他恶意代码滥用的可能性。它使您可以专门设置允许代码执行的操作，以及决不允许代码执行的操作。特别是，CAS 支持许可支持机制，通过该机制，代码可明确请求特定许可、或明确拒绝其他不需要的许可。
代码访问许可
代码访问安全性依赖于代码访问许可概念。每个许可代表代码访问受保护资源（如文件、目录、注册表项）的权限或执行受保护操作（如调用非托管代码）的权限。代码将请求许可，而运行时安全策略将决定授予何种许可。有关完整列表，请参阅代码访问许可（英文）。
.NET 允许管理员向应用程序分配预定义的许可集。这些许可集根据应用程序的可信度而有所不同。默认情况下，应用程序根据代码的数字签名、原始格式和应用程序位置等证据获得信任级别。
例如，运行在 UNC 共享（在 Intranet 安全区域运行）上的应用程序将获得 LocalIntranet 许可集。而运行在本地计算机（在 MyComputer 安全区域运行）上的应用程序将获得 FullTrust 许可集。
通过为 ASP .NET Web 应用程序分配信任级别，可以进一步配置它们。信任级别的配置是通过使用配置文件中的 <trust> 元素来实现的。
<trust level="Full | High | Low | None" originUrl="url" />
每个级别都决定了应用程序的许可程度，其细节在 XML 安全策略文件中指定。每一级别都映射到一个特定文件。ASP .NET 的默认映射是：
高 - 映射到 web_hightrust.config 这一级别提供的授权允许应用程序读/写应用程序目录（服从于操作系统许可），并允许应用程序取代身份验证 Principal 对象。它还限制应用程序调用非托管代码。
低 - 映射到 web_lowtrust.config 这一级别允许应用程序读取应用程序目录，并提供有限的网络连接。如果 <trust> 元素的 originUrl 属性配置恰当，应用程序就能够连回其承载站点。
无 - 映射到 web_notrust.config 这一级别提供基本执行许可，并支持应用程序使用独立存储（一种允许代码与保存数据安全关联的机制）。
请注意，完全信任没有相应的配置文件，因为完全信任允许应用程序使用所有资源（服从于操作系统许可），如同在没有代码访问安全性的情况下运行一样（但 CAS 不能关闭托管代码）。您可以使用配置文件中的 <securityPolicy> 元素替代这些映射，也可以自定义和扩展每一级别。您还可创建自己的定义任意许可集的级别。以下所示为默认 <securityPolicy> 映射集。
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="None" policyFile="web_notrust.config" />
</securityPolicy>
锁定配置设置
ASP .NET 配置在本质上是层次化的，在计算机级别、应用程序级别和子应用程序级别具有可选的配置文件。子级别配置文件可用于替代更高级别的设置，或用于添加其他配置信息。尽管它提供了很高的灵活性，但有时候管理员希望加强配置设置，不允许他们被指定的应用程序替代。例如，宿主网站的管理员希望指定代码访问安全级别，不允许单个应用程序更改它。结合使用 <location> 元素和 allowOverride 属性可以实现这一目的。
例如，宿主网站的管理员希望确保所有应用程序都不能调用非托管代码。以下配置文件片段说明管理员如何锁定整个站点的代码访问配置设置，并限制高信任级别的应用程序（不允许调用非托管代码）：
<location path="somesitepath" allowOverride="false">
<trust level="high" originUrl="http://somesite.com"; />
</location>
path 属性可以指向站点或虚拟目录，它适用于指定目录及其所有子目录。在上面的示例中，如果将 allowOverride 设置为“假”，则能够保护站点内的所有应用程序不被 <location> 元素中指定的配置设置替代。请注意，锁定配置设置的功能适用于所有设置，而不仅限于信任级别这样的安全设置。
有关详细信息，请参阅：
.NET 中的安全性：使用公共语言运行时限制代码访问权限（英文）
代码访问安全性（英文）

--------------------------------------------------------------------------------

通道安全性
通道通过远程处理边界（如 AppDomains、进程和计算机）来传输信息。.NET 框架提供两种远程处理通道：HTTP 和 TCP。
如果您希望保护通过这些协议传输的机密或敏感信息，则需要考虑使用安全通道。除非信息没有加密保护，否则使用网络监视软件很容易中途截获和读取这些信息。
以下是通道安全性的一些关键问题：
承载于 IIS 和 ASP .NET 中的 HTTP 通道支持使用 SSL 传送和接收安全数据。SSL 是设置安全通讯通道的最常用机制，可以在 IIS 内配置。
如果您希望使用非安全通道（如 HTTP/端口 80 或 TCP），则仍然可以使用加密 API 手动加密数据。
可以在传输层下实现通道安全机制。如果您使用 Windows 2000，则可以利用 Internet 协议安全性 (IPSec)，在对应用程序透明的同时，达到保护数据传输的目的。
如果您使用 ASP .NET 和 COM 或 DCOM 组件，并使用 DCOM 作为您的远程处理机制，则可以考虑使用 DCOM 数据包保密身份验证级别来加密 DCOM 通讯。
有关详细信息，请参阅：
《Microsoft Windows 2000 Server 资源包》中的“保护 Web 通讯”，Microsoft Press
.NET 框架开发人员规范（英文）中的远程处理规范
Microsoft Windows 2000 Server IP 安全性（英文）
MSDN 中的“设置 DCOM 和 NT 安全性”

--------------------------------------------------------------------------------

其他信息
要了解本文讨论的安全问题的其他信息，请参阅以下参考内容。
《Microsoft Windows 2000 Server 资源包》中的“理解数字证书”，Microsoft Press
.NET 框架 SDK（英文）
Microsoft 知识库文章 Q158229，信息：IIS 应用程序的安全性部分（英文）
使用 Microsoft Windows 平台创建网站的蓝图（英文）
有关 Web 服务安全性的详细信息，请参阅以下参考材料。
使用 SOAP 工具包保护 Web 服务（英文）
《设计基于 Web 的 Microsoft Windows 2000 安全应用程序》，Microsoft Press
Internet Information Services 5 安全性检查表（英文）
Microsoft 知识库文章 Q187506，运行 IIS 站点所需的 NTFS 权限列表（英文）
有关安全性的一般信息，请参阅：
Microsoft 安全性