Oracle® Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護 11gリリース1 (10.3.6) B55556-04 |
|
前 |
次 |
Java EEプラットフォームでは、以前からWebアプリケーションとEJBを保護するための標準モデルが提供されています。この標準モデルでは、ロール・マッピングやポリシーをWebアプリケーションまたはEJBのデプロイメント記述子に定義します。
環境によってはこのJava EE標準では柔軟性に欠けることもあるので、WebLogic ServerにはJava EE標準以外の選択肢としてさらに柔軟性の高いモデルも用意されています。
注意: JACC (JSR 115で定義されているJava Authorization Contract for Containers)を使用したセキュリティを実装する場合は、Java EE標準モデルを使用する必要があります。その他のWebLogic Serverモデルは使用できず、そのWebアプリケーションおよびEJB用のセキュリティ機能は管理コンソールでは無効になります。『Oracle WebLogic Serverセキュリティのプログラミング』のJava Authorization Contract for Containersの使用に関する項を参照してください。 |
セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。
以下の節では、WebアプリケーションやEJB (Enterprise Java Bean)リソースを保護するためのオプションについて説明します。
注意: この節で説明されているEJBリソースに対する手順は、メッセージドリブンBean (MDB)にも適用できます。 |
各セキュリティ・モデルは、WebアプリケーションおよびEJBの保護に関する2種類の動作、すなわち、ロールとポリシーがどこで定義されているか、および、どのようなURLパターンとEJBメソッドがセキュリティ・チェックを実行するセキュリティ・サービスをトリガーするかを定義します。表4-1で、それぞれのモデルを比較します。
表4-1 セキュリティ・モデルの動作
モデル | 使用するロールとポリシーの場所 | セキュリティ・チェックの実施方式 |
---|---|---|
デプロイメント記述子のみ(Java EE標準) |
デプロイメント記述子web.xml、weblogic.xml、ejb-jar.xml、weblogic-ejb-jar.xml。 WebアプリケーションまたはEJBを含むアプリケーションに対してロールが定義されている場合、すべてのロールが論理OR演算子で結合されます。 |
クライアントから、デプロイメント記述子内のポリシーで保護されているURLまたはEJBメソッドが要求されたときのみ。 |
カスタム・ロール |
このモデルでは、セキュリティ・レルムに構成されたロール・マッピング・プロバイダによるロール・マッピングが使用されます。管理コンソールを使用してプロバイダを構成できます。デプロイメント記述子のロール・マッピングはすべて無視されます。 このモデルでは、web.xmlデプロイメント記述子とejb-jar.xmlデプロイメント記述子に定義されているポリシーが使用されます。 |
クライアントから、デプロイメント記述子内のポリシーで保護されているURLまたはEJBメソッドが要求されたときのみ。 |
カスタム・ロールおよびポリシー |
セキュリティ・レルムに構成したロール・マッピング・プロバイダおよび認可プロバイダ。管理コンソールを使用してプロバイダを構成できます。 デプロイメント記述子のロール・マッピングやポリシーはすべて無視されます。 |
すべてのURLとEJBメソッドに対して。 |
詳細 |
構成可能。 このモデルでは、デプロイメント記述子からのセキュリティ・データのみを使用する、セキュリティ・プロバイダからのデータのみを使用する、または基準とするセキュリティ・データをデプロイメント記述子からセキュリティ・プロバイダのデータベースにインポートしてさらに変更を加える、といった動作に構成できます。 |
構成可能。 |
以下の節では、各モデルについて説明し、それぞれに適したシナリオを提示します。
これは標準のJava EEモデルで、WebアプリケーションおよびEJBに対して宣言型セキュリティを追加するための広く知られた方法です。このモデルでは、開発者によってJava EEデプロイメント記述子(DD)およびWebLogic Server DDに定義されたロールおよびポリシーのみが使用されます。デプロイメント記述子のセキュリティ・プリンシパル(グループやユーザー)が存在し、セキュリティ・レルムに適切にマップされているかどうかについて、セキュリティ管理者による確認が必要になります。
注意: このモデルは、EARに適用するアプリケーション・スコープのロールに影響を与えます。このモデルでは、セキュリティ・サービスはWebLogic Server DDに定義されたアプリケーション・スコープのロールのみを使用します。 |
開発者がデプロイメント記述子のロールやポリシーを変更すると、その変更はWebアプリケーション、EJB、またはEARを再デプロイした直後に認識されます。
このモデルを使用する場合、EJBおよびURLパターンは、よりスコープの広いロールおよびポリシー(Webアプリケーション全体をスコープとするポリシーなど)によっては保護されません。EJBまたはURLパターンがDD内のロールまたはポリシーで保護されていない場合、これらはまったく保護されず、誰でもアクセスできることになります。たとえば、EARに対してアプリケーション・スコープのポリシーを作成し、EARがEJBを含む場合、EJBはアプリケーション・スコープのポリシーによって保護されません。
このモデルは、WebアプリケーションまたはEJBの初回のデプロイ時や後の再デプロイ時に、開発者とセキュリティ管理者が作業を綿密に調整できる場合に適しています。表4-2に、一般的なシナリオを示します。
このセキュリティ・モデルではJava EE DDに定義されたポリシーが使用され、WebLogic Server DDのプリンシパルのマッピングは無視されます。セキュリティ管理者が管理コンソールを使用してロール・マッピングを完了します。
このモデルを使用すると、開発チームのメンバーがそれぞれの専門分野に集中できます。WebアプリケーションやEJBの開発者は、どのURLパターンやEJBメソッドを保護するかを宣言するだけで済みます。セキュリティ管理者はその後で、所定のレルムに対する既存のロールとプリンシパルの階層に適したロール・マッピングを作成します。
開発者がデプロイメント記述子のポリシーを変更すると、その変更はWebアプリケーションまたはEJBを再デプロイした直後に認識されます。開発者がロール・マッピングを変更すると、その変更は再デプロイしなくても即座に有効になります。
このモデルは、開発者と管理者が作業を綿密に調整できない場合、またはロール・マッピングが頻繁に変更される場合に適しています。表4-3に、一般的なシナリオを示します。
このセキュリティ・モデルを使用すると、統合的で動的なセキュリティ管理を行えます。セキュリティ管理者が管理コンソールで作成したロールとポリシーが使用され、デプロイメント記述子に定義されているロールとポリシーは無視されます。
組織のセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル・ユーザー・インタフェースからすべてのセキュリティ構成を変更できます。ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーを、すべて管理コンソールを使用して定義できます。その結果、更新されたセキュリティ要件に基づく変更のプロセスがより効率的になります。
詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。そうした詳細な制御を行うには、保護するURLパターンやEJBメソッドに関する詳細な情報を、開発者から管理者に提供する必要があります。詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。(「カスタム・ロール・モデル」を参照)
またこのモデルでは、クライアントからどのURLが要求され、どのEJBメソッドが呼び出されようとしているかに関わらず、パーミッションがチェックされるので、わずかなパフォーマンスの低下が見られます。
表4-4に、一般的なシナリオを示します。
このモデルは、主に9.0より前のリリースとの下位互換性のために提供されています。
このモデルでは以下の動作を構成できます(「「ロール・マッピングの組合せを有効化」設定について」を参照)。
セキュリティ・チェックをすべてのURLおよびEJBメソッドに対して実施するか、デプロイメント記述子で保護されているものに限って実施するか。
(このモデルを、デプロイメント記述子で保護されているURLおよびEJBメソッドに対してのみセキュリティ・チェックを実施するように構成する場合、適用されません。)デプロイメント記述子に定義されているロールとポリシーのみを使用するか、レルムのセキュリティ・プロバイダで定義されているロールとポリシーのみを使用するか、またはデプロイメント記述子からレルムの認可プロバイダまたはロール・マッピング・プロバイダのデータベースにセキュリティ・データをインポートするか。
セキュリティ・データのインポート機能は以下のタスクのために用意されています。
管理コンソールを使用した完全なセキュリティ管理への移行手順として。このインポート機能は、WebアプリケーションやEJBの保護のみにWebLogic Server管理コンソールを使用することを計画しているが、デプロイメント記述子のセキュリティ・データを基準として使用する必要がある場合を想定して提供されています。
WebアプリケーションおよびEJBリソースのセキュリティ構成を再初期化して、デプロイメント記述子で指定されていた元の状態に戻すため。
データをインポートした後には、管理コンソールを使用してセキュリティ・データを変更できます。
(このモデルを、レルムのセキュリティ・プロバイダに定義されているロールとポリシーのみを使用するように構成する場合、適用されません。)親アプリケーションのロールとWebアプリケーションまたはEJBのロールを結合するか、親アプリケーションのロールをオーバーライドするか。
このモデルの構成を変更すると、このモデルを使用するすべてのWebアプリケーションおよびEJBにその変更が適用されます。たとえば、詳細モデルを構成してすべてのURLとメソッドに対してセキュリティ・チェックを実施するようにしてから、複数のEJBをデプロイして詳細モデルを使用するように構成するとします。この場合、クライアントでどのEJBのどのメソッドを呼び出そうとした場合にも、毎回EJBコンテナによってセキュリティ・チェックが要求されます。その後、詳細モデルを変更してデプロイメント記述子で保護されているEJBメソッドにのみセキュリティ・チェックを実施するようにすると、EJBコンテナでは即座に、複数のEJBにおいて保護されているメソッドにのみセキュリティ・チェックが要求されるようになります。
注意: この節の内容は、詳細セキュリティ・モデルを使用するWebアプリケーションおよびEJBのみに適用されるものです。 |
詳細モデルは、管理コンソールの「ロールとポリシーのチェック」、「WebアプリケーションまたはEJBのデプロイ時」、および「ロール・マッピングの組合せを有効化」という3つの設定で構成します。これらの設定を理解していないと、セキュリティ・データが不適切なものになったり、失われたりすることがあります。
このモデルの構成を変更すると、このモデルを使用するすべてのWebアプリケーションおよびEJBにその変更が適用されます。
以下の節では、詳細セキュリティ・モデルの設定について説明します。
「ロールとポリシーのチェック」の設定では、セキュリティ・サービスによってすべてのURLとEJBモジュールに対してセキュリティ・チェックが実施されるのか、デプロイメント記述子で保護されたものに対してのみ実施されるのかを決定します。
「ロールとポリシーのチェック」の値は以下のように設定します。
WebアプリケーションおよびEJBリソースのうち、関連するデプロイメント記述子(DD)にセキュリティの指定があるものに対してのみセキュリティ・チェックを実施するには、「デプロイメント記述子で保護されたWebアプリケーションとEJB」を選択します。
注意: この設定を選択した場合の動作は、デプロイメント記述子のみのセキュリティ・モデルと似ています。セキュリティ・サービスでは、WebアプリケーションまたはEJBのデプロイメント記述子に定義されているロールおよびポリシーが使用されます。 |
すべてのWebアプリケーションおよびEJBリソースに対してセキュリティ・チェックを実施するには、対象とするWebLogicリソースのデプロイメント記述子にセキュリティ設定があるかどうかに関わらず、「すべてのWebアプリケーションとEJB」を選択します。
注意: これを選択した場合、「WebアプリケーションまたはEJBのデプロイ時」設定も併せて構成できます。 |
「WebアプリケーションまたはEJBのデプロイ時」の設定では、セキュリティ・サービスでデプロイメント記述子のロールおよびポリシーのデータを無視するか、WebアプリケーションやEJBをデプロイするたびに、ロール・マッピング・プロバイダや認可プロバイダのデータベースにデータをインポートするかを決定します。
注意: この設定は「ロールとポリシーのチェック」で「すべてのWebアプリケーションとEJB」を設定した場合にのみ有効です。 |
「WebアプリケーションまたはEJBのデプロイ時」の値は以下のように設定します。
WebLogic Server管理コンソールのみを使用してWebアプリケーションおよびEJBリソースを保護するには、「デプロイメント・ディスクリプタのロールとポリシーを無視」オプションを選択します。これを選択すると、管理コンソールを使用してリソースを保護できるようになります。Oracle WebLogic Server管理コンソール・ヘルプの「スコープ指定セキュリティ・ロールの作成」および「リソース・インスタンスのポリシーの作成」を参照してください。
デプロイメント記述子からセキュリティ・データをインポートするには、「デプロイメント記述子のロールとポリシーを初期化」を選択します。
表4-5に、「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の設定値をさまざまに組み合せて、WebLogicセキュリティ・サービスで希望する動作を行う方法を示します。
表4-5 「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の相互作用
セキュリティを制御する対象 | WebアプリケーションおよびEJBリソースに対するセキュリティの設定 | 「ロールとポリシーのチェック」の設定値 | 「WebアプリケーションまたはEJBのデプロイ時」の設定値 |
---|---|---|---|
すべてのWebアプリケーションおよびEJBリソース |
管理コンソールのみを使用する |
すべてのWebアプリケーションとEJB |
デプロイメント記述子のロールとポリシーを無視 |
すべてのWebアプリケーションおよびEJBリソース |
WebアプリケーションまたはEJBリソースのデプロイ時に、セキュリティ・データをデプロイメント記述子から構成済みの認可プロバイダおよびロール・マッピング・プロバイダのデータベースにコピーするか再初期化して、その後、セキュリティ・ロールとセキュリティ・ポリシーの変更をその他の方法で行います。 注意: WebアプリケーションまたはEJBリソースがデプロイされるたびに、セキュリティ・データはコピーまたは再初期化されます。 |
すべてのWebアプリケーションとEJB |
デプロイメント記述子のロールとポリシーを初期化 |
デプロイメント記述子で指定されているWebアプリケーションおよびEJBのメソッドのみ(デフォルト構成) |
デプロイメント記述子のみを使用する |
デプロイメント記述子で保護されたWebアプリケーションとEJB |
-- |
「ロール・マッピングの組合せを有効化」の設定では、エンタープライズ・アプリケーション、Webアプリケーション、およびEJBコンテナ内のロール・マッピングがどのように相互作用するかを決定します。
この設定は、8.xバージョンとの下位互換性のために提供されています。バージョン9.xで初めからデプロイされたすべてのアプリケーションにおいて、この設定のデフォルト値は「true」(有効)です。以前バージョン8.1でデプロイして9.xにアップグレードしたアプリケーションにおけるこの設定のデフォルト値は「false」(無効)です。以下のどちらかに当てはまる場合、「ロール・マッピングの組合せを有効化」のデフォルト値を変更することを検討してください。
8.xからアップグレードしたアプリケーションに対して詳細セキュリティ・モデルを選択し、バージョン9.xで利用可能な組み合せたロール・マッピングの動作を使用する必要があります。
9.xのアプリケーションに対して詳細セキュリティ・モデルを選択し、バージョン8.xのロール・マッピングの動作を使用する必要があります。
表4-6で、この設定がWebアプリケーションとEJBに与える影響について比較します。
表4-6 ロール・マッピングの組合せの設定がWebアプリケーションとEJBのセキュリティに与える影響
ロール・マッピングの組合せが無効 | ロール・マッピングの組合せが有効 |
---|---|
各コンテナのロール・マッピングは、 |
アプリケーションのロール・マッピングがEJBおよびWebアプリケーションのマッピングと組み合せられることで、すべてのプリンシパル・マッピングが含まれるようになります。セキュリティ・サービスでは、ロール・マッピングが論理 |
web.xmlファイル内の1つまたは複数のポリシーで、weblogic.xmlファイル内にロール・マッピングが存在しないロールが指定されている場合、Webアプリケーション・コンテナは未定義のロールがプリンシパルの名前であると想定します。そのため、想定されたプリンシパルがロール名にマップされます。たとえば、web.xmlファイルのポリシーの1つに次のスタンザがある場合: <auth-constraint> <role-name>PrivilegedUser</role-name> </auth-constraint> ただし、weblogic.xmlファイルにはPrivilegedUserに対するロール・マッピングがないとすると、Webアプリケーション・コンテナは、次のスタンザと同等のインメモリー・マッピングを作成します: <security-role-assignment><role-name>PrivilegedUser</role-name><principal-name>PrivilegedUser </principal-name></security-role-assignment> |
web.xmlファイル内の1つまたは複数のポリシーで、weblogic.xmlファイル内にマッピングが存在しないロールが指定されている場合、Webアプリケーション・コンテナでは未定義のロールに対して空のマップを作成します(つまり、ロールはプリンシパルを含まないものとして明示的に定義されます)。したがって、そのようなポリシーで保護されるURLパターンにはアクセスできません。 |
EJBメソッドのロール・マッピングは、weblogic-ejb-jar.xmlファイルで定義する必要があります。その他のコンテナで定義されたロール・マッピングは、 |
ejb-jar.xmlファイル内の1つまたは複数のポリシーで、weblogic-ejb-jar.xmlファイル内にマッピングが存在しないロールが指定されている場合、EJBコンテナは未定義のロールに対して空のマップを作成しまする(つまり、ロールはプリンシパルを含まないものとして明示的に定義されます)。したがって、そのようなポリシーで保護されるメソッドにはアクセスできません。 |
以下の例で、ロール・マッピングの組合せが有効な場合と無効な場合におけるロール・マッピングの動作の違いについて示します。
MyAppEarにMyAppWARが含まれ、MyAppWARにMyEJBが含まれます。プリンシパル・マッピングへのロール(p1およびp2)は以下のとおりです。
EARの記述子では、myRole = p1
WARの記述子では、myRole = p2
EJB-JARの記述子では、myRole = empty
組み合せたロール・マッピングが有効になっている場合、ロール・マッピングは以下のようになります。
EARコンテナでは、myRoleがp1にマップされます。
WARコンテナでは、myRoleがp1またはp2にマップされます。
EJBコンテナでは、myRoleがp1にマップされます。
組み合せたロール・マッピングが無効になっている場合、ロール・マッピングは以下のようになります。
EARコンテナでは、myRoleがp1にマップされます。
WARコンテナでは、myRoleがp2にマップされます。
EJBコンテナでは、外部的に定義されている必要があり、定義されていない場合にはデプロイメントが失敗します。
MyAppEarにMyAppWARが含まれます。ロールからプリンシパルへのマッピングは以下のとおりです。
MyAppEARの記述子では、myRole = p1
MyAppWARの記述子では、myRole = (何も定義されません)
組み合せたロール・マッピングが有効になっている場合、ロール・マッピングは以下のようになります。
EARコンテナでは、myRoleがp1にマップされます。
WARコンテナでは、myRoleがp1にマップされます。
組み合せたロールの動作なので、このマッピングは同じになります。
組み合せたロール・マッピングが無効になっている場合、ロール・マッピングは以下のようになります。
EARコンテナでは、myRoleがp1にマップされます。
WARコンテナでは、myRoleがMyRoleにマップされます。
Webアプリケーションにマッピングが定義されていない場合、このマッピングは同じになります。EARマッピングがWARマッピングにコピーされます。
セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。
管理コンソールを使用してのアプリケーションのデプロイ、セキュリティ・モデルの選択、ロールやポリシーの変更、および他の関連タスクの実行については、Oracle WebLogic Server管理コンソール・ヘルプの「WebアプリケーションおよびEJBのセキュリティの管理」を参照してください。
デプロイメント記述子を使用してWebアプリケーションまたはEJBリソースを保護する場合は、『Oracle WebLogic Serverセキュリティのプログラミング』のWebアプリケーションでの宣言によるセキュリティの使用に関する項またはEJBでの宣言によるセキュリティの使用に関する項を参照してください。