Интегрированная проверка подлинности Windows в node.js Client

При использовании node.js в качестве клиента можно ли подключиться к серверу с помощью встроенной проверки подлинности Windows (например, при подключении к IIS)?

Мои поиски только показывают результат, когда node.js используется как сервер.

Ответы

Ответ 1

Обновление 2015: В настоящее время есть несколько модулей, которые реализуют встроенную проверку подлинности Windows. node-sspi использует SSPI (API безопасности Windows) для обработки серверной части, но не выполняет аутентификацию клиента. Существует несколько клиентских реализаций, таких как http-ntlm, но они не являются действительно интегрированными, поскольку им требуется пароль пользователя - они не используют SSPI для прозрачной аутентификации.

Обновление 2019: По-видимому, можно использовать библиотеку kerberos для выполнения истинной интегрированной в Windows HTTP-аутентификации с использованием SSPI (т.е. использовать токен процесса узла для прозрачной аутентификации). Смотрите kerberos-agent. Очевидно, что здесь используется Kerberos, а не NTLM/Negotiate, поэтому это может работать, а может и не работать, в зависимости от конкретной ситуации.

"Встроенная проверка подлинности Windows" - это то, что называется проверкой подлинности NTLM. Когда вы получаете HTTP 401 от IIS с заголовком WWW-Authenticate, содержащим NTLM, у вас теперь есть удовольствие от реализации протокола аутентификации NTLM. Цитата из этого документа о протоколе аутентификации NTLM:

Клиент запрашивает защищенный ресурс с сервера:
```
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, в котором говорится, что клиент должен выбрать самую надежную поддерживаемую схему аутентификации.
Клиент повторно отправляет запрос с заголовком Authorization, содержащим параметр сообщения типа 1. Сообщение типа 1 кодируется Base-64 для передачи. С этого момента соединение остается открытым; закрытие соединения требует повторной аутентификации последующих запросов. Это означает, что сервер и клиент должны поддерживать постоянные соединения через заголовок "Keep-Alive" в стиле HTTP 1.0 или HTTP 1.1 (в котором постоянные соединения используются по умолчанию). Соответствующие заголовки запроса выглядят следующим образом:
```
GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg==
```

Сервер отвечает статусом 401, содержащим сообщение типа 2 в заголовке WWW-Authenticate (опять же, в кодировке Base-64). Это показано ниже.

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

Клиент отвечает на сообщение типа 2, повторно отправляя запрос с заголовком Authorization, содержащим закодированное в Base-64 сообщение типа 3:

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

Наконец, сервер проверяет ответы в сообщении клиента типа 3 и разрешает доступ к ресурсу.
```
 HTTP/1.1 200 OK
```

Вам нужно будет выяснить, как вы будете отвечать на вызов сообщения типа 2, где пароль пользователя является хэшированным MD4 и используется для создания ключей DES для шифрования данных запроса.

Я не уверен, как вы получите доступ к зарегистрированным учетным данным пользователя, которые позволят вам сделать это, хотя я уверен, что это потребует написания нативного аддона C++, чтобы вы могли поговорить с необходимым Windows API. Или, я полагаю, вы могли бы просто попросить пароль пользователя.

В качестве альтернативы, вы можете проксировать свои запросы Node через программное обеспечение, которое обрабатывает для вас NTLM-беспорядок.

Ответ 2

Для Kerberos:

Узел-SSPI

Just on windows
No client side node
Supports NTLM too

Паспорт-переговоры

Needs python on the server
it a passportJs strategy

Для NTLM

Узел-SSPI

Just on windows
No client side node
Supports Kerberos too

httpntlm
экспресс-NTLM
запроса NTLM
NTLM
```
experimental project!
```
NTLM-аутентификация
```
experimental!
```

паспорт NTLM

supports SMB protocol
it a passportJs strategy

Я выбрал паспорт-переговоры для Kerberos и express-ntlm для NTLM

Ответ 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();