node.js客户端中的Windows集成身份验证

将node.js用作客户端时，是否可以使用Windows集成身份验证连接到服务器，例如连接到IIS时

我对此的搜索只会在node.js用作服务器的情况下显示结果。

2015更新：现在有一些模块实现了Windows集成身份验证。使用SSPI和Windows安全API来处理服务器端的事情，但是。有，但它们不是真正集成的，因为它们需要用户密码-它们不使用SSPI进行透明身份验证

2019年更新：似乎可以使用该库使用SSPI ie执行真正的Windows集成HTTP身份验证，使用节点进程的令牌执行透明身份验证。看见显然，这使用的是Kerberos而不是NTLM/Negotiate，因此这可能有效，也可能无效，具体取决于您的具体情况

Windows集成身份验证被称为NTLM身份验证。当您从IIS收到包含NTLM的WWW Authenticate标头的HTTP 401时，您现在可以享受到实现NTLM身份验证协议的乐趣。引述自：

客户端从服务器请求受保护的资源：

GET /index.html HTTP/1.1

服务器以401状态响应，指示客户端必须进行身份验证。NTLM通过WWW Authenticate标头作为受支持的身份验证机制提供。通常，服务器此时会关闭连接：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
Connection: close

请注意，如果NTLM是提供的第一种机制，Internet Explorer将仅选择NTLM；这与RFC2616不一致，RFC2616规定客户端必须选择受支持的最强身份验证方案

客户端使用包含参数的授权标头重新提交请求。类型1消息为Base-64编码，用于传输。从这一点开始，连接保持打开；关闭连接需要重新验证后续请求。这意味着服务器和客户端必须通过HTTP 1.0样式的Keep-Alive头或HTTP 1.1（默认情况下使用持久连接）支持持久连接。相关的请求标题如下所示：

GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg==

服务器回复401状态，在WWW认证头中再次包含，Base-64编码。如下所示

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA=

客户端通过使用包含Base-64编码的授权标头重新提交请求来响应类型2消息：

最后，服务器验证客户端的Type3消息中的响应，并允许访问资源

 HTTP/1.1 200 OK

您必须弄清楚如何对用户密码进行MD4哈希处理，并用于创建DES密钥以加密质询数据

我不确定您将如何访问登录用户的凭据数据，这将允许您完成这项工作，尽管我确定这将涉及编写一个脚本，以便您可以与必要的Windows API对话。或者，我想你可以直接询问用户的密码

或者，您可以。

对于Kerberos：

节点sspi

Just on windows
No client side node
Supports NTLM too

Just on windows
No client side node
Supports Kerberos too

护照谈判

Needs python on the server
it's a passportJs strategy

对于NTLM

节点sspi

Just on windows
No client side node
Supports NTLM too

Just on windows
No client side node
Supports Kerberos too

httpntlm 快速ntlm 请求ntlm ntlm

ntlm认证

experimental!

护照

supports SMB protocol
it's a passportJs strategy

---

我为Kerberos选择passport协商，为ntlm选择express ntlm

为客户端选择，有效的方法是使用节点libcurl进行REST/HTTP调用

下面是示例代码：

var endpoint = urlString;
var url = require("url");
var endpointUrl = url.parse(endpoint);

var Curl = require( 'node-libcurl' ).Curl;
var curl = new Curl();

curl.setOpt( 'USERNAME', '' );
//curl.setOpt( 'VERBOSE', 1 );
curl.setOpt( 'URL', endpoint );
curl.setOpt( 'HTTPAUTH', Curl.auth.NEGOTIATE );
curl.setOpt( 'NOPROXY', endpointUrl.hostname );

curl.on( 'end', function( statusCode, body, headers ) {

    if (statusCode === 200) {
        console.log(body);
        cb(null, { statusCode, body, headers } ); 
    } else {
        cb(new Error(), { statusCode, body, headers } ); 
    }

    this.close();
});

curl.on( 'error', curl.close.bind( curl ) );
curl.perform();

---

谢谢，我会试试代理。你也可以看到协商，尤其是在域环境中。在这种情况下，授权标头中将包含Kerberos票证。现在的Windows集成身份验证意味着Kerberos。NTLM已弃用。此外，OP还要求客户端。因此，答案是离题的。@amadeus：他问过关于使用node作为IIS客户端的问题，这正是他的答案。关于Kerberos vs NTLM，协商的WWW身份验证头意味着服务器在较新的IIS中支持这两种默认值。您当然可以追求实现Kerberos——确实有，但它们的文档记录非常糟糕。我发现从客户端实现这一点最简单的方法是使用node libcurl。每个节点的节点sspi不能正确地与Kerberos一起工作。暴露sspi可以与Kerberos和NTLM协商一起工作。注意：我是node expose sspi的作者。