谁动了我的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大。