2011-08-18 8 views
1

Glassfish 3.1.1上に存在するJEE6アプリケーションがあります。このアプリケーションは、多数のRESTリソースを介してリモートクライアントにサービスを提供します。リソースの中には認証が必要なものもあれば、そうでないものもあります。JEE6:カスタムレルム対ResourceFilter - どちらがRESTリソース認証に適していますか?

現在、私は、カスタムレルム/ LoginModuleとして実装されたHTTP基本認証で安全なリソースを保護しています。認証に失敗すると、ログインモジュールはLoginExceptionを投げ、GlassfishはHTTP 401にマップします。認証が成功すると、リソースはsecurityContextuserPrincipalにアクセスできます。

これは動作しますが、LoginExceptionを傍受することはできません。私のクライアントはxmlまたはjsonを期待しています。 HTTP 401本体では、Glassfishはtext/htmlを与えます。その他のアプリケーションの例外はすべてExceptionMapperで傍受できますが、LoginExceptionは例外ではありません。

現時点では、Custom RealmをResourceFilterに置き換えることを考えています。ここでは、HTTP基本認証を手動で行います。私はここに例外を投げれば、それは傍受され、適切にマッピング/マーシャルされるだろうと期待しています。

私の質問は以下のとおりです。認証のためにResourceFilterを使用することをお勧め

  • ですか?パフォーマンスはどうですか?
  • RESTリソースに、認証されたばかりの人(userPrinidentsは誰ですか)を知らせるにはどうすればよいですか?
+0

Btw、私はそれをResourceFilterとInjectable UserProviderとして実装しました。誰かが興味があれば、私はコードを投稿して嬉しいです。私の質問に答えることはできませんが、それは良いアイデアです:) – Hank

答えて

0

少し遅れて、とにかく...

そのそれはあなたのリソースに到達することはありませんので、認証を行うコンテナ。個人的には、認証とアプリケーションをうまく分離するため、コンテナ管理による認証アプローチが好きです。

ResourceFilterを使用する場合は、要求からSecurityContextにアクセスできます。これにはプリンシパルが含まれています。そこから、たとえばアプリケーション全体からアクセス可能なApplicationConfigオブジェクト。

パフォーマンスは認証の実装によって異なります。私はResourceFilterを使用する際のオーバーヘッドが最小であると推測します。必要に応じて、セッションCookieを使用してセッションを維持し、認証をやり直すこともできます。

+0

それはもはや問題ではないので、私は質問を閉じておくべきだった。私はあなたが 'ResourceFilter'と' SecurityContext'で言ったようにしています。 'ResourceFilter'では例外btwを完全に制御できます。 – Hank

+0

とにかく返信してくれてありがとう:) – thehpi