サーバーに対してクライアントを認証するには 、Secure Sockets Layer (SSL) のクライアント認証を使用する方法もあります。
SSL クライアント認証の使用は、サーバーに対してクライアントを認証するもう 1 つの方法です。 この形式の認証は、ユーザー ID とパスワード、またはトークンを使用したメッセージ層では行われません。 この認証が行われるのは、SSL 証明書を使用した接続ハンドシェーク中です。
クライアントが キー・リング・ファイルにある個人証明書を使用して構成され (SSL クライアント認証が必要です)、 サーバーが SSL クライアント認証をサポートしている場合は、以下のアクションによって、 クライアント・サイドで識別が確立されます。
構成で SSL と SSL クライアント認証が指定されているため、接続タイプは SSL であり、SSL ハンドシェークはクライアントの証明書を妥当性検査のためにサーバーに送信します。クライアント証明書の妥当性が確認されない場合は、 接続は確立されず、メソッドが呼び出されたクライアント・コードに例外が戻され、失敗したことが示されます。 クライアント証明書の妥当性が確認されれば、 クライアントとサーバーの間の接続が開きます。
例えば、同時に基本認証が構成されている場合は、 ユーザー ID とパスワードの入力を求めるプロンプトが出されることがあります。 このアクションは不要であるため、SSL 証明書がメソッドの呼び出し対象である識別である場合は、 構成でこのオプションを使用不可にしておいてください。メッセージ層セキュリティーが存在しない場合は、セキュリティー・コンテキストが作成されて要求に関連付けられることはありません。
サーバーはサービス・コンテキストを検出しないため、 サーバー・ソケットでクライアント識別が入っているクライアント証明書チェーンを調べます。 ここでは、クライアントからの証明書チェーンが見つかります。 接続が確立されているため、証明書チェーン内の識別は有効です。 クレデンシャルを作成するには、証明書からの識別をユーザー・レジストリーにマップします。 このアクションは、認証メカニズムのタイプに応じたそれぞれの方法で行われます。
証明書のクレデンシャルへのマッピングは、 ユーザー・レジストリー・タイプに応じたそれぞれの方法で行われます。
SSL クライアント証明書認証の利点の 1 つは、通常は SSL 接続が作成されるため、 認証のパフォーマンスが最適化されるということです。 クライアント証明書を送信する際の余分なオーバーヘッドもごくわずかです。 クライアント・サイドの要求インターセプターはアクティビティーを実行しませんが、 サーバー・サイドの要求インターセプターは証明書をクレデンシャルにマップします。
このタイプの認証の欠点の 1 つは、 クライアント・システムごとに鍵リング・ファイルをセットアップするのが煩雑だということです。
SSL クライアント証明書の認証が機能するようにするには、HTTP トランスポート TrustedProxy カスタム・プロパティーも false に設定する必要があります。