このリンクでは、2 つのコンテナを相互に信頼させる方法に関する情報が不足しています。「コンテナ間の信頼」からの引用です。
元の呼び出し元 ID または指定された ID を使用してターゲット Bean を呼び出すようにエンタープライズ Bean が設計されている場合、ターゲット Bean は伝搬された ID のみを受け取ります。ターゲット Bean は認証データを受け取りません。
伝搬されたセキュリティー ID をターゲット・コンテナーが認証する方法はありません。ただし、セキュリティ ID は承認チェック (メソッドのアクセス許可や isCallerInRole メソッドなど) で使用されるため、>セキュリティ ID が本物であることが非常に重要です。伝播された ID を認証するために利用できる認証データがないため、ターゲットは、呼び出し元のコンテナが認証されたセキュリティ ID を伝播したことを信頼する必要があります。
デフォルトでは、GlassFish サーバーは、さまざまなコンテナーから伝搬された ID を信頼するように構成されています。したがって、信頼関係を設定するために特別な手順を実行する必要はありません。
最後の部分は私を怖がらせます。しかし、とにかく、2つのコンテナーを信頼し、相互に信頼しないようにする方法を知りたいです.Tomcat 5.5とGlassfish 3.1.2の間でこれが可能であれば(あるコンテナーから別のコンテナーに @RunAs を使用する必要があるため) .
私の問題をさらに明確にするために、私がしなければならないことと私の解決策をお伝えします。
クライアントがファイルをダウンロードできるように Restful Web サービスを作成しています。この Web サービスは *CONTAINER_A* にありますが、ファイルをダウンロードする前に、Web サービスは *CONTAINER_B* の EJB を呼び出してファイルのパスを取得します。 *CONTAINER_B* にもあるデータベース。問題は、*CONTAINER_B* からの EJB の呼び出しが CONTAINER_A の Web サービスによってのみアクセスされるようにしたいということです。また、*AUTHORIZED_ROLE* として機能するように、Web サービスで @RunAs アノテーションを使用しています。問題は、Web サービスにアクセスするクライアント (これを *WEB_CLIENT* と呼びましょう) は、Web サービスにアクセスするために認証される必要はありませんが、*CONTAINER_B* の EJB は *AUTHORIZED_ROLE* のみがアクセスできるように保護されています。
それは明らかですか？それとも、私は物事を複雑にしすぎていますか? より良いアプローチはありますか？@RunAs ソリューションは、JAX-RS Web サービスを @Stateless Bean にする場合にのみ使用でき、ファイル システム操作 (ファイルを読み取って送り返すなど) を使用することはお勧めできませんが、今のところ、私ができる唯一のソリューションです。のことを考える。