認証を使用したセキュリティで保護された接続の確立
クライアント/サーバー アプリケーション プロトコルでは、サーバーはソケットや RPC インターフェイスなどの通信ポートにバインドされます。 その後、サーバーはクライアントの接続を待機し、サービスを要求します。 相互認証の場合、接続セットアップでのセキュリティの役割は 2 倍になります。
- サーバーによるクライアント認証。
- クライアントによるサーバー認証。
トランスポート アプリケーションのクライアント コンポーネントとサーバー コンポーネントは、 セキュリティ パッケージ を使用して、メッセージを送信するためのセキュリティで保護された接続を確立します。 セキュリティで保護された接続を確立するための最初の手順は、 セキュリティ コンテキストを作成することです。つまり、 セッション キーやセッション の期間など、接続に関連するセキュリティ データを含む不透明なデータ構造です。
セキュリティ コンテキストは、基本的には、クライアントに関連付けられているセキュリティ パッケージからサーバーに関連付けられているセキュリティ パッケージへのメッセージです。 そのため、通常、セキュリティ コンテキストを作成するには、クライアントとサーバーの両方がそれぞれのセキュリティ パッケージを呼び出す必要があります。 コンテキスト関数の詳細については、「 コンテキスト管理」を参照してください。
セキュリティで保護された認証された接続を確立するために使用されるプロトコルには、クライアントとサーバーの間で 1 つ以上の "セキュリティ トークン" が交換されます。 これらのトークンは、他の アプリケーション プロトコル固有の情報と共に、2 つの側によって不透明なメッセージとして送信されます。 不透明なメッセージとして、トークンはクライアントによってセキュリティ パッケージ関数から受信され、これを解釈または変更できず、メッセージとしてサーバーに転送されます。 トークンはサーバーに対しても不透明であり、トークンを解釈したり変更したりすることはできません。 サーバーは、解釈のために不透明なトークンをセキュリティ パッケージに転送します。 その後、パッケージは、クライアント認証または認証の失敗をサーバーに通知します。
クライアントはメッセージでサーバーのトークンを受信し、受信したメッセージからトークンを取得し、そのトークンをセキュリティ パッケージの呼び出しで使用します。 その後、クライアントはセキュリティ パッケージを再度呼び出し、セキュリティで保護された接続が確立されているかどうか、またはセキュリティで保護された接続の準備が整う前にそれ以上の交換が必要かどうかを示します。 理論的には、必要なセキュリティ トークンの交換の数に制限はありません。 実際には、限られた数の交換のみが必要です。 NTLM 認証はチャレンジ/応答スキームに基づいており、3 つの脚を使用してクライアントをサーバーに対して認証します。 Kerberos バージョン 5.0 プロトコルでは、追加のメッセージ交換が必要な場合があります。
関連トピック