第 11 章 – .NET Remoting 安全性

本页内容

	本章内容
	目标
	适用范围
	如何使用本章内容
	.NET Remoting 体系结构
	.NET Remoting 网关守卫
	身份验证
	授权
	身份验证和授权策略
	访问系统资源
	访问网络资源
	将身份验证的凭据传递给远程对象
	传递原调用方
	受信任的子系统
	安全通信
	选择主机进程
	远程处理与 Web 服务的比较
	总结

本章内容

.NET Framework 提供了远程处理的基础结构，这样，客户端就可以与驻留在远程应用程序域或进程中的对象或远程计算机上的对象通信。在分布式 Web 应用程序中，.NET Remoting 通常用作一种机制，供表示层组件访问位于中间层的业务逻辑组件。

本章说明如何在使用 .NET Remoting 的分布式 Web 应用程序中实现身份验证、授权和安全通信。

返回页首

目标

本章的目标是：

返回页首

适用范围

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

返回页首

如何使用本章内容

若要学好本章内容：

返回页首

.NET Remoting 体系结构

图 11.1 显示了在 ASP.NET 中驻留远程对象时的基本 .NET Remoting 体系结构。如果主要关心安全性问题，那么建议使用 ASP.NET 主机和 HTTP 通道进行通信，因为它允许远程对象利用 ASP.NET 和 IIS 提供的基本安全服务。

有关可能使用的主机和通道类型范围的详细信息以及比较信息，请参见本章后面的选择主机进程。

图 11.1
.NET Remoting 体系结构

客户端与进程内的代理对象进行通信。可以通过远程对象代理设置身份验证凭据（例如，用户名、密码和证书等等）。方法调用通过接收链进行传递（您可以实现自己的自定义接收来执行数据加密），并到达负责通过网络发送数据的传输接收。在服务器端，调用通过相同的管道进行传递，并向对象发出调用。

注意：本章中使用的术语代理一词是指客户端进程内的代理对象，客户端通过该对象与远程对象进行通信。不要将它与术语代理服务器混淆。

.NET Remoting 接收

当客户端在远程对象上进行方法调用时，.NET Remoting 使用传输通道接收、自定义通道接收和格式化程序通道接收。

传输通道接收

传输通道接收通过网络在客户端与服务器之间传递方法调用。.NET 提供了 HttpChannel 和 TcpChannel 类，但是，可以对体系结构进行完全扩展，并且插入您自己的自定义实现方法。

比较传输通道接收

下表对两个主要的传输通道接收进行了比较。

表 11.1： TcpChannel 和 HttpChannel 的比较

自定义接收

可以在通道接收管道内的不同位置上使用自定义通道接收来修改在客户端和服务器之间发送的消息。提供加密和解密功能的通道接收就是一个自定义通道接收的示例。

格式化程序接收

格式化程序接收获取方法调用，并将它们序列化为可通过网络发送的流。.NET 提供两种格式化程序接收：

对驻留在 ASP.NET 中的请求进行剖析

远程对象终结点的地址是由以 .rem 或 .soap 扩展文件名结尾的 URL 指定的（例如 http://someserver/vDir/remoteobject.soap）。当 IIS 收到远程对象（带有 .rem 或 .soap 扩展名）的请求时，就会将它映射到 ASP.NET ISAPI 扩展 (Aspnet_isapi.dll) 中。ISAPI 扩展将该请求转发到 ASP.NET 辅助进程 (Aspnet_wp.exe) 中的应用程序域。图 11.2 显示了事件的顺序。

图 11.2
服务器端处理

图 11.2 显示了以下事件顺序：

ASP.NET 和 HTTP 通道

.NET Remoting 没有自己的安全模型。客户端（代理）和服务器（远程对象）之间的身份验证和授权是通过通道和主机进程执行的。可以组合使用以下主机和通道：

ASP.NET 中驻留的对象可以利用 ASP.NET 和 IIS 的基本安全功能。它们包括：

 <authentication mode="Windows"/>
 

更多信息

返回页首

.NET Remoting 网关守卫

ASP.NET 承载的远程对象使用的授权点（或者网关守卫）包括：

返回页首

身份验证

