谁动了我的CurrentPrincipal？解释一下为什么CurrentPrincipal变了，并解决这个问题。...

在上一篇博客中我遇到了一个问题，并且导致了我无法继续进行授权和验证。经过查阅资料和解决另外一个问题的过程，我突然想通了为什么CurrentPrincipal变了。并且经过验证后的确是我所理解的那样。下面说说过程。

我在将petshop调试成功运行后，打算在另外一台机器上调用petshop的wcf服务，达到web服务器和业务服务器的物理分层效果。在另一台机器调用wcf服务的时候，提示：“调用方未由服务进行身份验证”。根据提示我知道是绑定的原因，这说明了绑定中配置了服务方需要验证调用方的身份。A大在使用绑定的时候用的都是ws2007HttpBinding。于是我继续查看A大的文章里面关于wcf安全的文章，找到这篇：《[WCF安全系列]绑定、安全模式与客户端凭证类型：WSHttpBinding与WSDualHttpBinding》。里面描述了ws2007HttpBinding的默认安全是Message安全。其他设置于BasicHttpBinding一样。我再去看BasicHttpBinding，得知了在Message安全的情况下，客户端验证默认的是windows。这样的话，客户端在调用服务时，也会将自己的windows身份传递给服务。并且在执行服务的时候将身份附加到当前线程。如果将安全模式设置成为None。那么客户端就不会再传递自己的身份，也就是说匿名访问服务。

根据上面获取的信息，我将petshop的wcf服务里面的binding的安全模式设置为“None”。再次按照我上一篇博客中的方式来设置CurrentPrincipal。经过验证，成功运行了，不再发生执行服务的时候，CurrentPrincipal变了的情况。为什么不是将安全模式下面的消息安全里面的<message clientCredentialType="None" />设置为None呢？我这样设置了，结果：“安全协商失败，因为远程方未及时发回答复。这可能是因为基础传输连接已中止。”为了能够让它顺利运行，我只好先把安全关掉了。

服务端的配置

<!--Binding的设置-->
    <bindings>
      <ws2007HttpBinding>
        <binding name="ws2007httpbindingConfiguration">
          <security mode="None">
          </security>
        </binding>
      </ws2007HttpBinding>
    </bindings>
<!--使用到服务上-->
<service behaviorConfiguration="petshopbehavior" name="Artech.PetShop.Products.Service.ProductService">
        <endpoint binding="ws2007HttpBinding" bindingConfiguration="ws2007httpbindingConfiguration"
          contract="Artech.PetShop.Products.Service.Interface.IProductService" />
      </service>

客户端的配置

<!--Binding的设置-->
  <bindings>
   <ws2007HttpBinding>
    <binding name="ws2007client">
     <security mode="None">
     </security>
    </binding>
   </ws2007HttpBinding>
  </bindings>

<!--终结点的设置-->
<endpoint address="http://localhost:1719/Products/productservice.svc"
    behaviorConfiguration="petShopBehavior" binding="ws2007HttpBinding"
    bindingConfiguration="ws2007client" contract="Artech.PetShop.Products.Service.Interface.IProductService"
    name="productservice" />

 

这样的确解决了直接调用的时候，无法设置当前线程的CurrentPrincipal的问题。但是我们面临下一个问题：现在的服务是不安全的！匿名可以访问的！这是不能接受的！

那么必须解决这个问题。通过上面解决问题的过程，可以这样分析WCF安全机制的介入时机：我们知道ContextReceivalCallContextInitializer类，是作为ServiceBehavior的一个执行存在的，那么WCF安全机制在ServiceBehavior执行之后介入服务调用，根据配置的安全信息来进行安全验证。

这样我们可以从这里查找切入点，在既保证WCF安全的情况下又能够使用ApplicationContext里面的UserName来限制用户操作。

我将继续查找相关的资料并尝试解决这个问题。再次感谢A大。

 

 

 

转载于:https://www.cnblogs.com/Arnu/p/SolvePrincipalFail.html