第 10 章 - Web 服务安全性

本页内容

	本章内容
	目标
	适用范围
	如何使用本章内容
	Web 服务安全模型
	平台/传输安全体系结构
	身份验证和授权策略
	配置安全性
	将身份验证的凭据传递给 Web 服务
	传递原调用方
	访问系统资源
	访问网络资源
	访问 COM 对象
	将客户端证书用于 Web 服务
	安全通信
	总结

本章内容

由于使用了灵活的开放标准，所以 Web 服务成为一种绝佳机制，通过它可以向客户端提供各种功能并驻留前端 Web 服务器所访问的中间层业务逻辑。但是，由于存在标准限制且 Web 服务需要支持多种类型的客户端，所以保护 Web 服务的安全可能极具挑战性。

本章介绍了如何开发和应用身份验证、授权和安全通信技术，以保护 ASP.NET Web 服务的安全。在简要介绍了传输/平台、应用程序和消息级这三个关键的 Web 服务安全模型后，本章详细讨论了实现 ASP.NET Web 服务的传输/平台级安全性的各种可用选项和过程。

返回页首

目标

本章的目标是：

返回页首

适用范围

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

返回页首

如何使用本章内容

若要学好本章内容：

返回页首

Web 服务安全模型

可以在三个级别应用 Web 服务安全性：

每一种方法都具有各自的优缺点，这些会在下面详细地说明。选择哪一种方法在很大程度上取决于消息交换中所涉及的体系结构和平台的特点。

注意：本章着重讨论平台和应用程序级安全性。消息级安全性将在全局 XML Web 服务体系结构 (GXA) 提案中以及专门在 WS-Security 规范中进行介绍。在编写本指南时，Microsoft 刚刚发布了 Web 服务开发工具包的技术预览版本。它可用于开发符合 WS-Security 规范的消息级安全性解决方案。有关详细信息，请参见 http://msdn.microsoft.com/webservices/building/wse/。

平台/传输级（点对点）安全性

两个终结点之间的传输通道（Web 服务客户端和 Web 服务）可以用于提供点对点的安全性。图 10.1 中说明了这种情况。

图 10.1
平台/传输级安全性

当您使用平台级安全性时（它假定在公司 Intranet 上安装了紧密集成的 Microsoft® Windows® 操作系统环境）：

何时使用

传输级安全模型简单明了，并且可用于许多（主要是基于 Intranet 的）方案；在这些方案中，可以严格地控制传输机制和终结点配置。

传输级安全性的主要问题有：

应用程序级安全性

使用这种方法时，应用程序负责提供安全性并使用自定义的安全功能。例如：

何时使用

在以下时候使用此方法：

消息级（端对端）安全性

这是一种灵活性最大而且功能最强的方法，GXA 提案（特别是在 WS-Security 规范中）使用的就是这种方法。图 10.2 说明了消息级安全性。

图 10.2
消息级安全性

WS-Security 规范说明了 SOAP 消息传递的增强功能，这些功能提供了消息完整性、消息机密性以及单次消息身份验证。

何时使用

可以使用 WS-Security 构造框架以便在异类 Web 服务环境中交换安全消息。它非常适合于不能直接控制终结点和中间应用程序节点配置的异类环境和方案。

消息级安全性：

Web 服务开发工具包

Web 服务开发工具包提供管理安全性所需的 API 以及路由和消息级检索等其他服务。该工具包符合最新的 Web 服务标准（例如 WS-Security 规范），因此，它支持与遵守相同规范的其他供应商之间的互操作性。

更多信息

返回页首

平台/传输安全体系结构

图 10.3 显示了 ASP.NET Web 服务的平台安全体系结构。

图 10.3
Web 服务安全体系结构

图 10.3 说明了 ASP.NET Web 服务提供的身份验证和授权机制。当客户端调用 Web 服务时，将按下列顺序激发身份验证和授权事件：

网关守卫

ASP.NET Web 服务中的网关守卫是：

更多信息

返回页首

身份验证和授权策略

本节介绍了一些常用身份验证方案的可用授权选项（可进行配置和编程）。

下面汇总了一些身份验证方案：

带模拟功能的 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 身份验证和模拟功能一起使用时，可以使用下列授权选项：

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

编程安全性

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

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