在结合使用远程处理和 ASP.NET Web 应用程序客户端时，就会在 Web 应用程序和远程对象主机上进行身份验证。远程对象主机可以使用的身份验证选项取决于主机类型。

驻留在 ASP.NET 中

当对象驻留在 ASP.NET 中时，可以使用 HTTP 通道在客户端代理和服务器之间传递方法调用。HTTP 通道使用 HTTP 协议对服务器的远程对象代理进行身份验证。

以下列表说明在 ASP.NET 中驻留对象时可以使用的一组身份验证选项：

驻留在 Windows 服务中

当对象驻留在 Windows 服务中时，可以使用 TCP 通道在客户端和服务器之间传递方法调用。它使用基于套接字的原始通信方法。因为套接字没有提供身份验证，所以服务器无法对客户端进行身份验证。

在此方案中，远程对象必须使用自定义身份验证。

自定义身份验证

对于简单的自定义身份验证，远程对象可以公开一个接受用户名和密码的 Login 方法。可以根据存储、检索的角色列表以及发回到客户端的令牌对凭据进行验证，以便在后续请求中使用。在服务器上检索到令牌后，可以使用它来创建一个存储在 Thread.CurrentPrincipal 中的 IPrincipal 对象（包含角色）以便进行授权。

其他自定义身份验证的示例还包括：创建使用提供身份验证的进程间通信通道的自定义传输通道接收（例如，命名管道），或者创建使用 Windows 安全服务提供程序接口 (SSPI) 执行身份验证的通道接收。

更多信息

返回页首

授权

当在 ASP.NET 中驻留对象并且使用 HTTP 通道进行通信时，可以对客户端进行身份验证，并使用以下机制来控制授权：

当在 Windows 服务中驻留对象时，TCP 通道不提供任何身份验证。因此，您必须通过创建 IPrincipal 对象并将其存储在 Thread.CurrentPrincipal 中，来执行自定义身份验证并进行授权。

然后，可以使用声明方式的主体权限要求检查对远程对象的方法进行注释（如下所示）：

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

在对象的方法代码中，也可以使用强制方式的用户权限要求，并可利用 IPrincipal.IsInRole 进行明确的角色检查。

使用文件授权

您可能需要使用内置的 Windows 访问控制将远程对象作为可保护的 Windows 资源保护起来。如果没有文件授权（使用 Windows ACL），则您只能使用 URL 授权。

若要使用 FileAuthorizationModule 授权访问远程对象终结点（用 .rem 或 .soap URL 标识），您必须在应用程序的虚拟目录中创建带有 .rem 或 .soap 扩展名的物理文件。

注意：IIS 使用 .rem 和 .soap 扩展名将对象终结点的请求映射到 ASP.NET ISAPI 扩展 (aspnet_isapi.dll)。通常，它们并不是作为物理文件存在。

为 .NET Remoting 配置文件授权：

<%@ webservice class="YourNamespace.YourClass" ... %>

<wellknown mode="SingleCall" objectUri="RemoteMath.rem" 
type="RemotingObjects.RemoteMath, RemotingObjects, Version=1.0.000.000 
Culture=neutral, PublicKeyToken=4b5ae668c251b606"/>

更多信息

返回页首

身份验证和授权策略

在许多使用 .NET Remoting 的应用程序中，可以使用远程对象在应用程序中间层中提供业务功能，并且 ASP.NET Web 应用程序可以调用该功能。图 11.3 中显示了这种设置。

图 11.3
ASP.NET Web 应用程序调用的远程对象

在此方案中，使用为 Web 应用程序提供的 IIS 和 ASP.NET 网关守卫来保护对客户端代理的访问；而使用为远程应用程序服务器上 ASP.NET 主机提供的 IIS 和 ASP.NET 网关守卫来保护对远程对象的访问。

.NET Web 应用程序访问的远程对象可以使用两种基本的身份验证和授权策略。

更多信息

返回页首

访问系统资源

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

返回页首

访问网络资源

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

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

返回页首

将身份验证的凭据传递给远程对象

在客户端进程调用远程对象时，它使用代理来完成这一操作。这是一个本地对象，它公开一组与目标对象相同的方法。

