Microsoft Corporation
本章内容
灵活开放标准的使用使得 Web 服务成为一种优秀的机制，可以通过 Web 服务将功能向客户端公开，以及用它来承载前端 Web 服务可以访问的中间层业务逻辑。然而，由于标准的局限性，以及需要支持各种客户端类型，从而使 Web 服务面临着安全方面的挑战。
本章介绍如何开发和应用身份验证、授权和安全通信技术来保护 ASP.NET Web 服务。本章首先简要介绍三种主要的 Web 服务安全模型–传输／平台、应用程序和消息级–，然后详细介绍实现适用于 ASP.NET Web 服务的可用选项及传输／平台级安全性。
目标
利用本章来：
| • | 保护您的 Web 服务。 |
| • | 实现平台／传输级安全性解决方案。 |
| • | 比较和对比平台／传输级安全性与消息级安全性。 |
| • | 标识和使用由 ASP.NET Web 服务提供的网关守卫。 |
| • | 将客户端凭证传递给需要身份验证的 Web 服务。 |
| • | 将原调用者标识从 Web 服务传递到下游系统。 |
| • | 设计适合于您的 Web 服务的身份验证、授权和安全通信解决方案。 |
适用于：
本模拟适用于以下产品和技术：
| • | Microsoft® Windows® Server 2000 和 Windows Server™ 2003 操作系统 |
| • | Microsoft Internet Information Services (IIS) 5.0 及更高版本 |
| • | Microsoft Active Directory® 目录服务 |
| • | Microsoft .NET Framework 1.0 版（带 service pack 2）及更高版本 |
| • | Microsoft Visual C#® .NET 开发工具 |
如何使用本章
要想从本单元获得最大价值，您应该：
| • | 具备使用 Visual C# .NET 的编程经验。 | ||||||||
| • | 具备开发和配置 ASP.NET Web 应用程序的经验。 | ||||||||
| • | 具备配置 IIS 安全性、Windows 安全性和 Active Directory 的经验。 具备配置 Enterprise Services (COM+) 应用程序的经验。 | ||||||||
| • | 阅读“Introduction”一章。它定义了身份验证、授权和安全通信对分布式 Web 应用程序的重要性。 | ||||||||
| • | 阅读“Security Model for ASP.NET Applications”一章它概述了创建分布式 ASP.NET Web 应用程序所使用的体系结构和技术，并着重指出在该体系结构中的什么地方适用身份验证、授权和安全通信。 | ||||||||
| • | 阅读“身份验证和授权”一章。它详细介绍了当您使用 ASP.NET Web 服务时，可用的身份验证和授权机制。 | ||||||||
| • | 阅读“安全通信”一章。它介绍 SSl 和 IPSec，这两种通信安全性技术在客户端与 Web 服务之间进行通信时会经常用到。 | ||||||||
| • | 阅读“ASP.NET 安全性”一章。它深入介绍与 ASP.NET 相关的安全性问题，其中大部分与 ASP.NET Web 服务有关。 | ||||||||
| • | 阅读以下各章，它们介绍如何实现本章所讨论的许多技术：
|
本页内容
 | Web 服务安全性模型 |
