node.js客户端中的Windows集成身份验证 [英] Windows Integrated Authentication in node.js Client
问题描述
使用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)来处理服务器端的事情，但不进行客户端身份验证.有多个客户端实现，例如
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=
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.
我不确定您将如何访问登录用户的凭据数据，尽管我确定这将涉及编写
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集成身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
