0

JNDI LDAP 認証では、クリアテキストのパスワード (Context.SECURITY_CREDENTIALS) をほぼすべてのセキュリティ メカニズム (または少なくとも私が理解している方法) に渡す必要があります。パスワードが現在のJVMに由来するように設計されているようです。しかし、別のマシンから送信する必要があるパスワードはどうでしょうか? このアプローチでは、セキュリティがほとんどない回復可能な方法 (最も単純なのはクリアテキスト) で送信する必要があります。

具体的には、クライアント、Java サーバー、および LDAP サーバーの 3 層セットアップを考えてみましょう。ユーザーは、Java サーバーに送信されるクライアントにユーザー名とパスワードを入力します。次に、Java サーバーは、これらの資格情報を承認するために LDAP サーバーと通信します。クライアントからJavaサーバーへの送信を安全にする方法はありますか? チャネル自体を保護するために SSL または別の方法を使用できることは理解していますが、このチャネル (たとえ安全であっても) を介して回復可能な方法でパスワードを送信する必要があるのはまだ良くありません。

回答を探してみたのですが、2段構成を検討されている方が多いようです。(JNDI の代わりに) サードパーティの Java ライブラリの推奨事項もいくつかありましたが、それらが私のタスクを処理できるかどうかは明確ではありませんでした。彼らが実際にそうしているなら、私の仕事にそれらを利用する例を挙げていただけますか?

私のターゲット プラットフォームは、Delphi XE3 クライアント、Java SE 6 サーバー、および AD LDAP です。しかし、これらの具体的なクライアントと LDAP に限定されない、より理論的な議論にも興味があります。

4

2 に答える 2

1

その答えを見つけ、実際に本番システムで動作させました。正しいパスは、Kerberos プロトコルhttp://en.wikipedia.org/wiki/Kerberos_(protocol)を使用することです。

私のセットアップでは、次のことが起こります。

1) クライアントは、AD 内のサーバー サービスへのチケットを取得し、それをサーバーに送信します。TSSPIWinNTCredentialsこれはclass inの近くのクラスを介して行われIndyますが、Windows の機能を直接使用しても問題なく実行できると思います。

2) サーバーはサービスとして AD にログインします。これはLoginContext、正しいAppConfigurationEntryキーを使用してクラスを介して行われます。

3) サーバーはクライアントのチケットを使用して AD でクライアントを認証し、クライアントのユーザー名を取得します。これは、Subject.doAsメソッドとクラスの近くのGSSManagerクラスを介して行われます。

4) サーバーは追加のビジネス レベル チェックを実行し、クライアントにビジネス セッションを許可します。もちろん、これはビジネス固有のものです。

このシナリオでは、回復可能な方法でパスワードを送信するなど、安全でない通信が行われることはありません。これは、Kerberos プロトコル自体の設計目標であるためです。

于 2013-11-21T15:47:44.640 に答える
1

このアプローチでは、ほとんどセキュリティのない回復可能な方法 (最も単純なのはクリアテキスト) で送信する必要があります。

このアプローチでは、SSL を使用する必要があります。それはそれと同じくらい簡単です。

于 2013-09-08T23:43:16.000 に答える