// 要求调用方是特定角色的成员（对于 Windows
// 身份验证，这一点与 Windows 组相同）
[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName\WindowsGroup")]
// 要求调用方是特定用户
[PrincipalPermission(SecurityAction.Demand, 
                  Name=@"DomainName\UserName")]

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

何时使用

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

重要说明：使用模拟功能可能会降低可伸缩性，因为它会影响数据库连接池。作为一个替代方法，可以考虑使用受信任的子系统模型；在该模型中，Web 服务对调用方授权并使用固定标识来访问数据库。可以在应用程序级传递调用方标识；例如，使用存储过程参数来传递。

更多信息

不带模拟功能的 Windows 身份验证

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

<authentication mode="Windows" />
<!-- 以下设置等价于没有标识元素 -->
<identity impersonate="false" />

可配置的安全性

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

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

编程安全性

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

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

// 要求调用方是特定角色的成员（对于 Windows
// 身份验证，这一点与 Windows 组相同）
[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName\WindowsGroup")]
// 要求调用方是特定用户
[PrincipalPermission(SecurityAction.Demand, 
                  Name=@"DomainName\UserName")]  

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

何时使用

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

更多信息

使用固定标识的 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（HOW TO：使用 ASP.NET 工具加密凭据和会话状态连接字符串）。

何时使用

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

注意：.NET Framework 1.1 会在 Windows 2000 上提供这个方案的增强功能。登录将由 IIS 进程执行，这样一来，ASP.NET 就不需要“作为操作系统的一部分”特权。

更多信息

返回页首

配置安全性

本节说明配置 ASP.NET Web 服务安全性所需的实际步骤。图 10.4 中总结了这些情况。

图 10.4
配置 ASP.NET Web 服务安全性

配置 IIS 设置

有关如何配置 IIS 安全设置的详细信息，请参见第 8 章 ASP.NET 安全性中的配置安全性，因为该信息也适用于 ASP.NET Web 服务。

配置 ASP.NET 设置

应用程序级配置设置保存在 Web.config 文件中，该文件位于 Web 服务的虚拟根目录中。请配置下列设置：

<authentication mode="Windows|None" />

更多信息

有关 URL 授权的详细信息，请参见第 8 章 ASP.NET 安全性中的 URL 授权注意事项。

保护资源安全

应使用第 8 章 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 服务测试页中的“调用”按钮来测试 XML Web 服务。相反，您必须使用 Microsoft Visual Studio® .NET 开发系统添加对 Web 服务的引用，以便创建一个测试客户端程序。您可能需要在开发计算机上启用这些协议，使开发人员能够使用测试页进行测试。

<webServices>
    <protocols>
      <add name="HttpSoap"/> 
         <!-- <add name="HttpPost"/> --> 
         <!-- <add name="HttpGet"/>  -->
      <add name="Documentation"/> 
    </protocols>
</webServices>

注意：在特殊情况下，Web 服务客户端需要使用 HTTP-GET 或 HTTP-POST 与 Web 服务进行通信，此时您可以在应用程序的 Web.config 文件中添加对这些协议的支持，方法是：创建 <webServices>，然后使用 <protocol> 和 <add> 元素添加对这些协议的支持（如上所示）。

更多信息

有关保护资源安全的详细信息，请参见第 8 章 ASP.NET 安全性中配置安全性一节中的保护资源安全主题。

安全通信

结合使用 SSL 和 IPSec 以保护通信链路的安全。

更多信息

返回页首

将身份验证的凭据传递给 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;

在使用此方法之前，请注意以下事项：

使用特定凭据

若要在调用 Web 服务时使用一组特定的身份验证凭据，请使用以下代码：

CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web 服务 URL
           "Negotiate",        // Kerberos 或 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 )
{
  // 为提高性能，强制预先身份验证
  proxy.PreAuthenticate = true;
  // 设置凭据
  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 服务

可以将多种身份验证方法用于跨浏览器的方案中，其中包括：

代理服务器身份验证

Visual Studio .NET 的“添加 Web 引用”对话框不支持代理服务器身份验证（但是，下一版本的 Visual Studio .NET 中对它提供支持）。因此，在添加 Web 引用时，可能会出现 HTTP 状态 407 响应：“需要代理服务器身份验证”。

注意：在从浏览器查看 .asmx 文件时，可能看不到此错误，因为浏览器自动发送凭据。

要解决这个问题，可以使用 Wsdl.exe 命令行实用程序（而不是“添加 Web 引用”对话框），如下所示：

wsdl.exe /proxy:http://<YourProxy> /pu:<YourName> /pp:<YourPassword>
/pd:<YourDomain> http://www.YouWebServer.com/YourWebService/YourService.asmx

如果您需要以编程方式设置代理服务器身份验证信息，请使用以下代码：

YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;

返回页首

传递原调用方

本节介绍如何通过 ASP.NET Web 应用程序将原调用方的安全性上下文传递给远程应用程序服务器上的 Web 服务。要在 Web 服务或后续下游子系统（例如数据库，您要在其中授权原调用方访问个别数据库对象）中执行每用户的授权，您需要完成此操作。

在图 10.5 中，通过驻留 ASP.NET Web 应用程序的前端 Web 服务器将原调用方（王丽）的安全性上下文传递给远程应用程序服务器上 ASP.NET 驻留的远程对象，并最终将其传递给后端数据库服务器。

图 10.5
传递原调用方的安全性上下文

为了向 Web 服务传递凭据，Web 服务客户端（此方案中的 ASP.NET Web 应用程序）必须配置 Web 服务代理，并明确地设置该代理的 Credentials 属性。有关说明，请参见本章前面的将身份验证的凭据传递给 Web 服务。

可以使用两种方法来传递调用方的上下文：

使用 Kerberos 委派的默认凭据

要使用 Kerberos 委派，所有计算机（服务器和客户端）都必须运行 Windows 2000 或更高版本。此外，必须将要委派的客户端帐户存储在 Active Directory 中，并且不能将其标记为“敏感帐户，不能被委派”。

以下各表显示了在 Web 服务器和应用程序服务器上需要执行的配置步骤。

配置 Web 服务器

<authentication mode="Windows" />

<identity impersonate="true" />

配置远程应用程序服务器

<authentication mode="Windows" />

<identity impersonate="true" />

更多信息

有关配置 Kerberos 委派的详细信息，请参见本指南中的如何为 Windows 2000 实现 Kerberos 委派。

使用基本身份验证或窗体身份验证的显式凭据

作为 Kerberos 委派的一个替代方法，您可以在 Web 应用程序中使用基本身份验证或窗体身份验证来捕获客户端凭据，然后对 Web 服务使用基本身份验证（或集成 Windows 身份验证）。

利用此方法，Web 应用程序可以使用客户端的明文凭据。可通过 Web 服务代理将这些凭据传递给 Web 服务。为此，必须在 Web 应用程序中编写代码以检索客户端凭据并配置代理。

基本身份验证

使用基本身份验证时，Web 应用程序可从服务器变量中获取原调用方的凭据。以下代码说明如何检索凭据并配置 Web 服务代理：

// 检索客户端的凭据（可通过基本身份验证进行）
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// 将凭据与 Web 服务代理相关联
// 为提高性能，强制预先身份验证
proxy.PreAuthenticate = true;
// 设置凭据
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",     
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

窗体身份验证

使用窗体身份验证时，Web 应用程序可从窗体各个字段中（而不是服务器变量中）获取原调用方的凭据。在这种情况下，请使用以下代码：

// 从登录窗体检索客户端的凭据
string pwd = txtPassword.Text;
string uid = txtUid.Text;
// 将凭据与 Web 服务代理相关联
// 为提高性能，强制预先身份验证
proxy.PreAuthenticate = true;
// 设置凭据
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",     
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

以下各表显示了在 Web 服务器和应用程序服务器上需要执行的配置步骤。

配置 Web 服务器

<authentication mode="Windows" />

<authentication mode="Forms" />

<identity impersonate="false" />

配置应用程序服务器

<authentication mode="Windows" />

<identity impersonate="true" />

受信任的子系统

受信任的子系统模型提供了一种替代（且更易于实现的）方法来传递原调用方的安全性上下文。在该模型中，Web 服务和 Web 应用程序之间存在信任边界。Web 服务首先信任 Web 应用程序对调用方正确地进行身份验证和授权，然后才允许向 Web 服务发送请求。在 Web 服务中，不对原调用方进行任何身份验证。Web 服务对 Web 应用程序用来与 Web 服务通信的固定受信任标识进行身份验证。在大多数情况中，这是 ASP.NET 辅助进程的进程标识。

受信任的子系统模型如图 10.6 所示。

图 10.6
受信任的子系统模型

传递调用方标识

如果您使用的是受信任的子系统模型，则可能仍然需要传递原调用方的标识（名称，不是安全性上下文），例如，用于在数据库中进行审核。

通过使用可用于从数据库检索用户特定数据的方法、存储过程参数和受信任的查询参数（如下面的示例所示），可以在应用程序级传递该标识。

SELECT x,y,z FROM SomeTable WHERE UserName = "Alice"

配置步骤

以下各表显示了在 Web 服务器和应用程序服务器上需要执行的配置步骤。

配置 Web 服务器

配置应用程序服务器

返回页首

访问系统资源

有关从 ASP.NET Web 服务访问系统资源（例如，事件日志和注册表）的详细信息，请参见第 8 章 ASP.NET 安全性中的访问系统资源。第 8 章中介绍的方法和限制也适用于 ASP.NET Web 服务。

返回页首

访问网络资源

在从 Web 服务访问网络资源时，您需要考虑用于响应来自远程计算机的网络身份验证质询的标识。您有三个选项：

有关每种方法相对优势的详细信息以及配置详细信息，请参见第 8 章 ASP.NET 安全性中的访问网络资源。

返回页首

访问 COM 对象

Web 服务不能使用 AspCompat 指令（由 Web 应用程序在调用单元线程 COM 对象时使用）。这意味着，在从 Web 服务调用单元模型对象时会发生线程转换。这会对性能造成轻微的影响，如果 Web 服务使用模拟功能，则在调用 COM 组件时将会丢失模拟令牌。这通常导致出现“拒绝访问”异常。

更多信息

返回页首

将客户端证书用于 Web 服务

本节介绍在 Web 服务身份验证中使用 X.509 客户端证书的方法。

可以在 Web 服务中使用客户端证书身份验证来验证：

使用证书对 Web 浏览器客户端进行身份验证

Web 服务不能使用客户端证书验证调用方是否与中间 Web 应用程序进行交互，因为无法将原调用方的证书通过 Web 应用程序传递给 Web 服务。虽然 Web 应用程序可以使用证书对其客户端进行身份验证，但是 Web 服务无法使用相同的证书进行身份验证。

这种服务器到服务器的方案失败的原因在于，Web 应用程序无法访问其证书存储中的客户端证书（特别是其私钥）。图 10.7 中说明了这一问题。

图 10.7
Web 服务客户端证书身份验证

使用受信任的子系统模型

要消除上述限制并在 Web 服务中支持证书身份验证，必须使用受信任的子系统模型。通过使用这种方法，Web 服务可以使用 Web 应用程序的证书（而不是原调用方的证书）对 Web 应用程序进行身份验证。Web 服务必须信任 Web 应用程序对其用户进行身份验证并进行必要的授权，确保只有经过授权的调用方能够访问 Web 服务提供的数据和功能。

图 10.8 中显示了这一方法。

图 10.8
Web 服务对受信任的 Web 应用程序进行身份验证

如果 Web 服务中的授权逻辑需要多个角色，则 Web 应用程序可以根据调用方的角色成员身份来发送不同的证书。例如，可以对管理员组的成员使用一个证书（允许他们在后端数据库中更新数据）；而对所有其他用户使用另一个证书（只授予他们读取操作的权限）。

注意：在这类方案中，本地证书服务器（只能通过两个服务器访问）可用于管理所有的 Web 应用程序证书。

在此方案中：

解决方案实现

在此方案中，若要在 Web 服务中使用证书身份验证，请使用单独的进程来调用 Web 服务和传递证书。您无法从 ASP.NET Web 应用程序中直接使用证书，因为它没有加载用户配置文件和相关的证书存储。必须将此单独的进程配置为使用具有相关用户配置文件（和证书存储）的帐户来运行。您有两个主要选项：

图 10.9 说明了包含企业服务服务器应用程序的方案。

图 10.9
Web 服务中的客户端证书身份验证

下面概括了图 10.9 中说明的事件顺序：

为什么使用其他进程？

由于需要用户配置文件（包含证书存储），因此要求使用其他进程（而不是使用 Aspnet_wp.exe Web 进程与 Web 服务建立联系）。

使用 ASPNET 帐户运行的 Web 应用程序没有访问 Web 服务器上任何证书的权限。这是因为，证书存储保存在与交互式用户帐户相关的用户配置文件中。仅当使用交互式帐户进行实际登录时，才会为该帐户创建用户配置文件。不能将 ASPNET 帐户用作交互式用户帐户；可以给 ASPNET 帐户配置“拒绝交互式登录”特权以提高安全性。

重要说明：不要重新配置 ASPNET 帐户以删除此特权并将该帐户转换为交互式登录帐户。请使用配置的服务帐户运行单独的进程来访问证书，如本章前面所述。

更多信息

返回页首

安全通信

安全通信是指通过网络在应用程序之间传送 Web 服务消息时确保消息的完整性和机密性。可以使用两种方法来解决这个问题：传输级选项和消息级选项。

传输级选项

传输级选项包括：

如果满足以下条件，则可以使用这些选项：

消息级选项

消息级方法可用于确保消息通过任意数量的中间系统传递时的机密性和完整性。可以对消息进行签名以提供完整性。为了保证机密性，您可以选择加密整个消息或消息的一部分。

如果符合以下条件，则可以使用消息级方法：

更多信息

返回页首

总结

本章重点介绍了 ASP.NET、IIS 和操作系统的基本服务提供的平台/传输级（点对点）Web 服务安全性。虽然平台级安全性为紧密集成的 Intranet 应用提供了安全的解决方案，但它不适用于异类环境。为此，需要使用 GXA WS-Security 规范提供的消息级安全性。可以使用 Web 服务开发工具包来开发消息级 Web 服务安全性解决方案。

对于紧密集成的 Windows 域环境：

对于 Web 服务到 Web 服务的方案：

返回页首