の設定をBasic Authentication変更して使用してみましたがうまくいきませんでした: Jersey JAX-RS サービスでの BASIC 認証と Tomcat 6.0 の取得に失敗しましたserver.xmlTomcat 6.0
したがって、サーバー固有の構成が不要で、コードに直接ロールを追加できる方法を選択しています (クライアントまたはサーバーのいずれか; 利用可能なオプションについてはわかりません)。
@RolesAllowed注釈を使用して Web サービス メソッドを認証できるように、ユーザー ロールを設定するための可能なオプションについていくつかのアイデアを提供してください。
戻って、セキュリティ制約が機能しなかった理由を突き止める必要があります。JDBCレルムに移る前に、デフォルトのファイルレルムから始めてください。コンテナー内の動作をトリガーするアノテーションの @RolesAllowed。
本当に自分でやりたい場合 (悪い考えです)、基本的な http チャレンジ メカニズム全体を実装したカスタム サーブレット フィルターを作成することから始めるでしょう。次に、Jersey の SecurityContext プロバイダーを置き換える必要があります。
ジャージで @RolesAllowed を有効にする彼らの「もの」は次のとおりです。 /api/container/filter/RolesAllowedResourceFilterFactory.java ところで、ジャージ サーブレットに init-param として追加することを忘れないでください。RolesAllowedResourceFilterFactory は、注入された SecurityContext からセキュリティ情報を取得します。これは、ある時点で、資格情報のサーブレット API に委譲するだけだと確信しています。
基本的に、セキュリティ制約を機能させるために時間をかけたくない場合は、チェーンの大部分を置き換えることになります...私が言ったように、悪い考えです。
アプリケーション サーバーの機能は、インフラストラクチャ コードの作成に時間を費やさなくて済むようにするためにあります。独自のインフラストラクチャ コードを作成すると、時間がかかります。