28

node.jsをクライアントとして使用する場合、Windows統合認証を使用してサーバーに接続できますか（IISに接続する場合など）？

これを検索すると、node.jsがサーバーとして使用されている場合にのみ結果が表示されます。

4

3 に答える 3

37

2015年の更新： Windows統合認証を実装するモジュールがいくつかあります。 node-sspiはSSPI（WindowsセキュリティAPI）を使用してサーバー側を処理しますが、クライアント認証は行いません。http-ntlmなどのいくつかのクライアント実装がありますが、ユーザーパスワードが必要なため、実際には統合されていません。透過認証を行うためにSSPIを使用しません。

2019アップデート：Kerberosライブラリを使用して、SSPIを使用して真のWindows統合HTTP認証を実行することが可能であるようです（つまり、ノードプロセスのトークンを使用して透過認証を実行します）。kerberos-agentを参照してください。明らかに、これはNTLM / NegotiateではなくKerberosを使用するため、正確な状況に応じて機能する場合と機能しない場合があります。

「Windows統合認証」は、NTLM認証と呼ばれるものです。WWW-Authenticateを含むヘッダーを含むHTTP401をIISから受信すると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が提供される最初のメカニズムである場合にのみNTLMを選択することに注意してください。これは、クライアントがサポートされている最も強力な認証スキームを選択する必要があると述べているRFC2616とは相容れません。

  3. クライアントは、タイプ1メッセージパラメータAuthorizationを含むヘッダーを使用して要求を再送信します。タイプ1メッセージは、送信用にBase-64でエンコードされています。この時点から、接続は開いたままになります。接続を閉じるには、後続の要求の再認証が必要です。これは、サーバーとクライアントがHTTP1.0スタイルの「Keep-Alive」ヘッダーまたはHTTP1.1（デフォルトで持続的接続が採用されている）のいずれかを介して持続的接続をサポートする必要があることを意味します。関連するリクエストヘッダーは次のように表示されます。

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

  4. サーバーは、ヘッダーにタイプ2メッセージ401を含むステータスで応答します（ここでも、Base-64でエンコードされています）。これを以下に示します。WWW-Authenticate

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

  5. クライアントは、Base-64でエンコードされたタイプ3メッセージAuthorizationを含むヘッダーを使用してリクエストを再送信することにより、タイプ2メッセージに応答します。

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

  6. 最後に、サーバーはクライアントのタイプ3メッセージの応答を検証し、リソースへのアクセスを許可します。

     HTTP/1.1 200 OK

タイプ2メッセージのチャレンジにどのように応答するかを理解する必要があります。ここで、ユーザーのパスワードはMD4ハッシュされ、チャレンジデータを暗号化するためのDESキーの作成に使用されます。

ログインしたユーザーの資格情報データにアクセスして、これを実現する方法はわかりませんが、必要なWindowsAPIと通信できるようにネイティブC++アドオンを作成する必要があると思います。または、ユーザーのパスワードを尋ねることもできると思います。

または、 NTLMの混乱を処理するソフトウェアを介してノード要求をプロキシすることもできます。

于 2012-12-19T20:21:26.367 に答える
5

Kerberosの場合：

  • node-sspi

    Just on windows
No client side node
Supports NTLM too

  • パスポート-交渉

    Needs python on the server
it's a passportJs strategy

NTLMの場合

  • node-sspi

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

  • ntlm

    experimental project!

  • ntlm-auth

    experimental!

  • passport-ntlm

    supports SMB protocol
it's a passportJs strategy

Kerberosにはpassport-negotiateを、NTLMにはexpress-ntlmを選択しました

于 2016-05-27T18:21:33.603 に答える
-1

クライアント側の場合、機能するのは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();
于 2017-12-28T22:25:29.707 に答える