0

問題

アプリケーション クライアントのクラスに @EJB プロキシを挿入し、Mainその EJB にユーザーが特定のロールにいることを要求するメソッドがある場合、アプリケーション クライアント コンテナー (ACC) は、ユーザーがログインするとすぐにログインすることを要求します。アプリケーション クライアントが起動します。ACC は、クライアントが呼び出すことを念頭に置いていたメソッドを区別しないため、クライアントが実際に必要な役割 (存在する場合) は何であるかを区別しません。 EJB の 1 つのメソッドだけが、特定のロールを必要とするメソッドを持っています。EJB に で明示的に注釈を付けるかどうかは問題ではありません@PermitAll。ACC は引き続きユーザー名とパスワードの入力を求めます。指定されていない場合、GlassFish 3.1.2.2 (ビルド 5) の実装はすべてを中止し、"ユーザーが認証をキャンセルしました".

テスト環境を整えましょう!

次のようにリモート インターフェイスを宣言します。

@Remote
public interface IRemoteEJB
{
String echoGuest(String returnMe);
String echoAdmin(String returnMe);
}

EJB を記述します (私の問題はシングルトンに関連しているため、ここではあえて別のセッション アノテーションを使用しません!):

@Singleton
/*
 * See the following annotation. We explicitly "permit all" on class level.
 * Should not cause any ambiguity at all!
 */
@PermitAll
public class myEJB implements IRemoteEJB
{
    @Override
    public String echoGuest(String returnMe) {
        return returnMe; }

    @Override
    // ..but here we grant access only to administrators:
    @RolesAllowed("admin")
    public String echoAdmin(String returnMe) {
        return returnMe; }
}

クライアント部分に関しては、私が考えることができる最小の実装は次のとおりです。

public class Main
{
    @EJB private static remoteProxy;

    public static void main(String... args)
    {
        String reply = remoteProxy.echoGuest("Hello world!");
        JOptionPane.showMessageDialog(null, reply);
    }
}

結果

クライアントがメソッドに対して "匿名" 呼び出しを正常に行ったと思いますechoGuestか? いいえ。私は、ACC@EJBが注入される前であっても、クライアントにユーザー名とパスワードの提供を強制することを発見しました。簡単に言えば、アプリケーション クライアントから EJB へのアクセス認証を混在させることはできません。上記の解決策は、メソッド@RolesAllowed("admin")から注釈を削除することです。echoAdmin

ある意味では、それは完全に理にかなっています。MainACC は、クライアントの起動中にのみアクティブになります。これが、注入されたすべてのリソースをクラス内のアプリケーション クライアントに配置し、それらstaticも作成する必要があるまさにその理由です。ACC は、EJB のどのメソッドが呼び出されるかどうかを正確に知ることはできません。

@PermitAllわかりましたが、それはおよび@RolesAllowedアノテーションの仕様と期待される動作を壊していませんか? アプリケーションクライアントに、特定のロールを必要とする、廃止され、呼び出されたことのないメソッドが 1 つしかない EJB への匿名アクセス権を提供する方法は、地球上にないのでしょうか? 今のところ、これらのメソッドを分離する必要があるのは、私が可能であり、実行すべきであると考えていたアノテーションを使用するだけでなく、EJB を完全に分離するためにロジックをリファクタリングする必要もあります。難しい感じ:'(

4

1 に答える 1

0

Java EE 7 仕様JSR 342の 9 ページには、アプリケーション クライアントのdeployment and management is not completely defined by this specification. したがって、アプリケーションクライアントの「管理」に関しては、移植性のない異なる動作が予想されます。

仕様は続き、Lazy Authentication については 41 ページと 42 ページで説明しています。

認証に関連するコストがあります。たとえば、認証プロセスでは、ネットワーク全体で複数のメッセージを交換する必要がある場合があります。したがって、レイジー認証を使用する、つまり、必要な場合にのみ認証を実行することが望ましいです。レイジー認証では、保護されたリソースへのアクセス要求があるまで、ユーザーは認証する必要がありません。

レイジー認証は、認証が必要な保護されたリソースへのアクセスを要求するときに、第 1 層のクライアント (アプレット、アプリケーション クライアント) で使用できます。

この引用を解析して、仕様で遅延認証が必要かどうかを判断することはできません。どうやら、そうではありません。つまり、GlassFish は、保護されたリソース (この例ではメソッド呼び出し) にアクセスする前であっても、アプリケーション クライアントからの認証を要求する場合、ルールに違反しません。

さらに、仕様は44ページの痛いところに本当に当たりました:

使用される手法は、アプリケーション クライアント コンテナーの実装によって異なる場合があり、アプリケーションの制御を超えています。

したがって、私の最終的な判断は、仕様が遅延認証を必要とせず、「技術」が異なる可能性があるということでなければなりません。

于 2013-06-13T13:47:52.440 に答える