指定客户端凭据

如果远程对象驻留在 ASP.NET 中并被配置为使用 Windows 身份验证，则必须使用通道的凭据属性来指定用于身份验证的凭据。如果没有明确设置凭据，就会在没有任何凭据的情况下调用远程对象。如果需要使用 Windows 身份验证，这将导致出现 HTTP 错误状态 401，即拒绝访问。

使用 DefaultCredentials

如果您要使用驻留远程对象代理（如果调用代理的线程使用模拟功能，则为当前线程令牌）的进程的凭据，则应该将通道的凭据属性设置为进程凭据缓存保存的 DefaultCredentials。

可以在配置文件中指定是否使用 DefaultCredentials，或者通过编程方式设置凭据。

显式配置

在客户端应用程序配置文件（如果客户端应用程序是 ASP.NET Web 应用程序，则为 Web.config）中，将 <channel> 元素的 useDefaultCredentials 属性设置为 true，指定代理在与远程对象进行通信时应该使用 DefaultCredentials。

<channel ref="http" useDefaultCredentials="true" />

编程配置

对于编程配置，请使用以下代码以编程方式确定是否使用 DefaultCredentials：

IDictionary channelProperties;
channelProperties = ChannelServices.GetChannelSinkProperties(proxy);
channelProperties ["credentials"] = CredentialCache.DefaultCredentials;

使用特定凭据

在调用远程对象时，若要使用一组特定的身份验证凭据，请使用以下设置禁止在配置文件中使用默认凭据：

<channel ref="http" useDefaultCredentials="false" />

注意：编程设置会始终覆盖配置文件中的设置。

然后，使用以下代码来配置代理以使用特定的凭据：

