问题描述
使用node.js作为客户端时，是否可以使用Windows集成身份验证连接到服务器(例如，连接到IIS时)?
When using node.js as a client, is it possible to connect to a server using Windows integrated authentication (e.g. when connecting to IIS)?
我对此的搜索仅显示将node.js用作服务器的结果.
My searches for this only turn up results where node.js is used as a server.
推荐答案
2015更新:现在，有些模块实现了Windows集成的身份验证. node-sspi 使用SSPI(Windows安全API)来处理服务器端的事情，但不进行客户端身份验证.有多个客户端实现，例如 http-ntlm ，但是由于需要用户密码，因此它们并未真正集成-他们不使用SSPI进行透明身份验证.
2015 Update: There are now some modules that implement Windows-integrated authentication. node-sspi uses SSPI (the Windows security API) to handle the server side of things, but does not do client auth. There are several client implementations such as http-ntlm, but they are not truly integrated since they require the user password -- they do not use SSPI to do transparent auth.
2019更新::似乎可以使用 kerberos 库使用SSPI进行真正的Windows集成的HTTP身份验证(即，使用节点进程的令牌进行透明身份验证).请参阅 kerberos-agent .显然，这使用的是Kerberos，而不是NTLM/Negotiate，因此，根据您的具体情况，此方法可能有效也可能无效.
2019 Update: It appears to be possible to use the kerberos library to do true Windows-integrated HTTP auth using SSPI (ie, use the node process' token to do transparent auth). See kerberos-agent. Obviously this uses Kerberos rather than NTLM/Negotiate, so this may or may not work depending on your exact situation.
"Windows集成身份验证"是所谓的NTLM身份验证.现在，当您从IIS收到带有WWW-Authenticate头且包含NTLM的HTTP 401时，现在可以实现NTLM身份验证协议.引用有关NTLM身份验证协议的文档:
"Windows integrated authentication" is what's known as NTLM authentication. When you receive a HTTP 401 from IIS with a WWW-Authenticate header containing NTLM, you now have the fun of implementing the NTLM authentication protocol. Quoting from this document about the NTLM authentication protocol:
-
客户端从服务器请求受保护的资源:
The client requests a protected resource from the server:
GET /index.html HTTP/1.1
服务器以401状态响应，指示客户端必须进行身份验证.通过WWW-Authenticate标头将NTLM表示为受支持的身份验证机制.通常，服务器此时会关闭连接:
The server responds with a 401 status, indicating that the client must authenticate. NTLM is presented as a supported authentication mechanism via the WWW-Authenticate header. Typically, the server closes the connection at this time:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
Connection: close
请注意，如果Internet Explorer是第一个提供的机制，它将仅选择NTLM；否则，它将选择NTLM.这与RFC 2616不一致，RFC 2616指出客户端必须选择支持最强的身份验证方案.
Note that Internet Explorer will only select NTLM if it is the first mechanism offered; this is at odds with RFC 2616, which states that the client must select the strongest supported authentication scheme.
客户端使用Authorization标头重新提交请求，该标头包含类型1消息参数. Type 1消息是Base-64编码的，用于传输.从这一点开始，连接保持打开状态.关闭连接需要重新认证后续请求.这意味着服务器和客户端必须通过HTTP 1.0样式的"Keep-Alive"标头或HTTP 1.1(默认情况下采用持久连接)来支持持久连接.相关的请求标头显示如下:
The client resubmits the request with an Authorization header containing a Type 1 message parameter. The Type 1 message is Base-64 encoded for transmission. From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests. This implies that the server and client must support persistent connections, via either the HTTP 1.0-style "Keep-Alive" header or HTTP 1.1 (in which persistent connections are employed by default). The relevant request headers appear as follows:
GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg==
服务器以401状态答复，其中包含类型2消息在WWW-Authenticate标头中(再次，使用Base-64编码).如下所示.
The server replies with a 401 status containing a Type 2 message in the WWW-Authenticate header (again, Base-64 encoded). This is shown below.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA=
客户端通过使用Authorization标头重新提交请求来响应类型2消息，该标头包含以Base-64编码的第3类消息:
The client responds to the Type 2 message by resubmitting the request with an Authorization header containing a Base-64 encoded Type 3 message:
GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjBwx6BhHRmspst9GgPOZWPuMITqcxg==
最后，服务器会验证客户端的Type 3消息中的响应，并允许访问资源.
Finally, the server validates the responses in the client's Type 3 message and allows access to the resource.
HTTP/1.1 200 OK
您必须弄清楚如何回复第2类消息的挑战，其中用户密码是MD4哈希值，用于创建DES密钥以加密质询数据.
You'll have to figure out how you'll reply to the Type 2 message's challenge, where the user's password is MD4 hashed and used to create DES keys to encrypt the challenge data.
我不确定您将如何访问登录用户的凭据数据，尽管我确定这将涉及编写本地C ++插件，因此您可以使用必要的Windows API.或者，我想您可以只要求输入用户密码.
I'm not sure how you'd get access to the logged in user's credential data which would allow you to accomplish this, though I'm sure it would involve writing a native C++ addon so you could talk to the necessary Windows API. Or, I suppose you could just ask for the user's password.
或者，您可以通过为您处理NTLM混乱的软件代理您的Node请求.
Alternatively, you could proxy your Node requests through software that handles the NTLM mess for you.
这篇关于node.js客户端中的Windows集成身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！