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

Posted 2023-02-15

【中文标题】node.js 客户端中的 Windows 集成身份验证

【英文标题】：Windows Integrated Authentication in node.js Client

【发布时间】：2012-12-06 14:45:39

【问题描述】：

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

我对此的搜索只出现了 node.js 用作服务器的结果。

【参考方案1】：

2015 年更新：现在有一些模块实现了 Windows 集成身份验证。 node-sspi 使用 SSPI（Windows 安全 API）来处理服务器端的事情，但 does not do client auth。有several client implementations，比如http-ntlm，但它们并没有真正集成，因为它们需要用户密码——它们不使用SSPI进行透明验证。

2019 年更新：似乎可以使用 kerberos 库使用 SSPI 执行真正的 Windows 集成 HTTP 身份验证（即，使用节点进程的令牌进行透明身份验证）。见kerberos-agent。显然，这使用的是 Kerberos 而不是 NTLM/Negotiate，因此这可能会也可能不会根据您的具体情况来工作。

---

“Windows 集成身份验证”就是所谓的 NTLM 身份验证。当您从 IIS 收到带有包含 NTLM 的 WWW-Authenticate 标头的 HTTP 401 时，您现在可以享受实现 NTLM 身份验证协议的乐趣。引用this document about the NTLM authentication protocol:

---

客户端向服务器请求一个受保护的资源：

GET /index.html HTTP/1.1

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

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

请注意，Internet Explorer 仅在它是提供的第一种机制时才会选择 NTLM；这与 RFC 2616 不一致，RFC 2616 规定客户端必须选择支持的最强身份验证方案。

客户端使用包含Type 1 message 参数的Authorization 标头重新提交请求。 Type 1 消息经过 Base-64 编码以进行传输。从现在开始，连接保持打开状态；关闭连接需要重新验证后续请求。这意味着服务器和客户端必须支持持久连接，通过 HTTP 1.0 样式的“Keep-Alive”标头或 HTTP 1.1（默认情况下使用持久连接）。相关请求头显示如下：

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

服务器回复401 状态，在WWW-Authenticate 标头中包含Type 2 message（同样，Base-64 编码）。如下所示。

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

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

GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjBwx6BhHRmspst9GgPOZWPuMITqcxg==

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

 HTTP/1.1 200 OK

---

您必须弄清楚您将如何reply to the Type 2 message's challenge，其中用户的密码经过 MD4 散列并用于创建 DES 密钥来加密挑战数据。

我不确定您将如何访问已登录用户的凭据数据，这将允许您完成此操作，但我确信这将涉及编写 native C++ addon 以便您可以与必要的 Windows API。或者，我想您可以只询问用户的密码。

或者，您也可以proxy your Node requests through software that handles the NTLM mess for you。

【讨论】：

谢谢，我试试代理。

您还可以看到协商，尤其是在域环境中。在这种情况下，Kerberos 票证将包含在 Authorization 标头中。

Windows 集成身份验证 现在意味着 Kerberos。 NTLM 已弃用。 OP还要求客户端。因此，答案是题外话。

@amadeus：他问到使用节点 as 作为 IIS 的客户端，这正是这个答案。关于 Kerberos 与 NTLM，Negotiate 的 WWW-Authenticate 标头意味着服务器支持两者（在较新的 IIS 中默认）。您当然可以追求实施 Kerberos —— 有 a couple modules on npm，但它们的文档记录很差。

我发现从客户端执行此操作的最简单方法是使用 node-libcurl。 ***.com/a/48015144/75129

【参考方案2】：

对于 Kerberos：

节点-sspi

Just on windows
No client side node
Supports NTLM too

护照协商

Needs python on the server
it's a passportJs strategy

对于 NTLM

节点-sspi

Just on windows
No client side node
Supports Kerberos too

httpntlm express-ntlm 请求-ntlm

ntlm

experimental project!

ntlm-auth

experimental!

护照-ntlm

supports SMB protocol
it's a passportJs strategy

我为 Kerberos 选择了 passport-negotiate，为 NTLM 选择了 express-ntlm

【讨论】：

node-sspi 根据Caveats 无法正确使用 Kerberos

node-expose-sspi 适用于 Kerberos 和 NTLM（协商）。注意：我是node-expose-sspi的作者。

【参考方案3】：

对于客户端，有效的方法是使用 node-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();