ASP .NET 中的身份验证：.NET 安全性指导[5]

;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 身份验证，或者必须传递凭据以便于运行在其他计算机上的