使用wsHttpBinding和带有客户端凭据类型Windows的消息安全性对WCF进行负载平衡 [英] load balancing WCF with wsHttpBinding and Message Security with client credentials type windows

问题描述

我们有一个普通的WCF服务，该服务具有如下所示的绑定:

We have got a normal WCF service which has a binding that looks like this:

 <wsHttpBinding>
 <binding name="ServiceBinding" receiveTimeout="00:10:00" sendTimeout="00:10:00"
                bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                maxReceivedMessageSize="20971520"
                messageEncoding="Mtom" textEncoding="utf-8" useDefaultWebProxy="true"
                allowCookies="false">                   
                <security mode="Message">
                      <message clientCredentialType="Windows" negotiateServiceCredential="true"
                        establishSecurityContext="false" />
                </security>
            </binding>
</wsHttpBinding>

此服务位于负载均衡器后面的2台服务器中.如此处建议

this service sits in 2 servers behind a load balancer. As suggested here

http://msdn.microsoft.com/zh-我们/library/vstudio/hh273122(v=vs.100).aspx

我已将EstablishmentSecurityContext设置为false.当我运行该服务时，我得到了与无效安全上下文令牌有关的间歇性问题.即使我说不建立EstablishmentSeurityContext，WCF似乎也在做所有正常的握手工作.

I have set establishSecurityContext to false. When i run call the service i get intermittent issues related to invalid security context token. Even though i say not to establishSeurityContext it seems that WCF is doing all the normal handshake stuff.

由于需要，目前无法选择使用Cert，BasicHttBinding或没有安全性.

At this point of time using Cert, BasicHttBinding or no security is not an option because of the requirement.

我什至拥有基础架构团队来在负载均衡器中启用粘性会话，但是似乎没有按我们期望的方式工作.

I have even got the infrastructure team to enable sticky sessions in the load balancer but nothing seems to work the way we expect it to.

我和我的团队几乎完成了互联网上已经说过的所有事情，但是当有负载均衡器时似乎什么也没用，而当没有负载均衡器时，这种绑定是完美的.

Me and my team has done almost everything that has been said in the internet but nothing seems to work when there is a load balancer and this binding is working perfect when there is not load balancer.

有人对这种约束感到幸运吗?

Has any one got luck with this binding?

我们正在追赶Microsoft，向我们发送WCF专家，但是显然人们很难被抓住.

We are chasing Microsoft to send us the WCF expert but apparently folks are hard to get hold of.

我怎样才能使它与Load Balancer很好地配合使用?

How can i get this thing to work nicely with Load Balancer?

推荐答案

您设置了notifyServiceCredential ="true".这意味着安全上下文是在初始交换期间创建的，但是此上下文将不会在后续调用中使用(因为EstablishmentSecurityContext ="false").协商过程允许客户端安全地获取服务器凭据.然后，客户端使用这些凭据来保护消息.这就是为什么所有握手内容"都会发生的原因.

You set negotiateServiceCredential="true". That means security context is created during initial exchange, but this context won't be used in subsequent calls (because of establishSecurityContext="false"). The negotiation process allows client to get server credentials safely. Then client uses these credentials to secure the message. That's why all "handshake stuff" happens.

本文介绍了这种情况:"Windows的消息安全性"客户" .

This scenario is described in this article: "Message Security with a Windows Client".

使用负载均衡器时(因为实际服务器的凭据取决于将服务请求的计算机)，需要进行安全协商，除非您对均衡器后面的所有服务实例都使用相同的凭据.在后一种情况下，您可以设置contractServiceCredential ="false"，并在配置或代码中指定服务器凭据.例如，您可以使用clientCredentialType ="Certificate"并对所有计算机使用相同的服务器证书.或者，您也可以clientCredentialType ="Windows"并为域用户配置任意SPN，该域用户用于在balancer后面运行所有服务(我没有尝试这种情况，请参见下面的详细信息).

The security negotiation is needed when you're using load balancer (because actual server's credentials depend on a machine that will serve request) unless you're using the same credentials for all service instances behind balancer. In the latter case you can set negotiateServiceCredential="false" and specify server credentials in config or code. For example, you can use clientCredentialType="Certificate" and use the same server certificate for all machines. Or you can clientCredentialType="Windows" and configure arbitrary SPN to a domain user, which is used to run all services behind balancer (I didn't try this scenario, see details below).

在您的情况下，contractateServiceCredential ="true".因此可能的问题是:

In your case negotiateServiceCredential="true". So possible issues are:

1)粘性会话可能无法正常工作.您可以通过使用返回的BasicHttBinding实现简单的WCF服务进行测试

1) Sticky session may not work properly. You can test it by implementing simple WCF service with BasicHttBinding that returns

String.Format("{0}{1}", prefix, DateTime.Now);

在平衡器后面的一台服务器上的应用程序设置中配置prefix ="和prefix ="!!!!!!!!!!!!"另外一个.然后，多次循环调用此服务并记录结果.您会看到粘性会话是否存在问题.

Configure prefix="" in app settings on one server behind balancer and prefix="!!!!!!!!!!!!" on another. Then call this service in a loop many times and log results. You'll see if there's an issue with the sticky session.

2)如果粘性会话正常工作，请确保在不使用任何平衡的情况下您的配置对所有服务器都正确地工作.

2) If sticky session works correctly, ensure that your configuration works exactly for all servers when no balancing is used.

当您不能使用粘性会话时，应设置协商服务Credential ="false".不使用协商，因此客户端应具有在代码或配置中显式配置的服务器凭据.若要使用Windows凭据类型而无需协商，该服务的用户帐户必须有权访问在Active Directory域中注册的服务主体名称(SPN).请参阅具有Windows客户端而没有凭据协商的消息安全性"的详细信息和示例，

When you can't use sticky session, you should set negotiateServiceCredential="false". The negotiation is not used, so client should have server credentials are being configured explicitly in code or configuration. To use the Windows credential type without negotiation, the service's user account must have access to service principal name (SPN) that is registered with the Active Directory domain. See details and example in "Message Security with a Windows Client without Credential Negotiation"

要使用任意SPN，您应该将服务配置为在同一Windows域帐户下运行.要将任意SPN设置为帐户，可以在域控制器上使用setspn实用工具:

To use arbitrary SPN you should configure your services to run under the same Windows domain account. To set arbitrary SPN to the account you can use setspn utility on a domain controller:

setspn a AcmeService/GlobalBank WS_Account

如用于Windows的Kerberos技术补充

另请参阅有关消息安全性的文章，以了解各种方案和相应的设置.

See also article about Message Security for description of various scenarios and corresponding settings.

这篇关于使用wsHttpBinding和带有客户端凭据类型Windows的消息安全性对WCF进行负载平衡的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！