4

TcpClient/TcpListenerベースのクライアントサーバーアプリケーションを開発しています。これで、ユーザーを認証する必要があります。サーバー側でPrincipalContext-Classを使用して、クライアントにユーザー名/パスワード/ドメインを要求することはできますが、ネットワーク経由でクレデンシャルを送信したくありません。さらに、ユーザーに資格情報を再度要求したくありません。つまり、パススルー認証をサポートするCitrixReceiverを知っています。現在ログオンしているユーザーを使用し、資格情報を要求せず、サーバーに対してユーザーを認証します。それはうまくいきます。

アプリケーションでこれを行うにはどうすればよいですか？サーバーに送信できるトークンの種類を考えましたが、解決策が見つかりませんでした。

4

3 に答える 3

2

NetworkStream をNegotiateStreamNegotiateAs...でラップし、クライアントとサーバーの両方で適切なメソッドを呼び出します。

クライアントは許可する偽装レベルを指定でき、サーバーは必要なレベルを指定できます (最小限Identification、クライアント ID を判別するためですが、クライアントとしてローカルまたはネットワーク リソースにアクセスする必要がある場合は、Impersonationor を指定することもできます。正しいネットワーク構成Delegation)。

認証が完了すると、サーバーはクライアントの ID を特定したり、NegotiateStream のRemoteIdentityプロパティを使用して偽装したりできます。

コメントで述べたように、Citrix がこのセットアップにどのように影響するかはわかりませんが (使用したことはありません)、アプリケーションに対して基本的に完全に透過的であり、すべてが標準の Windows 資格情報を使用する場合、これは機能するはずです。

于 2012-05-18T11:56:33.787 に答える
1

.net Framework には、diffie-hellmann Key Exchange の機能があります。

http://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch

http://www.codeproject.com/Articles/24632/Shared-Key-Generation-using-Diffie-Hellman

于 2012-05-18T10:31:59.287 に答える
0

アプリケーションのクライアント部分とサーバー部分の両方を作成している場合は、ユーザーの資格情報を暗号化してネットワークを通過させ、相手側で解読することができます。

クライアント マシン上で、悪意のあるユーザーが (文字列などを使用して) アプリケーションから暗号化キーを抽出できるという前提に基づいて作業する場合、対称暗号化は適切ではありません。したがって、非対称 (パブリック/プライベート) 暗号化が適しているようです。鍵のペアを生成すると、サーバーの鍵は (サーバー上でのみ) 秘密のままにしておく必要があり、クライアントの鍵をクライアント マシンのアプリケーションに含めることができます。資格情報はサーバー上の秘密鍵と安全な秘密鍵を使用してのみ復号化できるため、鍵がアプリから抽出されても問題ありません。このクラスでは、基本的な作業のほとんどが行われました。

于 2012-05-18T10:23:13.677 に答える