2

JaaS 認証を REST に追加するためのシンプルで柔軟な方法を見つけようとしています。正しい方向に導くと思われる投稿を見つけました（StevenCの回答を参照）。Jerseyコード自体ではなく、サーブレットコンテナがセキュリティを担当しているようです。このアイデアは気に入っていますが、実装について少しガイダンスが必要です。

Grizzly は私のサーブレット コンテナーであり、認証に JaaS を使用するように構成したいと考えています。今のところ、単純なユーザー名とパスワードの組み合わせで問題ありません。ユーザー名とパスワードのペアをコードに直接ハードコーディングしても問題ありません。JaaS を使用している限り、後で詳細を調整できます。

HTTP 経由で送信されるものに関しては、Cookie を保存することが、これをすべて機能させる最も簡単な方法であると考えています。認証ジャンクをジャージーコードから遠ざけるために必要なものは何でも。

ここまでで Grizzly を起動するコードは次のとおりです。


final String baseUri = "http://localhost:9998/";
final Map initParams = new HashMap();

initParams.put("com.sun.jersey.config.property.packages", 
  "my.jersey.Service");

System.out.println("Starting grizzly...");
SelectorThread threadSelector = GrizzlyWebContainerFactory.create(baseUri, initParams);
System.out.println(String.format(
        "Jersey app started with WADL available at %sapplication.wadl\n"
  + "Try out %shelloworld\nHit enter to stop it...", baseUri, baseUri));                
System.in.read();
threadSelector.stopEndpoint();
System.exit(0);

このプロセス全体が機能する場合、ユーザーのアクセス許可を確認する最善の方法は何ですか? おそらく、REST コードで特定の時点でアクセス許可を実際に検証したいと思うでしょう。私は正しい軌道に乗っていますか？もっと簡単な方法はありますか？チュートリアルへのリンクは素晴らしい答えです。「私はそれを行い、うまくいきました」のような答えでさえ、私が正しい方向に向かっているという温かいあいまいさを私に与えるでしょう.

助けてくれてありがとう。

編集:StevenCのコメントに対するいくつかの説明:

  • リソースを保護するために、引き続きサーブレット フィルタを使用しますか? 認証の詳細をジャージー コードから分離できるものは何でも使用します。サーブレット フィルターである必要はありません。
  • 「JaaS を使用するように構成する」とはどういう意味ですか? 当初の計画は、JaaS を使用して現在の API を保護することでした。次のフェーズは、API 全体をオンラインで利用できるようにすることです。API 呼び出しの周りに Jersey ラッパーを配置することは理にかなっているように見えましたが、Grizzly によって処理された認証を維持します。その時点で、Grizzly は JaaS とやり取りする必要があると思います。
  • grizzly にリソースを保護させるだけの構成が必要だと思いますか? 私は、ユーザーを認証し、ロールに基づいて、ユーザーがリソースにアクセスすることを承認する 2 段階のプロセスを検討していました。アイデアは、Grizzly が (JaaS を使用して) 認証を処理し、Jersey が承認を処理するようにすることでした。
  • 「RESTful リソースで Cookie を使用する必要はないと思います。」Cookie の使用を削除することは素晴らしいことですが、どうすれば実現できるのでしょうか? システムは、ユーザーが認証されているかどうかを知る必要があります。呼び出しごとにユーザー名/パスワードなどを渡すように依頼したくありません。すべての呼び出しでパラメーターとしてセッション トークンを渡すことでさえ、「醜い」ように見えます。

また、私は REST にかなり慣れていないことに注意してください。私はSOAPを数年間やっているので、「SOAPバイアス」があり、誰もが使用する明白で単純なソリューションから目がくらんでいる可能性があります. もっと簡単な方法がある場合は、お気軽に共有してください。私はできるだけ多くのことを学ぼうとしています。

4

2 に答える 2

3

「認証に JaaS を使用するように構成する」という意味が完全にはわかりません。URL を保護する HTTP 認証を grizzly に強制させる単純な構成がある場合、私はそれについて知りません。

私は、他の質問と回答から、サーブレットフィルターを使用したいと考えています。通常、これはサーブレット プロジェクトの web.xml ファイルで構成されます。もちろん、Grizzly は、アプリケーション構成ではなく、コードからサーバーを起動するためによく使用されます。このように grizzly を使用したとき、GrizzlyWebContainerFactory がサーブレット フィルターを指定できる create() のバージョンを提供していないことに気付きました。ただし、同じプロジェクトで、その機能を提供する ServletAdapter [1] に気付きました。

フィルター自体については、残念ながら、JaaS で構成されたログイン モジュールをアプリケーションにプラグインするだけのビルド済みサーブレット フィルターについては知りません。そのため、そこに少しコードを記述する必要があるでしょう。ただし、HTTP ベースの認証方法 (HTTP BASIC、DIGEST など) を選択し、それに応じて要求から資格情報を抽出し、JaaS フレームワークを使用してログインするだけです。RESTful リソースに Cookie が特に必要になるとは思いません。RESTful なアーキテクチャ スタイルは、セッションを保持することに難色を示します。JaaS に関するチュートリアルは他にもたくさんあるので、ここでは詳しく説明しません。

JaaS サブジェクトがアクティブになると (コンシューマーが正常にログインすると)、Subject.getSubject メソッドを使用して現在のサブジェクトを取得し、アクティブなプリンシパルと資格情報を確認することができます。

とにかく、この回答は、他の（リンクされた）質問で要求したように、サーブレットフィルターを使用した認証の実行に関する詳細をもう少し詳しく説明することです。これは必ずしもジャージー Web アプリケーションで認証を行う唯一の方法ではありませんが、かなり簡単な方法です。必要な各リソースに繰り返し認証コードを挿入する必要がなくなるので、気に入っています。

[1] https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/http/servlet/ServletAdapter.html

于 2009-11-09T01:07:47.547 に答える
1

各リソースを保護する方法を尋ねているかどうかはわかりませんが、探しているもののように聞こえるjavapassionに関するプレゼンテーションを見つけました。彼は、@ContextSecurityContextをパラメーターとして使用すると言います。

  @Path("basket")
  // Sub-resource locator could return a different resource if a user
  // is a preferred customer:
  public ShoppingBasketResource get(@Context SecurityContext sc) {
    if (sc.isUserInRole("PreferredCustomer") {
      return new PreferredCustomerShoppingBaskestResource();
    } else {
      return new ShoppingBasketResource();
  }
}
于 2009-11-05T23:15:25.503 に答える