ADが使用されていない2層クライアント/サーバーレガシーアプリケーション（SQL Server 2008 R2）で、IPSecなどを使用せずにx.509PKI証明書に基づくユーザー認証と承認を追加したいと思います。
クライアントは、SQL Serverに接続する前に、既存のSTS / WS-trustサービスを使用して、署名されたSAMLトークンを取得できます。
SQL ServerのSSLオプションは、これまでのところ、相互（双方向）認証をサポートしていません。1つの考えは、認証（またはSAMLトークン検証）を実行するカスタム.NETストアドプロシージャを使用することでした。その後、ユーザーの現在のSQL Serverログインが「有効」になりますが、より適切なオプションが必要です。
これを達成するための良いアプローチは何でしょうか？
stunnelを使用して証明書で認証された SSL エンドポイントを作成し、SSL プロトコルを介して Windows 認証または組み込みの SQL Server 認証を使用できます。
証明書を従来のクライアント/サーバーに改造しようとするプロジェクトをいくつか見てきました。これを行う 1 つの方法は、SSL 認証を担当するサービスをサーバー上に置くことです (このサービスと SQL Server 間の通信は暗号化されません)。
時間に応じて、このソリューションには 2 つの極端な方法があります。
最も単純なケースでは、SSL サービスは、クライアント証明書が有効であり、信頼できる CA によって発行されていることのみを確認します。より複雑な状況では、SSL サービスはクライアント証明書をアカウントにマップし、SQL Server で SQL ログインを開始します (オプションでパスワードを定期的に変更します)。