从Web应用程序调用自托管WCF服务时线程的标识

我有一个自托管Wcf服务的Windows服务，这个Wcf服务有一个带有默认设置的tcpBinding。Windows服务正在作为本地系统运行

Wcf服务由运行在IIS 7.5集成管道中的Web应用程序引用（默认设置），该应用程序位于其自己的应用程序池中，并具有自己的标识

两者都在同一台机器上运行

除了在Wcf服务中使用以下工具检查当前线程的标识外，所有操作都正常：

Thread.CurrentPrincipal.Identity.Name

它返回Web应用程序的应用程序池的用户。。这不是我所期望的。看起来Wcf服务中正在进行某种模拟

这是标准行为吗？我找不到这方面的任何文件。 这是否意味着，当我试图访问Wcf服务中的数据库时，我引入了一个身份跃点

编辑，服务端的配置：

        Type serviceType = typeof(WcfService);
        host = new ServiceHost(serviceType);

        Binding tcpBinding = new NetTcpBinding( );

        Uri tcpBaseAddress = new Uri("net.tcp://localhost:8001/Test");
        host.AddServiceEndpoint(typeof (WcfService), tcpBinding, tcpBaseAddress);

        host.Open();

在客户端：

            NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.Transport);
        windowsService = new WindowsService.WcfServiceClient(tcpBinding, new EndpointAddress("net.tcp://localhost:8001/Test"));

---

需要更多的信息，但我猜在服务器端或客户端绑定配置的某个地方启用了模拟。添加服务引用时，svcutil.exe在设置配置中所有可能的绑定属性时都非常积极

如果您能提供更多关于服务器端和客户端配置的信息，我们将不胜感激。

我正在阅读Michele Bustamante的《学习WCF》。我已经将WCF用于一个经过重构的应用程序，我们希望在新的应用程序中使用WCF，因为它提供了灵活性。WCF的一个缺点是，使用.net属性或.config文件来获得正确的设置可能很棘手。我花了几天时间跟踪WCF设置的问题。我甚至创建了自动测试，以检查我的服务是否按预期方式运行

在回答您的问题时，Michele在第七章中特别指出NetTcpBinding在默认情况下是安全的，这意味着调用方必须提供Windows凭据以进行身份验证。我相信这可以解释为什么线程看起来是以web服务的身份运行的。这是为了保护您的服务不被未经授权的用户调用

我相信以下第419-420页的引文将简明扼要地回答您的问题。如果您熟悉传统的.NET基于角色的安全性，您知道每个执行线程都有一个安全主体。该安全主体持有调用方的身份，该身份可能与Windows帐户或自定义数据库凭据及其角色相关联

这似乎清楚地表明，是的，这是标准行为

我相信您可以通过属性和.config文件更改行为。我建议你买一本这方面的好书。我在沙地上转了很长一段时间，试图从网络上获取有关WCF的零碎信息。

要清除：

我查错了这里的房子。因为代码将在WindowsIdentity.GetCurrent（）标识下执行

默认情况下，这与调用方（位于Thread.CurrentPrincipal.Identity中）不同。如果您想要这种行为，您可以通过以下方式进行控制：

host.Authorization.ImpersonateCallerForAllOperations = true;

及

---

事实上，我们在网站上设置了集成安全设置，然后从网站向WCF服务拨打任何电话，我们将其打包：

        using (((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate())
        {

这将确保传递登录用户的凭据，而不是IIS应用程序池凭据

工作就像魔术

        using (((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate())
        {