Windows a intégré L'authentification dans node.Client js

Lors de l'utilisation de nœud.js en tant que client, est-il possible de se connecter à un serveur en utilisant L'authentification intégrée Windows (par exemple lors de la connexion à IIS)?

Mes recherches pour ceci ne donnent que des résultats où le noeud.js est utilisé comme serveur.

19
demandé sur rekire 2012-12-19 13:26:40

3 réponses

mise à Jour: il y a maintenant quelques modules qui implémentent L'authentification intégrée à Windows. node-sspi utilise SSPI (L'API de sécurité Windows) pour gérer le côté serveur des choses, mais ne pas faire de l'authentification des clients. Il y a plusieurs implémentations clienthttp-ntlm, mais ils ne sont pas vraiment intégrés puisqu'ils nécessitent le mot de passe de l'utilisateur -- ils n'utilisent pas SSPI pour faire transparent auth.

"Windows integrated authentication" est ce qu'on appelle l'authentification NTLM. Lorsque vous recevez un HTTP 401 de IIS avec un WWW-Authenticate en-tête contenant NTLM, vous avez maintenant le plaisir d'implémenter le protocole D'authentification NTLM. Citant ce document sur le protocole D'authentification NTLM:

  1. Le client demande une ressource protégée de la serveur:

    GET /index.html HTTP/1.1

  2. Le serveur répond avec un 401 statut, indiquant que le client doit s'authentifier. NTLM est présenté comme un mécanisme d'authentification via le WWW-Authenticate en-tête. Typiquement, le serveur ferme la connexion à ce moment:

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

    notez Qu'Internet Explorer ne sélectionnera NTLM que s'il s'agit du premier mécanisme proposé; ceci est en contradiction avec la RFC 2616, qui stipule que le client doit sélectionner le plus fort pris en charge un dispositif d'authentification.

  3. le client renvoie la requête avec un Authorization en-tête contenant un Type 1 message paramètre. Le message de Type 1 est codé Base-64 pour la transmission. À partir de ce moment, la connexion est maintenue ouverte; la fermeture de la connexion nécessite l'authentification des demandes ultérieures. Cela implique que le serveur et le client doivent prendre en charge les connexions persistantes, via L'en-tête "Keep-Alive" de type HTTP 1.0 ou HTTP 1.1 (dans lequel les connexions persistantes sont employées par défaut). Les en-têtes pertinents de la demande sont les suivants:

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

  4. Le serveur répond avec un 401 statut contenant un message de Type 2 dans le WWW-Authenticate en-tête (de nouveau encodé Base-64). Ceci est illustré ci-dessous.

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

  5. le client répond au message de Type 2 en renvoyant la demande avec un Authorization en-tête contenant une Base-64 encodée message de Type 3:

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

  6. enfin, le serveur valide les réponses dans le message de Type 3 du client et permet l'accès à la ressource.

     HTTP/1.1 200 OK

Vous aurez à comprendre comment vous allez répondre à la contestation du message de Type 2, où le mot de passe de l'utilisateur est MD4 hashé et utilisé pour créer des clés DES pour crypter les données de challenge.

Je ne suis pas sûr comment vous obtiendriez l'accès aux données d'identification de l'utilisateur connecté qui vous permettrait d'accomplir ceci, mais je suis sûr que cela impliquerait d'écrire un C++ natif addon pour que vous puissiez parler à L'API Windows nécessaire. Ou, je suppose que vous pourriez demander le mot de passe utilisateur.

vous pouvez proxy de votre Nœud de demandes par le biais du logiciel qui gère le NTLM mess pour vous.

27
répondu josh3736 2015-10-01 18:32:09

Pour Kerberos:

  • node-sspi

    Just on windows
No client side node
Supports NTLM too

  • passeport-négocier

    Needs python on the server
it's a passportJs strategy

For NTLM

  • node-sspi

    Just on windows
No client side node
Supports Kerberos too
  • httpntlm
  • express-ntlm
  • demande-ntlm

  • ntlm

    experimental project!

  • ntlm-auth 

        experimental!

  • passeport-ntlm

        supports SMB protocol
    it's a passportJs strategy

j'ai choisi passport-negotiate pour Kerberos et express-ntlm pour NTLM

1
répondu DaNeSh 2016-05-27 18:45:09

côté client, ce qui fonctionne est d'utiliser node-libcurl pour faire des appels REST / HTTP.

voici un exemple de code:

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();
0
répondu zumalifeguard 2017-12-28 22:25:29