私は現在、JSF（フロントエンド）とJPA、EJB、およびCDI（バックエンド）を使用して「基本的な」JavaEE6アプリケーションを開発しています。これまでのところ、すべてがうまく機能しています。
ログイン部分には、JDBC-Realmとともにフォームベースの認証を選択しました。
今、私はモバイルデバイスによって消費されるいくつかのRESTサービス（Jersey）を提供するのが好きです。したがって、認証するための2番目の方法を追加する必要があります。しかし、私の理解では、一度に1つしか存在できません。
すでにいくつかのPoCを試しましたが、有効なユーザーを必要とするRESTサービスを呼び出すたびに、サービスはログインページにリダイレクトされました。
この種の問題を処理するためのベストプラクティスはありますか？
リクエストごとにユーザー/パスまたはセッションIDを送信したくないので、現在のログインメカニズムにOauthを追加することは可能ですか？ある種のトークンは素晴らしいでしょう。
アプリケーションがサービスごとに異なる認証メカニズムを必要とする場合、ほとんどのJava EE実装（サーバー）に付属しているログインモジュールは実際には十分ではありません。
カスタムログイン/認証モジュールを作成して、自分の手で問題を解決する必要があります。Java EE 6には、そのためのAPI、JASPICがあります。または、特定のサーバーの独自のログインモジュールAPIを使用することもできます。
そのログイン/認証モジュールでは、リクエストを検査し、そのリクエストがどのサービスに属しているかを判断してから、適切な「実際の」モジュールに委任することができます。
私はあなたが始めるかもしれないJASPICについての記事を少し前に書きました。
多くの場合、サーバーにはログインモジュールをスタックするオプションがあります。これは独自の機能であるため、そのうちの1つが認証メカニズムのスタックを許可する可能性はほとんどありません。
しかし、私の理解では、一度に1つしか存在できません。
それは完全に正しいわけではありません。コンテナ管理の構成は1つだけですが、プログラムによるログインまたはサードパーティのフレームワークを使用する場合は、必要な数だけ構成できます。
私はすでにいくつかのPoCを試しましたが、RESTサービスを呼び出すたびに、有効なユーザーが必要であり、サービスはログインページにリダイレクトされました
セキュリティ制約を定義したweb.xml場所では、コンテナ管理の認証メカニズムをバイパスしてプログラムで認証するか、サードパーティのソリューションを使用するために、アプリケーションのREST部分を除外します。
この種の問題を処理するためのベストプラクティスはありますか。
これは議論につながる可能性が高いので、私はそれに答えようとはしません。
リクエストごとにユーザー/パスまたはセッションIDを送信したくないので、現在のログインメカニズムにOauthを追加することは可能ですか？
はい。おそらく他にもたくさんありますが、私はSeam Social（Agoravaになりつつあります）に精通しています。これらの2つは、Google、Facebook、およびその他のいくつかをサポートすると主張しています。ApacheShiro用に独自のOAuthオーセンティケーターを作成することもできます。
別の方法は、アプリケーションをEARとしてパッケージ化し、WebUIとRESTインターフェイスを個別のWebモジュールに分割することです。これにより、web.xmlを介して各Webモジュールを個別に構成できます。
のような名前のカスタムサーブレットを追加し、 （Jersey @POSTメソッドbtwの場合もあります）をAuthServlet使用して公開できるように設定し、プログラムによる認証を使用できます。security-constraint