web-dev-qa-db-ja.com

node.jsクライアントでのWindows統合認証

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

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

node.jswindowswindows-authenticationnode.js-client
25
laktak

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

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

「Windows統合認証」は、NTLM認証と呼ばれるものです。 IISからHTTP 401を受信し、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. クライアントは、 タイプ1メッセージ パラメータを含むAuthorizationヘッダーを使用してリクエストを再送信します。タイプ1メッセージは、送信用にBase-64でエンコードされています。この時点以降、接続は開いたままになります。接続を閉じるには、後続の要求の再認証が必要です。これは、サーバーとクライアントが、HTTP 1.0スタイルの "Keep-Alive"ヘッダーまたはHTTP 1.1（永続的な接続がデフォルトで採用されている）を介した永続的な接続をサポートする必要があることを意味します。関連するリクエストヘッダーは次のように表示されます。

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

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

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

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

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

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

     HTTP/1.1 200 OK

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

ログインしたユーザーの資格情報データにどのようにアクセスして、これを実現できるかはわかりませんが、 native C++ addon を記述して話すことができると確信しています必要なWindows APIに。または、ユーザーのパスワードを尋ねるだけで済むと思います。

または、 NTLMの混乱を処理するソフトウェアを介してNodeリクエストをプロキシする のようにすることもできます。

32
josh3736

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
  • エクスプレスNTLM
  • request-ntlm

  • nTLM

    experimental project!

  • ntlm-auth

    experimental!

  • パスポートNTLM

    supports SMB protocol
it's a passportJs strategy

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

5
DaNeSh

クライアント側で機能するのは、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();
0
zumalifeguard