IDictionary channelProperties =  
                         ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential("username", "password", "domain");
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
// 使用“协商”、“基本”、“摘要式”、“Kerberos”或“NTLM” 
// 替代“authenticationType”
credCache.Add(objectUri, "authenticationType", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

请求特定的身份验证类型

按照上面所述，您应该使用 CredentialCache.Add 方法来请求特定的身份验证类型。避免直接使用 NetworkCredential 类，如以下代码所示：

IDictionary providerData = ChannelServices.GetChannelSinkProperties(yourProxy);
providerData["credentials"] = new NetworkCredential(uid, pwd);

在生产代码中应该避免出现这种情况，因为您无法控制远程对象主机使用的身份验证机制，因此也无法控制使用凭据的方式。

例如，您可能期望得到来自服务器的 Kerberos 或 NTLM 验证要求，但实际却可能收到一个基本身份验证要求。在这种情况下，以明文形式将提供的用户名和密码发送到服务器。

设置 preauthenticate 属性

可以将代理的 preauthenticate 属性设置为 true 或 false。如果将其设置为 true（如上述代码所示），则可以提供特定的身份验证凭据，以便通过初始请求传递 WWW-Authenticate HTTP 标头。这可避免 Web 服务器拒绝初始请求的访问，并在后续请求中执行身份验证。

使用 connectiongroupname 属性

如果 ASP.NET Web 应用程序连接到（驻留在 ASP.NET 中）远程组件并传递原调用方的安全性上下文（通过使用 DefaultCredentials 和模拟或通过设置显式凭据，如上所示），则应该在 Web 应用程序中设置通道的 connectiongroupname 属性。这用于防止未验证身份的新客户端重用到远程组件（该组件与以前的客户端身份验证凭据关联）的已验证身份的旧连接。在使用 HTTP KeepAlives 或出于 IIS 的性能考虑而启用身份验证持续功能时，会出现连接重用。

将 connectiongroupname 属性设置为能够区分调用方的标识符（例如，调用方的用户名）。

channelProperties["connectiongroupname"] = userName;

注意：如果没有通过 Web 应用程序将原调用方的安全性上下文传递给远程组件，而是使用固定标识（例如，Web 应用程序的 ASP.NET 进程标识）连接到远程组件，则您不需要设置 connectiongroupname 属性。在此方案中，连接安全性上下文在从一个调用方传递到下一个调用方时，保持不变。

下一版本的 .NET Framework 将支持基于调用代理对象的线程 SID 的连接池，如果 Web 应用程序正在模拟调用方，则它有助于解决上述问题。.NET Remoting 客户端支持连接池，但 Web 服务客户端不支持。

返回页首

传递原调用方

本节介绍如何通过 ASP.NET Web 应用程序将原调用方的安全性上下文传递给远程应用程序服务器上 ASP.NET 驻留的远程组件。要在远程对象或后续下游子系统（例如，数据库）中支持每用户的授权，您可能需要完成上述操作。

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

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

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

注意：IPrincipal 对象无法跨越 .NET Remoting 边界进行传递。

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

带有 Kerberos 委派的默认凭据

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

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

配置 Web 服务器

  
<authentication mode="Windows" />

 
<identity impersonate="true" />

<channel ref="http"  
	useDefaultCredentials="true" />
 

配置远程应用程序服务器

<authentication mode="Windows" />

<identity impersonate="true" />

更多信息

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

带有基本身份验证或窗体身份验证的显式凭据

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

利用此方式，Web 应用程序可以使用客户端的明文凭据。可以通过远程对象代理将这些凭据传递给远程对象。为此，必须在 Web 应用程序中包含代码以检索客户端凭据并配置远程对象代理。

基本身份验证

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

// 检索客户端的凭据（可通过基本身份验证进行）
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// 将凭据与远程对象代理相关联
IDictionary channelProperties =  
                         ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential(uid, pwd);
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
credCache.Add(objectUri, "Basic", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

注意：上述代码中的 NetworkCredential 构造函数是随用户 ID 和密码提供的。要避免对域名进行硬编码，在配置基本身份验证时，可以在 IIS 中的 Web 服务器上配置默认域。

窗体身份验证

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

// 从登录窗体检索客户端的凭据
string pwd = txtPassword.Text;
string uid = txtUid.Text;
// 将凭据与远程对象代理相关联
IDictionary channelProperties =  
                         ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential(uid, pwd);
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
credCache.Add(objectUri, "Basic", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

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

配置 Web 服务器

  <authentication mode="Windows" />

  <authentication mode="Forms" />

<identity impersonate="false" />

<channel ref="http"
         useDefaultCredentials="false" />

配置应用程序服务器

<authentication mode="Windows" />

<identity impersonate="true" />

返回页首

受信任的子系统

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

图 11.5 显示了受信任的子系统模型。该图还显示了两种可能的配置。第一种配置使用 ASP.NET 主机和 HTTP 通道，而第二种配置使用 Windows 服务主机和 TCP 通道。

图 11.5
受信任的子系统模型

传递调用方标识

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

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

SELECT x,y,z FROM SomeTable WHERE UserName = "李华"

选择主机

受信任的子系统模型意味着远程对象主机不对原调用方进行身份验证。但是，它仍需对其中间客户端（此方案中的 ASP.NET Web 应用程序）进行身份验证（和授权），以防止未经授权的应用程序向远程对象发出请求。

如果您在 ASP.NET 中驻留对象并使用 HTTP 通道，则可以使用 Windows 集成身份验证对 ASP.NET Web 应用程序进程标识进行身份验证。

如果您在 Windows 服务中驻留对象，则可以使用具有更高性能的 TCP 通道，但是该通道不提供身份验证功能。在此方案中，可以在 Web 服务器和应用程序服务器之间使用 IPSec。可以制订只允许 Web 服务器与应用程序服务器进行通信的 IPSec 策略。

配置步骤

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

配置 Web 服务器

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

identity impersonate="false" />

<channel ref="http"  
	useDefaultCredentials="true" />

配置应用程序服务器

<authentication mode="Windows" />

<identity impersonate="false" />

使用 Windows 服务主机

如果使用的是 Windows 服务主机进程，则必须创建一个 Windows 帐户以运行该服务。远程对象将使用该帐户提供的安全性上下文来访问所有本地和远程资源。

要访问远程 Microsoft SQL Server™ 数据库（利用 Windows 身份验证），您可以使用权限最少的域帐户；也可以使用本地帐户，然后在数据库服务器上创建一个重复帐户（具有相同的用户名和密码）。

返回页首

安全通信

安全通信是指在通过网络传送消息时确保消息的完整性和机密性。可以使用基于平台的方法来保护通信的安全并使用 SSL 或 IPSec；也可以使用消息级方法并开发自定义的加密接收，以便对整个消息或消息的选定部分进行加密。

平台级选项

可以考虑两个平台级选项以保护在客户端和远程组件之间传送的数据安全：

如果远程对象驻留在 ASP.NET 中，则可以使用 SSL 来保护客户端和服务器之间的通信通道。这要求驻留远程对象的计算机具有服务器身份验证证书。

如果远程对象驻留在 Windows 服务中，则可以在客户端和主机（服务器）之间使用 IPSec，也可以开发自定义的加密接收。

消息级选项

由于 .NET Remoting 体系结构具有可扩展性，因此，您可以开发自定义接收并将其插入到处理管道中。要提供安全的通信，可以开发自定义接收，以便对发送到和来自远程对象的消息数据进行加密和解密。

这种方法的优点是您可以有选择地加密消息的一部分。这与平台级方法正好相反，平台级方法是对客户端和服务器之间发送的所有数据进行加密。

更多信息

有关 SSL 和 IPSec 的详细信息，请参见第 4 章安全通信。

返回页首

选择主机进程

要远程访问的对象必须在主机可执行文件中运行。主机侦听传入请求，并向对象发出调用。所选的主机类型会影响称为“通道”的消息传输机制。选择的通道类型影响身份验证、授权、安全通信和解决方案的性能。

HTTP 通道提供更好的安全性选项，但 TCP 通道提供更高的性能。

可以使用以下主要选项来驻留远程对象：

建议

从安全的角度出发，要充分利用 ASP.NET 和 IIS 提供的安全基础结构，建议将远程对象驻留在 ASP.NET 中。这要求客户端通过 HTTP 通道与远程对象进行通信。驻留在 ASP.NET 中的远程对象可以使用 ASP.NET 和 IIS 身份验证、授权和安全通信功能。

如果主要关心性能（而不是安全性）问题，则考虑将远程对象驻留在 Windows 服务中。

驻留在 ASP.NET 中

在将远程对象驻留在 ASP.NET 中时：

优点

如果将远程对象驻留在 IIS 中，则您可以获得以下优势：

缺点

如果使用 ASP.NET 驻留远程对象，则应该了解它的以下缺点：

驻留在 Windows 服务中

如果将远程对象驻留在 Windows 服务中，则在服务进程内包含的应用程序域中激活远程对象。您不能使用 HTTP 通道，而必须使用 TCP 通道。TCP 通道支持以下安全功能：

优点

如果将远程对象驻留在 Windows 服务中，则可以获得以下优势：

缺点

如果使用 Windows 服务来驻留远程对象，则应该了解它的以下缺点：

驻留在控制台应用程序中

如果将远程对象驻留在控制台应用程序中，则在控制台应用程序进程内包含的应用程序域中激活远程对象。您不能使用 HTTP 通道，而必须使用 TCP 通道。

建议在生产解决方案中不要使用这种方法。

优点

虽然这种方法没有多少优点，但它在中间层的确不需要使用 IIS。不过，仅建议在开发和测试环境中使用这种方法，不要在生产环境中使用。

缺点

如果将远程对象驻留在自定义的可执行文件中，则应该了解它的以下缺点：

返回页首

远程处理与 Web 服务的比较

.NET 提供多种不同的方法使客户端能够与远程对象进行通信，其中包括使用 Web 服务。

如果需要异类系统之间具有互操作性，则最好选择使用开放式标准（例如 SOAP、XML 和 HTTP）的 Web 服务方法。另一方面，如果您正在创建服务器到服务器的 Intranet 解决方案，则远程处理组件可提供以下功能：

表 11.2： 远程处理和 Web 服务的主要差别

返回页首

总结

.NET Remoting 自身不提供安全模型。然而，通过将远程对象驻留在 ASP.NET 中并使用 HTTP 通道进行通信，远程对象可以使用 IIS 和 ASP.NET 提供的基本安全服务。比较而言，TCP 通道和自定义的主机可执行文件能够提供更高的性能，但这种组合不提供内置的安全功能。

返回页首