如何使用Windows凭据将WCF服务重定向到HTTPS端点

Uri*_*ick 6 ssl wcf redirect windows-authentication

以下是我要处理的情况:

我们有一个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>
Run Code Online (Sandbox Code Playgroud)

服务器配置如下所示:

<system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
    <services>
        <service behaviorConfiguration="MyServiceBehavior" name="MyService">
            <endpoint address="" binding="basicHttpBinding" bindingConfiguration="securedBinding" contract="Contracts.IMyService">
            </endpoint>
        </service>
    </services>
    <bindings>
        <basicHttpBinding>
            <binding name="securedBinding">
                <security mode="TransportCredentialOnly">
                    <transport clientCredentialType="Windows" proxyCredentialType="Windows"/>
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <behaviors>
        <serviceBehaviors>
            <behavior name="MyServiceBehavior">
                <serviceMetadata httpGetEnabled="true"/>
                <serviceDebug includeExceptionDetailInFaults="true"/>
                <useRequestHeadersForMetadataAddress>
                    <defaultPorts>
                        <add scheme="http" port="80" />
                        <add scheme="https" port="443" />
                    </defaultPorts>
                </useRequestHeadersForMetadataAddress>
            </behavior>
        </serviceBehaviors>
    </behaviors>
</system.serviceModel>
Run Code Online (Sandbox Code Playgroud)

Joe*_*men 1

我不明白为什么这是 GET 而不是 POST

这就是你的问题的原因。收到对 POST 的 302 响应后,客户端的预期行为是获取新 URL。请参阅以下网址:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

如果收到 302 状态代码来响应除 GET 或 HEAD 之外的请求,则用户代理不得自动重定向请求,除非用户可以确认,因为这可能会更改发出请求的条件。

另外,以下 SO 帖子有一些很好的信息:Response.Redirect with POST instead of Get?

因此,WCF 正在做它应该做的事情,即在 302 重定向后拒绝重新 POST。不幸的是,除了第一次正确指定协议以避免 302 之外,我不确定可以采取什么措施来解决您的问题。