Autenticación integrada de Windows en el cliente node.js

node.js-client windows-integrated-auth

Question

Al usar node.js como cliente, ¿es posible conectarse a un servidor usando la autenticación integrada de Windows (por ejemplo, cuando se conecta a IIS)?

Mis búsquedas para esto solo muestran resultados donde node.js se usa como un servidor.

Answer 1

Para Kerberos:

• node-sspi

  Just on windows
  No client side node
  Supports NTLM too

• negociar pasaporte

  Needs python on the server
  it''s a passportJs strategy

Para NTLM

• node-sspi

  Just on windows
  No client side node
  Supports Kerberos too

• httpntlm
• expreso-ntlm
• request-ntlm

• ntlm

  experimental project!

• ntlm-auth

   experimental!

• pasaporte-ntlm

   supports SMB protocol
  it''s a passportJs strategy

Elegí el pasaporte-negociar para Kerberos y Express-ntlm para NTLM

Answer 2

Para el lado del cliente, lo que funciona es usar node-libcurl para hacer llamadas REST / HTTP.

Aquí está el código de ejemplo:

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();

Answer 3

Actualización: ahora hay algunos módulos que implementan la autenticación integrada de Windows. node-sspi usa SSPI (la API de seguridad de Windows) para manejar el lado del servidor de las cosas, pero no realiza la autenticación del cliente . Existen varias implementaciones de clientes , como http-ntlm , pero no están realmente integradas, ya que requieren la contraseña del usuario; no utilizan SSPI para realizar la autenticación transparente.

"Autenticación integrada de Windows" es lo que se conoce como autenticación NTLM. Cuando recibe un HTTP 401 de IIS con un encabezado WWW-Authenticate contiene NTLM , ahora tiene la diversión de implementar el protocolo de autenticación NTLM. Citando este documento sobre el protocolo de autenticación NTLM :

1. El cliente solicita un recurso protegido del servidor:

   GET /index.html HTTP/1.1

2. El servidor responde con un estado 401 , lo que indica que el cliente debe autenticarse. NTLM se presenta como un mecanismo de autenticación compatible a través del encabezado WWW-Authenticate . Normalmente, el servidor cierra la conexión en este momento:

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

   Tenga en cuenta que Internet Explorer solo seleccionará NTLM si es el primer mecanismo ofrecido; esto está en desacuerdo con RFC 2616, que establece que el cliente debe seleccionar el esquema de autenticación compatible más sólido.

3. El cliente vuelve a enviar la solicitud con un encabezado de Authorization contiene un parámetro de mensaje de Tipo 1 . El mensaje Tipo 1 está codificado en Base-64 para transmisión. Desde este punto en adelante, la conexión se mantiene abierta; cerrar la conexión requiere la reautenticación de solicitudes posteriores. Esto implica que el servidor y el cliente deben admitir conexiones persistentes, ya sea a través del encabezado "Keep-Alive" del estilo HTTP 1.0 o HTTP 1.1 (en el que las conexiones persistentes se emplean de forma predeterminada). Los encabezados de solicitud relevantes aparecen como sigue:

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

4. El servidor responde con un estado 401 contiene un mensaje de Tipo 2 en el encabezado WWW-Authenticate (de nuevo, codificado en Base-64). Esto se muestra a continuación.

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

5. El cliente responde al mensaje de Tipo 2 volviendo a enviar la solicitud con un encabezado de Authorization contiene un mensaje de Tipo 3 codificado en Base-64:

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

6. Finalmente, el servidor valida las respuestas en el mensaje Tipo 3 del cliente y permite el acceso al recurso.

    HTTP/1.1 200 OK

Tendrá que averiguar cómo responderá al desafío del mensaje Tipo 2 , donde la contraseña del usuario es un hash MD4 y se utiliza para crear claves DES para cifrar los datos del desafío.

No estoy seguro de cómo obtendría acceso a los datos de credenciales del usuario que inició sesión, lo que le permitiría lograr esto, aunque estoy seguro de que implicaría escribir un complemento nativo de C ++ para poder hablar con la API de Windows necesaria. O bien, supongo que podría pedir la contraseña del usuario.

De forma alternativa, podría enviar sus solicitudes de Nodo a través del software que maneja el desorden NTLM por usted .