我有一组IIS7托管的net.tcp WCF服务为我的ASP.NET MVC Web应用程序提供服务。网络应用程序通过互联网访问。如何为单个方案配置多个WCF绑定配置
WCF Services (IIS7) <--> ASP.NET MVC Application <--> Client Browser
的服务是用户名认证的,即(我的web应用程序)的客户端使用登录帐户结束与主机上当前主体。
我希望其中一个服务以不同方式进行身份验证,因为它为我的登录视图提供视图模型。当它被调用时,客户端显然还没有登录。我认为,如果服务托管在与Web应用程序不在同一个域中的计算机上,那么Windows身份验证服务效果最好,或者也许只是基于证书的安全性(事实上,我应该将其用于已验证的服务)。
虽然这不是重点。使用多个TCP绑定是给我的麻烦。我试着在我的客户端配置设置它是这样的:
<bindings>
<netTcpBinding>
<binding>
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName"/>
</security>
</binding>
<binding name="public">
<security mode="Transport">
<message clientCredentialType="Windows"/>
</security>
</binding>
</netTcpBinding>
</bindings>
<client>
<endpoint contract="Server.IService1" binding="netTcpBinding" address="net.tcp://localhost:8081/Service1.svc"/>
<endpoint contract="Server.IService2" binding="netTcpBinding" bindingConfiguration="public" address="net.tcp://localhost:8081/Service2.svc"/>
</client>
服务器配置是这样的:
<bindings>
<netTcpBinding>
<binding portSharingEnabled="true">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName"/>
</security>
</binding>
<binding name="public">
<security mode="Transport">
<message clientCredentialType="Windows"/>
</security>
</binding>
</netTcpBinding>
</bindings>
<services>
<service name="Service1">
<endpoint contract="Server.IService1, Library" binding="netTcpBinding" address=""/>
</service>
<service name="Service2">
<endpoint contract="Server.IService2, Library" binding="netTcpBinding" bindingConfiguration="public" address=""/>
</service>
</services>
<serviceHostingEnvironment>
<serviceActivations>
<add relativeAddress="Service1.svc" service="Server.Service1"/>
<add relativeAddress="Service2.svc" service="Server.Service2"/>
</serviceActivations>
</serviceHostingEnvironment>
的事情是,这两种绑定似乎不想在我的主人一起住。当我删除任何一方,都很好,但它们共同产生在客户端以下异常:
请求的升级不“://本地主机:8081/Service2.svc的net.tcp”的支持。这可能是由于绑定不匹配(例如,在客户端而不是服务器上启用了安全性)。
在服务器跟踪日志,我发现以下异常:
协议类型应用程序/洽谈被送到不支持这种类型的升级服务。
我正在寻找正确的方向还是有更好的方法来解决这个问题?
UPDATE
虽然这个问题似乎是相当老,但它仍然与我有关(而且我认为其他人也)。目前,我正在使用一个神奇的用户名/密码组合(因为当前的主体需要一个用户名)在访问不应该首先进行身份验证的服务时。鉴于这个问题,你可以看到,我宁愿有一个专门用于这些公共服务的未经验证的绑定。在这种情况下,一个神奇的账户不是不安全的,除了公共层面之外,它不提供任何访问权限。
强化它只适用于.NET 4.0非常重要 – 2013-04-19 16:22:47