| 平台／传输安全性体系结构 |
| 身份验证和授权策略 |
| 配置安全性 |
| 将身份验证的凭证传递给 Web 服务 |
| 传送原调用者 |
| 受信任的子系统 |
| 访问系统资源 |
| 访问网络资源 |
| 访问 COM 对象 |
| 将客户端证书用于 Web 服务 |
| 安全通信 |
| 小结 |
Web 服务安全性模型
可以在三个级别应用 Web 服务安全性：
| • | 平台／传输级（点对点）安全性 |
| • | 应用程序级（自定义）安全性 |
| • | 消息级（端对端）安全性 |
每一种方法都具有各自的优缺点，下面将详细阐述这些方法。选择哪一种方法在很大程度上取决于消息交换中涉及到的体系结构和平台的特点。
注本章着重介绍平台级和应用程序级的安全性。消息级安全性将在全局 XML Web 服务体系结构 (GXA) 提案中以及专门在 WS-Security 规范中进行介绍。在编写本指南时，Microsoft 刚刚发布了 Web 服务开发工具包的技术预览版本。它可用于开发符合 WS-Security 规范的消息级安全性解决方案。有关详细信息，请参阅 http://msdn.microsoft.com/webservices/building/wse/。
平台／传输级（点对点）安全性
两个终结点（Web 服务客户端和 Web 服务）之间的传输通道可用于提供点对点的安全性。图 1 阐释了这种情况。
图1. 平台／传输级安全性
当您使用平台级安全性时（它假定在公司 Intranet 上安装了紧密集成的 Microsoft_ Windows_ 操作系统环境）：
| • | Web 服务器 (IIS) 提供基本、摘集成和证书身份验证。 |
| • | ASP.NET Web 服务继承了某些 ASP.NET 身份验证和授权功能。 |
| • | 可以使用 SSL 和／或IPSec 提供消息完整性和机密性。 |
何时使用
传输级安全性模型简单明了，并且可用于许多（主要是基于 Intranet 的）方案；在这些方案中，可以严格控制传输机制和终结点配置。
传输级安全性的主要问题有：
| • | 安全性取决于基本平台、传输机制和安全服务提供程序（NTLM、Kerberos 等等）并且与它们紧密集成。 |
| • | 安全性是在点对点的基础上应用的，无法通过中间应用程序节点提供多个跃点和路由。 |
应用程序级安全性
通过使用这种方法，应用程序负责提供安全性并使用自定义的安全功能。例如：
| • | 应用程序可以使用自定义的 SOAP 标头传递用户凭证，以便根据每个 Web 服务请求对用户进行身份验证。常用的方法是在 SOAP 标头中传递票证（或者用户名或许可证）。 |
| • | 应用程序可以灵活地生成其包含角色的 IPrincipal 对象。该对象可以是自定义类或 .NET ¿ò¼Ü提供的 GenericPrincipal 类。 |
| • | 应用程序可以有选择地加密需要保密的内容，但是这需要使用安全密钥存储，并且开发人员必须了解相关加密 API 的知识。 |
另一种方法是使用 SSL 提供机密性和完整性，并将它与自定义的 SOAP 标头结合起来以执行身份验证。
何时使用
在以下时候使用此方法：
| • | 您想要利用在现有应用程序中使用的用户和角色的现有数据库架构。 |
| • | 您想要加密消息的一部分，而不是整个数据流。 |
消息级（端对端）安全性
这是一种灵活性最大而且功能最强的方法，GXA 提案（特别是在 WS-Security 规范中）使用的就是这种方法。图 2 阐释了消息级安全性。
图 2. 消息级安全性
WS-Security 规范说明了 SOAP 消息传递的增强功能，这些功能提供了消息完整性、消息机密性以及单次消息身份验证。
| • | 身份验证是由在 SOAP 标头中传递的安全性令牌提供的。 WS-Security 不要求使用任何特定类型的令牌。安全令牌可以包括 Kerberos 票证、X.509 证书或自定义的二进制令牌。 |
| • | 安全通信是通过数字签名提供的，以便确保消息的完整性，并使用 XML 加密以确保消息的机密性。 |
何时使用
可以使用 WS-Security 构建框架以便在异类 Web 服务环境中交换安全消息。它非常适合于不能直接控制终结点和中间应用程序节点配置的异类环境和方案。
消息级安全性：
| • | 可以不依赖于基本传输。 |
| • | 支持异类安全性体系结构。 |
| • | 提供端对端的安全性并通过中间应用程序节点提供消息路由。 |
| • | 支持多项加密技术。 |
| • | 支持不可否认性。 |
Web 服务开发工具包
Web 服务开发工具包提供管理安全性所需的 API 以及路由和消息级检索等其他服务。该工具包符合最新的 Web 服务标准（例如 WS-Security 规范），因此，它支持与采用相同规范的其他供应商之间的互操作性。
更多信息
| • | 有关 Web 服务开发工具包和 WS-Security 规范的最新消息，请参见 MSDN 中的“XML 开发人员中心”页面：http://msdn.microsoft.com/webservices/. |
| • | 有关 GXA 的详细信息，请参见 MSDN 上的文章“Understanding GXA”。 |
| • | 有关该主题的讨论，请参考 MSDN 上的“GXA 互操作性新闻组”。 |
平台／传输安全性体系结构
图 3 显示了 ASP.NET Web 服务平台安全性体系结构。
图 3. Web 服务安全性体系结构
图 3 阐释了 ASP.NET Web 服务提供的身份验证和授权机制。当客户端调用 Web 服务时，将按下列顺序激发身份验证和授权事件：
| 1. | 接收到来自网络的 SOAP 请求。它是否包含身份验证凭证取决于所使用的身份验证类型。 |
| 2. | IIS 可以有选择地使用基本、摘要、集成（NTLM 或 Kerberos）或证书身份验证对调用者进行身份验证。在不能使用 IIS (Windows) 身份验证的异类环境中，可以将 IIS 配置为使用匿名身份验证。在这个方案中，可以使用消息级属性（例如，在 SOAP 标头中传递的票证）对客户端进行身份验证。 |
| 3. | IIS 也可以配置为只接受来自特定 IP 地址的客户端计算机的请求。 |
| 4. | IIS 将已验证的调用者的 Windows 访问令牌传递给ASP.NET （如果将 Web 服务配置为使用匿名身份验证，则它可能是匿名 Internet 用户的访问令牌）。 |
| 5. | ASP.NET 对该调用者进行身份验证。如果将 ASP.NET 配置为使用 Windows 身份验证，则此时不会进行任何其他的身份验证；IIS 对调用者进行身份验证。 如果使用的是非 Windows 身份验证方法，则将 ASP.NET 身份验证模式设置为“无”以使用自定义身份验证。 注Web 服务目前不支持表单和 Passport 身份验证。 |
| 6. | ASP.NET 通过使用 URL 授权和文件授权来授权访问所请求的 Web 服务（.asmx 文件），文件授权使用与 .asmx 文件关联的 NTFS 权限来确定是否将访问权限授予已验证身份的调用者。 注只能将文件授权用于 Windows 身份验证。 对于细分的授权，还可以使用 .NET 角色（以声明方式或编程方式）确保授权调用者访问所请求的 Web 方法。 |
| 7. | Web 服务中的代码可以使用特定标识来访问本地和／或远程资源。在默认情况下，ASP.NET Web 服务不执行任何模拟，因此，配置的 ASP.NET 进程帐户提供该标识。也可以选择原调用者的标识或已配置的服务标识。 |
网关守卫
ASP.NET Web 服务中的网关守卫是：
| • | IIS
可以将 IIS 配置为只允许来自具有特定 IP 地址的计算机的请求。 | ||||
| • | ASP.NET
| ||||
| • | 主体权限要求和明确的角色检查 |
更多信息
| • | 有关网关守卫的详细信息，请参见“ASP.NET 安全性”一章中“ASP.NET 安全性体系结构”部分的“网关守卫”主题。 |
| • | 有关配置安全性的详细信息，请参见本章后面的“配置安全性”。 |
身份验证和授权策略
本节介绍一组常用身份验证方案的可用授权选项（可进行配置和编程）。
下面概述了一些身份验证方案：
| • | 带模拟功能的 Windows 身份验证 |
| • | 不带模拟功能的 Windows 身份验证 |
| • | 使用固定标识的 Windows 身份验证 |
带模拟功能的Windows 身份验证
以下配置元素向您显示了如何明确启用 Web.config 或Machine.config 中的 Windows (IIS) 身份验证和模拟功能。
注 应根据 Web 服务的具体情况，在每个 Web 服务的 Web.config 文件中配置身份验证。
<authentication mode="Windows" /> <identity impersonate="true" />
在此配置中，Web 服务代码模拟已由 IIS 验证身份的调用者。要模拟原调用者，您必须在 IIS 中关闭匿名访问。借助于匿名访问，Web 服务代码可以模拟匿名 Internet 用户帐户（在默认情况下，该帐户为 IUSR_MACHINE）。
可配置的安全设置
当您将 Windows 身份验证和模拟功能一起使用时，就可以使用下列授权选项：
| • | Windows 访问控制列表 (ACL)
| ||||
| • | URL 授权。这是在 Machine.config 和／或 Web.config 中配置的。在 Windows 身份验证中，用户名采用 DomainName/UserName 格式，并且角色与 Windows 组一一对应。 <authorization> <deny user="DomainName/UserName" /> <allow roles="DomainName/WindowsGroup" /> </authorization> |
编程安全性
编程安全性是指您的 Web 服务代码中的安全性检查。在您使用 Windows 身份验证和模拟功能时，可以使用下列程序安全设置选项：
| • | 主体权限要求 命令性（嵌入方法的代码内） PrincipalPermission permCheck = new PrincipalPermission(
null, @"DomainName/WindowsGroup");
permCheck.Demand();
|
| • | 声明性（这些属性可以优先于 Web 方法或 Web 类） // Demand that the caller is a member of a specific role (for Windows
// authentication this is the same as a Windows group)
[PrincipalPermission(SecurityAction.Demand,
Role=@"DomainName/WindowsGroup")]
// Demand that the caller is a specific user
[PrincipalPermission(SecurityAction.Demand,
Name=@"DomainName/UserName")]
|
| • | 明确的角色检查。您可以使用 IPrincipal 接口执行角色检查。 IPrincipal.IsInRole(@"DomainName/WindowsGroup"); |
何时使用
使用 Windows 身份验证和模拟的情况是：
| • | Web 服务的客户端可以通过使用 Windows 帐户来标识，而 Windows 帐户则可以由服务器验证。 |
| • | 您需要通过 Web 服务将原调用者的安全性上下文传递到下一层。例如，传递到一组使用 Enterprise Services (COM+) 角色的服务组件，或传递到需要细化（每用户）授权的数据层。 |
| • | 您需要将原调用者的安全性上下文传递到下游各层以支持操作系统级审核。 |
重要 使用模拟功能可能会降低可扩展性，因为它会影响数据库连接池。作为一个替代方法，可以考虑使用受信任的子系统模型；在该模型中，Web 服务对调用者进行授权并使用固定标识来访问数据库。可以在应用程序级别上传递调用者标识；例如，使用存储过程参数来传递。
更多信息
| • | 有关 Windows 身份验证和模拟的详细信息，请参见“ASP.NET Security”一章。 |
| • | 有关 URL 授权的详细信息，请参见“ASP.NET Security”一章中的“URL 授权注意事项”。 |
不带模拟功能的 Windows 身份验证
下列配置显示了如何在 Web.config 中明确声明启用不带模拟功能的 Windows (IIS) 身份验证。
<authentication mode="Windows" /> <!-- The following setting is equivalent to having no identity element --> <identity impersonate="false" />
可配置的安全性
当您使用不带模拟功能的 Windows 身份验证时，可以使用以下授权选项：
| • | WindowsACL
| ||||
| • | URL 授权 这是在Machine.config 和 Web.config 中配置的。在 Windows 身份验证中，用户名采用 DomainName/UserName 格式，并且角色与 Windows 组一一对应。 <authorization> <deny user="DomainName/UserName" /> <allow roles="DomainName/WindowsGroup" /> </authorization> |
编程安全性
编程安全性是指您的 Web 服务代码中的安全性检查。当您使用不带模拟功能的 Windows 身份验证时，可以使用下列编程安全性选项：
| • | 主体权限要求
| ||||
| • | 明确的角色检查。您可以使用 IPrincipal 接口执行角色检查。 IPrincipal.IsInRole(@"DomainName/WindowsGroup"); |
何时使用
使用不带模拟功能的 Windows 身份验证的情况：
| • | Web 服务的客户端可以通过使用 Windows 帐户来标识，而 Windows 帐户则可以由服务器验证。 |
| • | 您需要使用受信任的子系统模型并且在 Web 服务中对客户端进行授权，然后使用固定标识访问下游资源（例如数据库），从而为连接池提供支持。 |
更多信息
| • | 有关 Windows 身份验证和模拟的详细信息，请参见“ASP.NET 安全性”一章。 |
| • | 有关 URL 授权的详细信息，请参见“ASP.NET 安全性”一章中的“URL 授权注意事项”。 |
使用固定标识的 Windows 身份验证
Web.config 中的 <identity> 元素支持可选的用户名和密码属性，可以使用该元素为 Web 服务配置特定的固定标识以进行模拟。这显示在以下配置文件片段中。
<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“HOW TO: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 Framework 1.1 版会在 Windows 2000 中为此方案进行改进。登录会由 IIS 进程执行，因此 ASP.NET 不需要“充当操作系统的一部分”权限。
更多信息
| • | 有关 Windows 身份验证和模拟的详细信息，请参见“ASP.NET 安全性一章”。 |
| • | 有关 URL 授权的详细信息，请参见“ASP.NET 安全性”一章中的“URL 授权注意事项”。 |
配置安全性
本节说明配置 ASP.NET Web 服务安全性所需的实际步骤。图 4 总结了这些情况。
图 4. 配置 ASP.NET Web 服务安全性
配置 IIS 设置
有关如何配置 IIS 安全设置的详细信息，请参见“ASP.NET 安全性”一章中的“配置安全性”，因为该信息也适用于 ASP.NET Web 服务。
配置 ASP.NET 设置
应用程序级配置设置保存在 Web.config 文件中，该文件位于 Web 服务的虚拟根目录中。请配置以下设置：
| 1. | 配置身份验证。应该在 Web 服务虚拟根目录下的 Web.config 文件中基于每个 Web 服务对它进行设置（而不是在 Machine.config 中）。 <authentication mode="Windows|None" /> 注Web 服务目录不支持 Passport 或表单身份验证。对于自定义和消息级身份验证，请将模式设置为“无”。 |
| 2. | 配置模拟和授权。有关详细信息，请参见“ASP.NET 安全性”一章中的“配置安全性”。 |
更多信息
有关 URL 授权的详细信息，请参见“ASP.NET 安全性”一章中的“URL 授权注意事项”。
保护资源
应该使用“ASP.NET 安全性”一章中介绍的相同方法来保护 Web 资源的安全。另外，对于 Web 服务，应该考虑从生产服务器上的 Machine.config 中删除 HTTP-GET 和 HTTP-POST 协议。
禁用 HTTP-GET、HTTP-POST
默认情况下，客户端可以使用以下三个协议与 ASP.NET Web 服务进行通信：HTTP-GET、HTTP-POST 和 HTTP 上的 SOAP。应该在生产计算机上禁用计算机级别的 HTTP-GET 和 HTTP-POST 协议支持，因为生产计算机不需要这两个协议。这可避免出现潜在的安全隐患，使有害的 Web 页面无法访问在防火墙后面运行的内部 Web 服务。
注禁用这些协议意味着，新客户端将无法使用 Web 服务测试页中的 Invoke 按钮来测试 XML Web 服务。相反，您必须使用 Microsoft Visual Studio_ .NET 开发系统添加对 Web 服务的引用，以便创建一个测试客户端程序。您可能需要在开发计算机上启用这些协议，使开发人员能够使用测试页进行测试。
在整个计算机中禁用 HTTP-GET 和 HTTP-POST 协议
| 1. | 编辑 Machine.config。 |
| 2. | 在 <webServices> 元素中，注释掉 HTTP-GET 和 HTTP-POST 支持的命令行。完成后，Machine.config 应该如下所示。 <webServices>
<protocols>
<add name="HttpSoap"/>
<!-- <add name="HttpPost"/> -->
<!-- <add name="HttpGet"/> -->
<add name="Documentation"/>
</protocols>
</webServices>
|
| 3. | 保存 Machine.config。 注 在特殊情况下，Web 服务客户端使用 HTTP-GET 或 HTTP-POST 与 Web 服务进行通信，您可以在应用程序的 Web.config 文件中添加对这些协议的支持，方法是：创建 <webServices>，然后使用 <protocol> 和 <add> 元素添加对这些协议的支持（如上所示）。 |
更多信息
有关保护资源安全的详细信息，请参见“ASP.NET 安全性”一章中的“配置安全性”。
安全通信
结合使用 SSL 和 IPSec 来保护通信链路的安全。
更多信息
| • | 有关使用 SSL 调用 Web 服务的更多信息，请参见“How To Call a Web Service Using SSL”。 |
| • | 有关在两台计算机之间使用 IPSec 的信息，请参见“How To Use IPSec to Provide Secure Communication Between Two Servers”。 |
将身份验证的凭证传递给 Web 服务
在调用 Web 服务时，您可以使用 Web 服务代理来完成该操作；Web 服务代理是一个本地对象，它公开一组与目标 Web 服务相同的方法。
可以使用 Wsdl.exe 命令行实用工具来生成 Web 服务代理。另外，如果您使用 Visual Studio .NET，则还可以通过在项目中添加 Web 引用来生成代理。
注 对于要为其生成代理的 Web 服务，如果将它配置为需要使用客户端证书，则在添加引用时必须暂时禁用该要求，否则就会出现错误。在添加引用后，必须记住将该服务重新配置为需要使用证书。
另一个方法是给用户应用程序提供脱机的 Web 服务描述语言 (WSDL) 文件。如果 Web 服务接口发生变化，则必须记住对它进行更新。
指定用于 Windows 身份验证的客户端凭证
如果您正在使用 Windows 身份验证，则必须使用 Web 服务代理的 Credentials 属性指定用于身份验证的凭证。如果您没有明确地设置该属性，则无需任何凭证即可调用 Web 服务。如果需要 Windows 身份验证，这会导致出现 HTTP 状态 401，拒绝访问响应。
使用 DefaultCredentials
不能隐式地传递客户端凭证。Web 服务使用者必须在代理上设置凭证和身份验证详细信息。要将客户端的 Windows 安全性上下文（通过模拟线程令牌或进程令牌）传递给 Web 服务，您可以将 Web 服务的 Credentials 属性设置为 CredentialCache. DefaultCredentials （如下所示）。
proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
在使用此方法之前，请注意以下事项：
| • | 仅当使用 NTLM、Kerberos 或协商身份验证时，此方法才传递客户端凭证。 |
| • | 如果客户端应用程序（例如，Windows 表单应用程序）调用 Web 服务，则可以从用户的交互式登录会话中获取凭证。 |
| • | 除非配置了模拟功能（此时，服务器端应用程序使用被模拟的调用者的标识），否则，服务器端应用程序（例如，ASP.NET Web 应用程序）使用进程标识。 |
使用特定凭证
若要在调用 Web 服务时使用一组特定的身份验证凭证，请使用以下代码。
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web service URL
"Negotiate", // Kerberos or NTLM
new NetworkCredential("username", "password", "domainname") );
proxy.Credentials = cache;
在上面的示例中，请求的协商身份验证类型导致 Kerberos 或 NTLM 身份验证。
请求特定的身份验证类型
如以下所述，您应该请求特定的身份验证类型。避免直接使用 NetworkCredential 类，如以下代码所示。
proxy.Credentials = new
NetworkCredential("username", "password", "domainname");
在生产代码中应该避免出现这种情况，因为您无法控制 Web 服务使用的身份验证机制，因此也无法控制使用凭证的方式。
例如，可能期望得到来自服务器的 Kerberos 或 NTLM 身份验证质询，但实际却可能收到一个基本质询。在这种情况下，会以明文形式将提供的用户名和密码发送到服务器。
设置 PreAuthenticate 属性
可以将代理的 PreAuthenticate 属性设置为 true 或 false。将其设置为 true 可以提供特定的身份验证凭证，以便通过 Web 请求传递 WWW-authenticate HTTP 标头。这可以避免 Web 服务器拒绝请求的访问，并在后续重试请求中执行身份验证。
注 仅当 Web 服务第一次成功地进行身份验证后，才能使用预身份验证。预身份验证对第一次 Web 请求没有任何影响。
private void ConfigureProxy( WebClientProtocol proxy,
string domain, string username,
string password )
{
// To improve performance, force pre-authentication
proxy.PreAuthenticate = true;
// Set the credentials
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
"Negotiate",
new NetworkCredential(username, password, domain) );
proxy.Credentials = cache;
proxy.ConnectionGroupName = username;
}
使用 ConnectionGroupName 属性
注意，上述代码设置 Web 服务代理的 ConnectionGroupName 属性。仅当用于连接 Web 服务的安全性上下文根据不同请求发生变化时，才需要使用该属性（如下所述）。
如果 ASP.NET Web 应用程序连接到 Web 服务并传递原调用者的安全性上下文（通过使用 DefaultCredentials 或者设置显式凭证，如上所示），则应该在 Web 应用程序中设置 Web 服务代理的 ConnectionGroupName 属性。这可防止未验证身份的新客户端重用到 Web 服务（该服务与以前的客户端身份验证凭证关联）的已验证身份的旧 TCP 连接。在使用 HTTP KeepAlives 或出于 IIS 的性能考虑而启用身份验证持续功能时，会出现连接重用。
将 ConnectionGroupName 属性设置为能够区分调用者的标识符（例如调用者的用户名），如上面的代码片段所示。
注如果没有通过 Web 应用程序将原调用者的安全性上下文传递给 Web 服务，而是，Web 应用程序使用固定标识（例如，Web 应用程序的 ASP.NET 进程标识）连接到 Web 服务，则不需要设置 ConnectionGroupName 属性。在此方案中，连接安全性上下文在从一个调用者传递到下一个调用者时，保持不变。
从非 Windows 客户端调用 Web 服务
可以将多种身份验证方法用于跨浏览器的方案中。它们是：
| • | 证书身份验证。使用跨平台的 X.509 证书。 |
| • | 基本身份验证。有关如何根据自定义数据存储使用基本身份验证（不需要使用 Active Directory）的示例，请参见 http://www.rassoc.com/gregr/weblog/stories/2002/06/26/webServicesSecurityHttpBasicAuthenticationWithoutActiveDirectory.html。 |
| • | GXA 消息级方法。使用 Web 服务开发工具包来实现 GXA (WS-Security) 解决方案。 |
| • | 自定义方法。例如，在 SOAP 标头中传递凭证。 |
代理服务器身份验证
Visual Studio .NET 的 添加Web引用 对话框不支持代理服务器身份验证（但是，下一版本的 Visual Studio .NET 对它提供支持）。因此，在添加 Web 引用时，可能会出现 HTTP 状态 407 响应：“需要代理验证”。
注 通过浏览器查看 .asmx 文件时，可能看不到此错误，因为浏览器自动发送凭证。
要解决这个问题，可以使用 Wsdl.exe 命令行实用工具（而不是 添加Web引用对话框），如下所示。
wsdl.exe /proxy:http:// /pu: /pp: /pd: http://www.YouWebServer.com/YourWebService/YourService.asmx
如果您需要以编程方式设置代理服务器身份验证信息，请使用以下代码。
YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;
传送原调用者
本节介绍如何通过 ASP.NET Web 应用程序将原调用者的安全性上下文传递给远程应用程序服务器上的 Web 服务。要在 Web 服务或后续下游子系统（例如，数据库，您要在其中授权原调用者访问个别数据库对象）中执行每用户授权，您需要完成此操作。
在图 5 中，通过驻留 ASP.NET Web 应用程序的前端 Web 服务器将原调用者 (Alice) 的安全性上下文传递给远程应用程序服务器上 ASP.NET 驻留的远程对象，并最终将其传递到后端数据库服务器。
图 5. 传递原调用者的安全性上下文
为了向 Web 服务传递凭证，Web 服务客户端（此方案中的 ASP.NET Web 应用程序）必须配置 Web 服务代理，并明确地设置该代理的 Credentials 属性，如本章前面的“将身份验证的凭证传递给 Web 服务”所述。
可以使用两种方法来传递调用者的上下文。
| • | 传递默认凭证并使用 Kerberos 身份验证（和委派）。该方法要求您在 ASP.NET Web 应用程序内使用模拟，并用从被模拟调用者的安全性上下文中获得 DefaultCredentials 来配置远程对象代理。 |
| • | 传递显式凭证并使用基本身份验证或表单身份验证。该方法不要求在 ASP.NET Web 应用程序内使用模拟。相反，您可以通过编程方式，使用从给 Web 应用程序提供的服务器变量（利用基本身份验证）或 HTML 表单字段（利用表单身份验证）中获取的显式凭证来配置 Web 服务代理。可以使用基本身份验证或表单身份验证，以明文形式给服务器提供用户名和密码。 |
带有 Kerberos 委派的默认凭证
要使用 Kerberos 委派，所有计算机（服务器和客户端）都必须运行 Windows 2000 或更高版本。此外，必须将要委派的客户端帐户存储在 Active Directory 中，并且不能将其标记为“敏感用户，不能被委派”。
以下表格显示了在 Web 服务器和应用程序服务器上需要执行的配置步骤。
| 配置 Web 服务器 | |
| 配置 IIS | |
| 步骤 | 更多信息 |
| 禁用对 Web 应用程序的虚拟根目录的匿名访问 |
|
| 配置 ASP.NET | |
| 步骤 | 更多信息 |
| 将 ASP.NET Web 应用程序配置为使用 Windows 身份验证 | 编辑 Web 应用程序的虚拟目录下的 Web.config <authentication mode="Windows" /> |
| - | - |
| - | 配置 ASP.NET Web 应用程序的模拟 |
| 编辑 Web 应用程序的虚拟目录下的 Web.config | - <identity impersonate="true" /> |
| 配置 Web 服务代理 | |
| 步骤 | 更多信息 |
| 将 Web 服务代理的凭证属性设置为 DefaultCredentials。 | 有关代码示例，请参见本章前面的“使用 DefaultCredentials”。 |
| 配置远程应用程序服务器 | |
| 配置 IIS | |
| 步骤 | 更多信息 |
| 禁用对 Web 服务的虚拟根目录的匿名访问 | |
| 配置 ASP.NET （Web 服务主机） | |
| 步骤 | 更多信息 |
| 将 ASP.NET 配置为使用 Windows 身份验证 | 编辑 Web 服务的虚拟目录下的 Web.config 文件。 |
| 配置 ASP.NET 的模拟功能 | 编辑 Web 服务的虚拟目录下的 Web.config 文件。 注： 只有当您想将原调用者的安全性上下文通过 Web 服务传递给下一个下游子系统（例如数据库）时，才需要执行本步骤。如果在此处启用了模拟功能，资源访问（本地和远程）就会使用模拟的原调用者的安全性上下文。 |
更多信息
有关配置 Kerberos 委派的更多信息，请参见“How To Implement Kerberos Delegation for Windows 2000”。
带有基本身份验证或表单身份验证的显式凭证
作为 Kerberos 委派的一个替代方法，您可以在 Web 应用程序中使用基本身份验证或表单身份验证来捕获客户端凭证，然后对 Web 服务使用基本身份验证（或者集成 Windows 身份验证）。
利用此方法，Web 应用程序可以使用客户端的明文凭证。可通过 Web 服务代理将这些凭证传递给 Web 服务。为此，必须在 Web 应用程序中编写代码来检索客户端凭证并配置代理。
基本身份验证
使用基本身份验证，Web 应用程序可在服务器变量中使用原调用者的凭证。以下代码说明如何检索凭证并配置 Web 服务代理。
// Retrieve client's credentials (available with Basic authentication)
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// Associate the credentials with the Web service proxy
// To improve performance, force preauthentication
proxy.PreAuthenticate = true;
// Set the credentials
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
"Basic",
new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;
表单身份验证
使用表单身份验证，Web 应用程序可在表单各个字段中（而不是在服务器变量中）使用原调用者的凭证。在这种情况下，请使用以下代码。
// Retrieve client's credentials from the logon form
string pwd = txtPassword.Text;
string uid = txtUid.Text;
// Associate the credentials with the Web service proxy
// To improve performance, force preauthentication
proxy.PreAuthenticate = true;
// Set the credentials
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
"Basic",
new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;
以下各表显示了在 Web 服务器和应用程序服务器上需要执行的配置步骤。
| 配置 Web 服务器 | |
| 配置 IIS | |
| 步骤 | 更多信息 |
| 要使用基本身份验证，请禁用对 Web 应用程序的虚拟根目录的匿名访问，并选择基本身份验证 | 基本身份验证和表单身份验证都应和 SSL 配合使用，才能保护通过网络传送的明文凭证。如果您使用基本身份验证，则应该将 SSL 用于所有页面（而不仅仅是初始登录页面），因为在每个请求中都传递基本身份验证凭证。 |
| 配置 ASP.NET | |
| 步骤 | 更多信息 |
| 如果您使用基本身份验证，请将您的 ASP.NET Web 应用程序配置为使用 Windows 身份验证 | 编辑 Web 应用程序的虚拟目录下的 Web.config |
| 禁用 ASP.NET Web 应用程序中的模拟 | 编辑 Web 应用程序的虚拟目录中的 Web.config。 注： 这相当于没有 <identity> 元素。 |
| 配置 Web 服务代理 | |
| 步骤 | 更多信息 |
| 编写代理以便在 Web 服务代理中捕获和明确地设置凭证 | 请参考前面的“基本身份验证”和“表单身份验证”部分中显示的代码片段。 |
| 配置应用程序服务器 | |
| 配置 IIS | |
| 步骤 | 更多信息 |
| 禁用对应用程序的虚拟根目录的匿名访问 |
|
| 配置 ASP.NET（Web 服务） | |
| 步骤 | 更多信息 |
| 将 ASP.NET 配置为使用 Windows 身份验证 | 编辑 Web 服务的虚拟目录下的 Web.config。 |
| 将 ASP.NET Web 服务配置为使用模拟 | 编辑 Web 服务的虚拟目录下的 Web.config。 注： 只有当您想将原调用者的安全性上下文通过 Web 服务传递给下一个下游子系统（例如数据库）时，才需要执行本步骤。如果在此处启用了模拟功能，资源访问（本地和远程）就会使用模拟的原调用者的安全性上下文。 |
受信任的子系统
受信任的子系统模型提供一种替代（且更易于实现的）方法来传递原调用者的安全性上下文。在该模型中，Web 服务和 Web 应用程序之间存在信任边界。Web 服务首先信任 Web 应用程序对调用者正确地进行身份验证和授权，然后才允许其向 Web 服务发送请求。在 Web 服务中，不对原调用者进行任何身份验证。Web 服务对 Web 应用程序用来与 Web 服务通信的固定受信任标识进行身份验证。在大多数情况下，这是 ASP.NET 辅助进程的进程标识。
图 6 显示了受信任的子系统模型。
图 6. 受信任的子系统模型
传递调用者的标识
如果您使用的是受信任的子系统模型，则可能仍然需要传送原调用者的标识（名称，而不是安全性上下文），例如，用于在数据库中进行审核。
通过使用可用于从数据库检索用户特定数据的方法、存储过程参数和受信任的查询参数（如下面的示例所示），可以在应用程序级传送该标识。
SELECT x,y,z FROM SomeTable WHERE UserName = "Alice"
配置步骤
以下各表显示了在 Web 服务器和应用程序服务器上需要执行的配置步骤。
| 配置 Web 服务器 | |
| 配置 IIS | |
| 步骤 | 更多信息 |
| 配置 IIS 身份验证 | Web 应用程序可以使用任何形式的验证方法来验证原调用者。 |
| 配置 ASP.NET | |
| 步骤 | 更多信息 |
| 配置身份验证并确保禁用模拟功能 | 编辑 Web 应用程序的虚拟目录下的 Web.config。 将 <identity> 元素设置为： （或删除 <identity> 元素） |
| 重置用于运行 ASP.NET 的 ASPNET 帐户的密码，或者创建一个权限最少的域帐户来运行ASP.NET，并在 Web.config 中的 <processModel> 元素上指定帐户详细信息 | 有关如何从 ASP.NET 访问网络资源（包括 Web 服务）以及选择和配置 ASP.NET 进程帐户的详细信息，请参见“ASP.NET 安全性”一章中的“访问网络资源”和“ASP.NET 的进程标识”。 |
| 配置 Web 服务代理 | |
| 步骤 | 更多信息 |
| 配置 Web 服务代理，以便将默认凭证用于 Web 服务的所有调用 | 使用以下代码行： proxy.Credentials = DefaultCredentials; |
| 配置应用程序服务器 | |
| 配置 IIS | |
| 步骤 | 更多信息 |
| 禁用对 Web 服务的虚拟根目录的匿名访问 | |
| 配置 ASP.NET | |
| 步骤 | 更多信息 |
| 将 ASP.NET 配置为使用 Windows 身份验证 | 编辑 Web 服务的虚拟目录下的 Web.config。 <authentication mode="Windows" /> |
| 禁用模拟 | 编辑应用程序的虚拟目录下的 Web.config。 |
访问系统资源
有关从 ASP.NET Web 服务访问系统资源（例如，事件日志和注册表（的详细信息，请参见“ASP.NET 安全性”一章中的“访问系统资源”。该章讨论的方法和限制也适用于 ASP.NET Web 服务。
访问网络资源
在从 Web 服务访问网络资源时，您需要考虑用于响应来自远程计算机的网络身份验证质询的标识。您有三个选项：
| • | 进程标识（由用于运行 ASP.NET 辅助进程的帐户确定） |
| • | 服务标识（例如，通过调用 LogonUser 创建的标识） |
| • | 原调用者标识（带有为模拟配置的 Web 服务） |
有关每种方法的相对优点的详细信息，请参见“ASP.NET 安全性”一章中的“访问网络资源”。
访问 COM 对象
Web 服务不能使用 AspCompat 指令（由 Web 应用程序在调用单元线程 COM 对象时使用）。这意味着，在从 Web 服务调用单元模型对象时，就会发生线程转换。这会对性能造成轻微的影响，如果 Web 服务使用模拟功能，则在调用 COM 组件时将会丢失模拟令牌。这通常导致出现“拒绝访问”异常错误。
更多信息
| • | 有关在调用单元线程 COM 对象时出现“拒绝访问”异常错误的更多信息，请参见 Microsoft 知识库文章 Q325791“PRB:Access Denied Error Message Occurs When You Impersonating an Account in ASP.NET and Then Call STA COM Components”。 |
| • | 有关访问 COM 对象和使用 AspCompat 属性的更多信息，请参见“ASP.NET 安全性”一章中的“访问 COM 对象”。 |
| • | 有关从 Web 服务调用单元进程 COM 对象的更多信息，请参见 Microsoft 知识库文章 Q303375“INFO:XML Web Services and Apartment Objects”。 |
将客户端证书用于 Web 服务
本节介绍在 Web 服务身份验证中使用 X.509 客户端证书的方法。
可以在 Web 服务中使用客户端证书身份验证来验证：
| • | 其他 Web 服务。 |
| • | 与 Web 服务直接进行通信的应用程序（例如，基于服务器或客户端的桌面应用程序）。 |
使用证书对 Web 浏览器客户端进行身份验证
Web 服务不能使用客户端证书验证调用者是否与中间 Web 应用程序交互，因为无法将原调用者的证书通过 Web 应用程序传递给 Web 服务。虽然 Web 应用程序可以使用证书对其客户端进行身份验证，但 Web 服务无法使用相同的证书进行身份验证。
这种服务器到服务器的方案失败的原因在于，Web 应用程序无法访问其证书存储中的客户端证书（特别是其私钥）。图 7 说明了这个问题。
图 7. Web 服务客户端证书身份验证
使用受信任的子系统模型
要消除上述限制并在 Web 服务中支持证书身份验证，必须使用受信任的子系统模型。通过使用这种方法，Web 服务可以使用 Web 应用程序的证书（而不是原调用者的证书）对 Web 应用程序进行身份验证。Web 服务必须信任 Web 应用程序对其用户进行身份验证并进行必要的授权，确保只有经过授权的调用者才能够访问 Web 服务提供的数据和功能。
图 8 显示了这种方法。
图 8. Web 服务对受信任的 Web 应用程序进行身份验证
如果 Web 服务中的授权逻辑需要多个角色，则 Web 应用程序可以根据调用者的角色成员身份来发送不同的证书。例如，可以对管理员组的成员使用一个证书（允许他们在后端数据库中更新数据）；而对所有其他用户使用另一个证书（只授予他们“读”操作权限）。
注 在此类方案中，本地证书服务器（只能通过两个服务器访问）可用于管理所有的 Web 应用程序证书。
在这个方案中：
| • | Web 应用程序使用客户端证书对其用户进行身份验证。 |
| • | Web 应用程序充当网关守卫，对其用户进行授权以及控制对 Web 服务的访问。 |
| • | Web 应用程序调用 Web 服务并传递另一个代表该应用程序的证书（也可能是基于调用者角色成员身份的一组证书）。 |
| • | Web 服务对 Web 应用程序进行身份验证，然后信任该应用程序执行必要的客户端授权。 |
| • | 在 Web 应用程序服务器和 Web 服务服务器之间，使用 IPSec 提供额外的访问控制。IPSec 禁止通过其他计算机进行未经授权的访问。Web 服务服务器上的证书身份验证也可以防止未经授权的访问。 |
解决方案实现
在此方案中，要在 Web 服务中使用证书身份验证，请使用单独的进程来调用 Web 服务和传递证书。您无法从 ASP.NET Web 应用程序中直接使用证书，因为它没有加载用户配置文件及其相关的证书存储。必须将此单独的进程配置为使用具有相关用户配置文件（和证书存储）的帐户来运行。您有两个主要的选项：
| • | 使用 Enterprise Services 服务器应用程序 |
| • | 使用 Windows 服务。 |
图 9 说明了包含 Enterprise Services 服务器应用程序的方案。
图 9. Web 服务中的客户端证书身份验证
下面概述了图 9 中说明的事件顺序：
| 1. | Web 应用程序使用客户端证书对原调用者进行身份验证。 |
| 2. | Web 应用程序充当网关守卫，并且负责授权访问特定范围的功能（包括那些与 Web 服务进行交互的功能）。 |
| 3. | Web 应用程序调用在进程外 Enterprise Services 中运行的服务组件。 |
| 4. | 用于运行 Enterprise Services 应用程序的帐户具有相关的用户配置文件。该组件访问其证书存储中的客户端证书，Web 服务使用该证书对 Web 应用程序进行身份验证。 |
| 5. | 服务组件调用 Web 服务，并根据每个方法请求传递客户端证书。Web 服务使用该证书对 Web 应用程序进行身份验证，然后信任 Web 应用程序正确地向原调用者进行授权。 |
为什么使用其他进程？
由于需要用户配置文件（包含证书存储），因此要求使用其他进程（而不是使用 Aspnet_wp.exe Web 进程与 Web 服务建立联系）。
使用 ASPNET 帐户运行的 Web 应用程序没有访问 Web 服务器上任何证书的权限。这是因为，证书存储保存在与交互式用户帐户相关的用户配置文件中。仅当使用交互式帐户进行实际登录时，才会为该帐户创建用户配置文件。不能将 ASPNET 帐户用于交互式用户帐户；可以给其配置“拒绝交互式登录”权限以提高安全性。
重要 不要重新配置 ASPNET 帐户以删除此权限并将该帐户转换为交互式登录帐户。请使用配置的服务帐户运行单独的进程来访问证书，如本章前面所述。
更多信息
| • | 有关如何实现此方法的更多信息，请参见“How To Call a Web Service Using Client Certificates from ASPNET”。 |
| • | 有关配置 IPSec 的更多信息，请参见“How To Use IPSec to Provide Secure Communication Between Two Servers”。 |
安全通信
安全通信是指通过网络在应用程序之间传送 Web 服务消息时确保消息的完整性和机密性。可以使用两种方法来解决这个问题：传输级选项和消息级选项。
传输级选项
传输级选项包括：
| • | SSL |
| • | IPSec |
如果满足以下条件，则可以使用这些选项：
| • | 直接从应用程序向 Web 服务发送消息，并且不通过中间系统传递消息。 |
| • | 可以控制参与消息传输的两个终结点的配置。 |
消息级选项
消息级方法可以确保消息通过任意数量的中间系统传递时的机密性和完整性。可以对消息进行签名以提供完整性。为了保证机密性，您可以选择加密整个消息或消息的一部分。
如果符合以下条件，则可以使用消息级方法：
| • | 您向 Web 服务发送消息，并且可能会将消息转发到其他 Web 服务，或者通过中间系统进行传递。 |
| • | 您无法控制两个终结点的配置，例如，您从一个公司向另一个公司发送消息。 |
更多信息
| • | Web 服务开发工具包提供符合 WS-Security 规范的消息加密功能。 |
| • | 有关 SSL 和 IPSec 的更多信息，请参见第 4 章“安全通信”。 |
小结
本章重点介绍了 ASP.NET、IIS 和操作系统的基本服务提供的平台／传输级（点对点）Web 服务安全性。虽然平台级安全性为紧密集成的 Intranet 应用提供了安全的解决方案，但它不适用于异类环境。为此，需要使用 GXA WS-Security 规范提供的消息级安全性。可以使用 Web 服务开发工具包来开发消息级 Web 服务安全性解决方案。
对于紧密集成的 Windows 域环境：
| • | 如果您要将原调用者的标识从 ASP.NET Web 应用程序传递给远程 Web 服务，则 ASP.NET Web 应用程序应该使用 Kerberos 身份验证（将帐户配置为使用委派）、基本身份验证或表单身份验证。
|
对于 Web 服务到 Web 服务的方案：
| • | 使用基本身份验证或 Kerberos 身份验证，并在客户端代理中设置凭证。 |
| • | 使用进程外 Enterprise Services 应用程序或 Windows 服务来使用来自 Web 应用程序的X.509 证书。 |
| • | 尽可能地使用系统级授权检查（例如文件授权和 URL 授权）。 |
| • | 对于细分的授权（例如，在 Web 方法级上），请使用 .NET 角色（通过声明性方式和命令性方式）。 |
| • | 使用 .NET 角色来授权非 Windows 用户（基于包含角色的 GenericPrincipal 对象）。 |
| • | 在生产服务器上禁用 HTTP-GET 和 HTTP-POST 协议。 |
| • | 如果不担心通过中间系统安全地传递消息的问题，请使用传输级安全性。 |
| • | 如果 SSL 性能可以接受，请使用传输级安全性。 |
| • | 使用 WS-Security 和 Web 服务开发工具包来开发消息级解决方案。 |
扫一扫
5814
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
