通过 NTLM 授权的代理请求具有基本授权的 Web 服务不起作用答案

【问题标题】：Request to web service with Basic authorization via proxy with NTLM authorization not working通过 NTLM 授权的代理请求具有基本授权的 Web 服务不起作用
【发布时间】：2011-05-31 14:59:34
【问题描述】：

我有一个需要基本授权的 Web 服务和一个需要 NTLM 授权的 Internet 代理背后的用户。我还有一个表单应用程序，它调用 Web 服务并要求用户提供 Web 服务凭据（不同于 NTLM 凭据）。

我的应用配置正常工作（WCF ServiceModel），它使用默认代理凭据，请求正在通过代理进行身份验证，但在通过 Web 服务进行身份验证后，由于某种原因它没有发送请求正文。

如果我在没有 NTLM 代理的情况下进行本地测试，则该过程有效。抱歉，示例太长了，但我必须将它们包括在内。

第一个请求：

发送：

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收：

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM
Proxy-Authenticate: BASIC realm="corporaterealm"
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: close
Content-Length: 1057
Proxy-Support: Session-Based-Authentication

[...]

第二次请求：

发送：

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0

接收：

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAEAAQADgAAAAFgomiysOwieqrhFEAAAAAAAAAALIAsgBIAAAABQLODgAAAA9DAE8ATQBFAFQATgBFAFQAAgAQAEMATwBNAEUAVABOAEUAVAABABoAVgBJAC0AUgBJAEMASwBEAEMALQAwADAAMQAEABwAYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAMAOABWAEkALQBSAEkAQwBLAEQAQwAtADAAMAAxAC4AYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAUAHABjAG8AbQBlAHQAbgBlAHQALgBsAG8AYwBhAGwAAAAAAA==
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: Keep-Alive
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: Keep-Alive
Content-Length: 1074
Proxy-Support: Session-Based-Authentication

[...]

第三次请求：

发送：

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAABAAEABIAAAADgAOAFgAAAASABIAZgAAAAAAAACoAAAABYKIogUBKAoAAAAPQwBPAE0ARQBUAE4ARQBUAFAAYQByAHMAbwBuAEoAVwBTAFIASwAwADQAOAA3ADAAlap7g+mPRMEAAAAAAAAAAAAAAAAAAAAARLAhi5lf3nd+l9xENAcu2W6xf6iJbyM6
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收：

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:09:33 GMT
Cache-Control: proxy-revalidate
Content-Length: 1656
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Proxy-support: Session-based-authentication
Age: 0

[...]

第四次请求：

发送：

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0

接收：

HTTP/1.1 400 Bad Request
Date: Tue, 31 May 2011 13:09:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, proxy-revalidate
Content-Length: 0
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Age: 0

我不明白为什么它没有在第四个请求中发送信封。两次握手都完成了，所以理论上一切都应该没问题。

当我在没有 NTLM 代理的情况下在本地执行此操作时，信封会按预期发送：

第一个请求：

发送：

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收：

HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:31:46 GMT

[...]

第二次请求：

发送：

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收：

HTTP/1.1 200 OK
Date: Tue, 31 May 2011 13:31:47 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Set-Cookie: ASP.NET_SessionId=svv4i11awg05v1j5viz1impo; path=/; HttpOnly
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 5127

[...]

【问题讨论】：

您用来发送这些请求的客户端库是什么？一些请求看起来......异常：例如，发送一个 expect: continue 标头以及 POST 数据。
我正在使用 .NET WCF 服务参考。有一个 Sytem.ServiceModel 对象。
这比我在 .Net 中使用 NTLM 得到的还远，你能回答stackoverflow.com/questions/4723062 吗？
@Keith：你的问题不同。我不必编写自己的 NTLM 代码，因为 WCF 服务绑定程序可以处理这些。这是我的配置：stackoverflow.com/questions/6154705/….
感谢您的关注

标签： web-services proxy ntlm basic-authentication wcf

【解决方案1】：

我必须更改服务器安全配置以接受摘要式身份验证。出于某种原因，Basic 不起作用。

【讨论】：

【解决方案2】：

我遇到了一个可能类似的问题，我认为这可能与建立到代理的原始 NTLM 连接有关。

根据我的经验，我每小时依次发出三个请求，并配置了重试。

在这些请求中，有两个会起作用，一个会失败并返回 400，然后当第一次重试时它也能正常工作。

这里发现了一个与 IE 类似的问题：http://blogs.msdn.com/b/asiatech/archive/2012/01/30/400-bad-request-when-posting-webservice-or-wcf-request-from-ie.aspx

我运行了一些网络跟踪并观察了行为，并注意到 TCP 流似乎经常被共享，因此其中一个请求最终会在另一个之后向代理发送 NTLM 身份验证消息（内容长度为零）已经认证了。在这种情况下，代理只是通过零内容消息（因为流已经过身份验证）。

为我解决的问题是移动到 WCF 自定义 customBinding（使用 textMessageEncoding 和 Soap11 的 messageVersion 来维持我的 basicHttpBinding 行为）和（不确定是否需要）设置 @987654327 @ 为假。

不幸的是，我怀疑这对您的特定情况有多大帮助，但更多信息永远不会受到伤害。

【讨论】：