5

一般的なケース: EJB (3.1) を介してサービスを公開する単純なアプリケーション - そのほとんどはステートレス セッション Bean (ここでは何も機能しません) と、リモート インターフェイスを介してこれらのサービスを呼び出し、必要な処理を行う SWING ベースのクライアントです。

セキュリティ: この呼び出しのサイクルを認証/承認し、もちろんサービスを保護したいと考えています。明白な答えは、サーバーで JAAS を使用し、基盤となるサーバーで任意のカスタム ワイヤリング セットアップを使用することです。それはまだオプションです

Apache Shiro : 多くの人が Apache Shiro について話していますが、実際には非常に単純な API とメカニズムを備えており、アプリケーション サーバーに依存しない可能性があります。

技術的な質問:

  1. セッション: 私の場合、私は HTTP セッションを持っていません。私が理解していることから、Shiro は少なくとも、渡す必要があるある種の SESSION ID を必要としています。ビジネス API を汚染せずに、サーバーへの RMI/IIOP 呼び出しにユーザー資格情報を注入する良い方法はありますか?

  2. サーバー側の実装: 私が経験したいくつかのリソースについては、Singleton EJB 3.1 Bean から「参照」することで Shiro DefaultSecurityManager を実装できると思います。他のアイデアはありますか？次に、簡単にインターセプターを作成してリモート呼び出しに追加できます。つまり、新しい呼び出しがリモート EJB メソッドを通過するときに、Shiro Interceptor を使用して、ユーザーを検証したり、特定の権限を確認したりできます。

コメント/ヒント/例はありますか?

どうもありがとう

4

1 に答える 1

0

shiro から、ServiceLocator パターンを使用してみます。EJB のルックアップは、コンテナー (JBoss、Netweaver、Weblogig など) によって異なります。

Application Server では、コンテナー ベースのセキュリティの制約 (@RolesAllowed、@PermitAll、@Deny...) を使用してみてください。JAAS はユーザーのプリンシパルでサブジェクトを作成するため、コンテナー承認 (@RolesAllowed、@PermitAll、@Deny...) を使用するだけです。あるコンテナーから別のコンテナーに移行する場合は、より適切になる可能性があります。

于 2012-06-13T12:26:56.560 に答える