これにはかなり多くの配管が関係しています。トリッキーな部分は次のとおりです。
- 注釈を処理し、非継承およびオーバーライドの規則を尊重する (xml のオーバーライドを参照しない)
- 注釈が誤用されたり、誤って適用されたりしないようにする
- xml を尊重し、注釈データをオーバーライドする
- 宣言された「役割」で「許可された役割」をマッピングします（間接的なレベルがあります）
- すべてのメタデータを適切にフォーマットされた許可文字列として JACC プロバイダーに追加する
- 適切に構成された JAAS LoginModule によるログインの処理
- JAAS を JACC と統合するためのいくつかの独創的なコード (それを行う標準的な方法はありません)
doAs通話または通話で件名を追跡するThreadLocal- メソッドが実際に呼び出される前に認証チェックを実行できるように、すべてのオブジェクトをプロキシする
- @RunAs でアノテーションが付けられたメソッドのセキュリティ コンテキストを変更し、RunAs ロールが宣言されたロールであることを確認する
- 対処
EJBContext.getCallerPrincipal()(aSubjectには多くのPrincipalオブジェクトがあるため、返されるオブジェクトを 1 つ選択し、一貫して同じオブジェクトを選択できるようにする必要があります)
EJBContext.isCallerInRole(String)JACC プロバイダーへの配線- ログインの失敗、承認の失敗、およびその他のさまざまな条件を処理するときに、適切な例外クラスを使用していることを確認する
それがコンテナの機能です。JAAS と JACC の仕事は本当に小さいです。確かに、少なくとも詳細指向ではありません。
あなたが望んでいたように、これのどれも実際に「注入」することはできません。セキュリティは実質的に回避策です。
表面的には、注釈ベースのセキュリティなどは非常に単純に見えます。ただし、すべての組み合わせ、注意事項、および条件を検討すると、実際には合計されます。最初にそれらを実装しなければならなかったときにすべて間違っていたので、上記のすべての詳細を覚えています。:) TCKに感謝します。
独自のセキュリティ テスト フレームワークを作成しようとすることはお勧めしません。
テストを行う特定の方法がある場合は、OpenEJB または Arquillian に参加するのが最も賢明です。
OpenEJB の最も優れた機能はすべて、ユーザーの苦痛と「これを行うと痛い」と私たちに説明する人々から生まれました。私達はそれが大好き。これは、優れた機能のソースであり、新しい貢献者を獲得する優れた方法であり、仕様に取り入れるのに適したアイデア (EJB 3.1 の組み込み EJBContainer API など) を証明する優れた方法です。
イノベーションを回避しようとするのではなく、イノベーションに参加することの重要性はいくら強調してもしすぎることはありません。何かがあなたのニーズを満たさない場合は、より良いものを要求してください。
その最後の声明は、一般的に世界に向けられています:)