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

Ответ 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:

1. Клиент запрашивает защищенный ресурс с сервера:

   GET /index.html HTTP/1.1
   

2. Сервер отвечает статусом 401, указывающим, что клиент должен пройти аутентификацию. NTLM представлен как поддерживаемый механизм аутентификации через заголовок WWW-Authenticate. Обычно сервер закрывает соединение в это время:

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

   Обратите внимание, что Internet Explorer будет выбирать NTLM, только если это первый предложенный механизм; это противоречит RFC 2616, в котором говорится, что клиент должен выбрать самую надежную поддерживаемую схему аутентификации.

3. Клиент повторно отправляет запрос с заголовком Authorization, содержащим параметр сообщения типа 1. Сообщение типа 1 кодируется Base-64 для передачи. С этого момента соединение остается открытым; закрытие соединения требует повторной аутентификации последующих запросов. Это означает, что сервер и клиент должны поддерживать постоянные соединения через заголовок "Keep-Alive" в стиле HTTP 1.0 или HTTP 1.1 (в котором постоянные соединения используются по умолчанию). Соответствующие заголовки запроса выглядят следующим образом:

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

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

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

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

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

6. Наконец, сервер проверяет ответы в сообщении клиента типа 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();