负载平衡 WCF 与 wsHttpBinding 和消息安全与客户端凭据类型窗口答案

【问题标题】：load balancing WCF with wsHttpBinding and Message Security with client credentials type windows负载平衡 WCF 与 wsHttpBinding 和消息安全与客户端凭据类型窗口
【发布时间】：2014-09-23 04:08:26
【问题描述】：

我们有一个普通的 WCF 服务，它的绑定如下所示：

 <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 台服务器中。按照这里的建议

http://msdn.microsoft.com/en-us/library/vstudio/hh273122(v=vs.100).aspx

我已将建立安全上下文设置为假。当我运行调用服务时，我会遇到与无效安全上下文令牌相关的间歇性问题。即使我说不要建立SeurityContext，WCF 似乎也在做所有正常的握手工作。

由于要求，此时使用 Cert、BasicHttBinding 或无安全性不是一个选项。

我什至让基础架构团队在负载均衡器中启用粘性会话，但似乎没有任何工作按我们预期的方式工作。

我和我的团队几乎完成了互联网上所说的所有事情，但是当有负载均衡器时似乎没有任何效果，而当没有负载均衡器时，此绑定工作完美。

有没有人用这个绑定运气好？

我们正在追赶微软向我们发送 WCF 专家，但显然人们很难找到。

我怎样才能让这个东西与负载均衡器很好地工作？

【问题讨论】：

标签： c# wcf load-balancing wcf-security ws-security

【解决方案1】：

您设置了negotiateServiceCredential="true"。这意味着安全上下文是在初始交换期间创建的，但此上下文不会在后续调用中使用（因为建立安全上下文 =“假”）。协商过程允许客户端安全地获取服务器凭据。然后客户端使用这些凭据来保护消息。这就是为什么所有“握手的事情”都会发生的原因。

本文描述了这种情况："Message Security with a Windows Client"。

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

在您的情况下，negotiateServiceCredential="true"。所以可能的问题是：

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

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

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

2) 如果粘性会话正常工作，请确保您的配置在不使用平衡的情况下完全适用于所有服务器。

当你不能使用粘性会话时，你应该设置negotiateServiceCredential="false"。不使用协商，因此客户端应该在代码或配置中明确配置服务器凭据。要在不协商的情况下使用 Windows 凭据类型，服务的用户帐户必须有权访问在 Active Directory 域中注册的服务主体名称 (SPN)。查看"Message Security with a Windows Client without Credential Negotiation"中的详细信息和示例

要使用任意 SPN，您应该将您的服务配置为在同一个 Windows 域帐户下运行。要将任意 SPN 设置为帐户，您可以在域控制器上使用 setspn 实用程序：

setspn a AcmeService/GlobalBank WS_Account

如Kerberos Technical Supplement for Windows中所述

另见关于Message Security的文章，了解各种场景和相应设置的描述。

【讨论】：

我们现在不想进行 Kerberos 身份验证，我最初的问题是微软是否明确表示启用粘性会话或禁用建立安全上下文是实现负载平衡的方法他们的文章为什么在现实生活中不起作用？
仅供参考...@Ivan 我已经尝试了 basicHttpBinding 没有任何问题，但这不是我想去的地方
是的，我猜文章中下面的说法是错误的：“如果将建立安全上下文属性设置为false，则不会执行一次性初始步骤，并且请求不依赖于已建立的会话. 这是使用粘性会话的替代方法。”。默认情况下，negotiateServiceCredential 为 true，因此仍会执行初始步骤。它可能会影响平衡。 basicHttpBinding 不会导致任何问题，因为默认情况下它不暗示任何安全性 (msdn.microsoft.com/en-us/library/…)。没有发生任何协商。
我发现了有关使用 Windows 凭据的更多信息并更新了答案。
得到了微软的回复，说的和你说的完全一样，并要求禁用粘性会话并尝试将安全上下文设置为 false 并将服务凭据协商为 false，所以我接受你的回答。

【解决方案2】：

如前所述，一种选择是同时关闭协商服务凭据和建立安全上下文。这将导致性能损失，这可能对您的方案有意义，也可能没有意义。如果此方法也不起作用，则可能由于 kerberos/ntlm 没有“一次性”身份验证。我建议只为一个用户操作（一个代理调用）打开 Fiddler（或 wcf 日志），看看它是否也只对服务器进行一个 XML 调用，还是需要多次调用来进行身份验证。

另一种选择是确保所有服务器使用相同的帐户，Ivan 也提到了这一点。

还有第三种选择，您可以使用无状态安全上下文令牌使服务器无状态。刚刚设置：

requireSecurityContextCancellation=false

通过这种方式，所有客户端每次都会将 cookie 发送到服务器，因此他们获得的服务器无关紧要。我知道证书安全性意味着所有服务器都必须使用相同的证书，不确定 Windows 安全性的含义是什么。这是一个完整的例子：

http://msdn.microsoft.com/en-us/library/ms731814(v=vs.90).aspx

在某些情况下，创建自定义 SecurityStateEncoder 也可能是相关的：

http://msdn.microsoft.com/en-us/library/system.servicemodel.security.secureconversationservicecredential.securitystateencoder.aspx

【讨论】：