小编Uri*_*ick的帖子

以下是我要处理的情况:

我们有一个WCF客户端,它与http端点和https端点一起使用,但在从http重定向(302)到https时却没有.我们有一个F5负载均衡器,它正在执行重定向和SSL功能,但据我所知,它没有对请求做任何意外的事情.重定向似乎是WCF在执行重定向后不希望提供Windows Kerberos身份验证信息的罪魁祸首.

成功调用的顺序(即没有重定向的http)如下所示:

• 客户端 - 使用http方案发送POST服务请求
• 服务器 - 响应401未经授权
• 客户端 - 通过授权发送协商POST
• 服务器 - 响应100继续
• 客户端 - 发送soap数据并成功完成

当呼叫被重定向并失败时,它会像这样:

• 客户端 - 使用http方案发送POST服务请求
• 服务器 - 返回302,重定向到同一地址的https方案
• 客户端 - 为https地址发送GET(我无法弄清楚为什么这是GET而不是POST)
• 服务器 - 响应401未经授权
• 客户端 - 抛出异常"HTTP请求未经授权,客户端身份验证方案'协商'.从服务器收到的身份验证标头是'Negotiate,NTLM'."

它类似于这个问题,但不完全相同(虽然它确实引用了"破坏WCF协议",但我没有真正的答案,我可以找到文件).如果我们关闭F5重定向规则http和https流量工作正常.WCF真的不能处理这个简单的重定向吗？有关此漏洞的解决方法或任何文档吗？

客户端配置(请注意,使用https进行测试时,我将TransportCredentialOnly更改为Transport):

<client>
        <endpoint address="http://fooserver/MyService.svc/" binding="basicHttpBinding" bindingConfiguration="clientBinding" contract="Contracts.IMyService" />
</client>
<bindings>
<basicHttpBinding>
    <binding name="clientBinding">
        <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Windows" proxyCredentialType="Windows" />
        </security>
    </binding>
</basicHttpBinding>

服务器配置如下所示:

<system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
    <services>
        <service behaviorConfiguration="MyServiceBehavior" name="MyService">
            <endpoint address="" binding="basicHttpBinding" bindingConfiguration="securedBinding" contract="Contracts.IMyService">
            </endpoint>
        </service>
    </services>
    <bindings> …