| Oracle® Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護 12c (12.1.2) E48030-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護 12c (12.1.2) E48030-02 |
|
前 |
次 |
この章では、Java EE標準モデルを含め、WebアプリケーションとEJBリソースを保護するためのWebLogic Serverのオプションについて説明します。
Java EE標準モデルでは、次のいずれかの方法でWebアプリケーションとEJBを保護できます。
デプロイメント記述子またはメタデータ・アノテーションを使用して宣言的に行う場合。
EJB 3.xの場合、EJBセキュリティ・メタデータ・アノテーションをEJB Beanクラスで直接指定して、EJBのすべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定できます。
「EJBでのプログラム的セキュリティの使用」に従ってプログラム的に行う場合。
WebLogic Serverは、EJBにおけるプログラムによる認可を実装するために、EJBContext.isCallerInRoleメソッドとEJBContext.getCallerPrincipalメソッドの使用、およびデプロイメント記述子でのsecurity-role-ref要素の使用をサポートしています。
環境によってはこのJava EE標準では柔軟性に欠けることもあるので、WebLogic ServerにはJava EE標準以外の選択肢としてさらに柔軟性の高いモデルも用意されています。
|
注意: JACC(JSR 115で定義されているJava Authorization Contract for Containers)を使用したセキュリティを実装する場合は、Java EE標準モデルを使用する必要があります。その他のWebLogic Serverモデルは使用できず、そのWebアプリケーションおよびEJB用のセキュリティ機能は管理コンソールでは無効になります。詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJava Authorization Contract for Containersの使用に関する項を参照してください。 |
この章の内容は以下のとおりです。
|
注意: この節で説明されているEJBリソースに対する手順は、メッセージドリブンBean (MDB)にも適用できます。 |
『Oracle WebLogic Server Enterprise JavaBeansの開発』のEJB 3.0の新機能と変更された機能に関する項で説明されているように、デプロイメント記述子ファイル(ejb-jar.xmlなど)を作成する必要がなくなります。Beanファイル自体の中で、メタデータ・アノテーションを使用してメタデータを構成できます。アノテーションを使用すると、コンテナ内でのBeanの動作、依存関係インジェクションの要求方法などをJavaクラス自体の中で指定でき、EJBの開発プロセスを簡略化できます。アノテーションは、EJBの2.x以前のバージョンで必要だったデプロイメント記述子にかわるものです。
ただし、選択すれば、メタデータ・アノテーションに加えて(またはメタデータ・アノテーションのかわりに)XMLデプロイメント記述子を使用できます。
|
注意: デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。 |
EJBの場合、アプリケーション開発者は、EJBメソッドを呼び出すことができるセキュリティ・ロールを指定するためにセキュリティ関連メタデータ・アノテーションを使用することで、デプロイヤのタスクを推進できます。アノテーションまたはデプロイメント記述子を使用する場合、セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。
デプロイメント記述子ベースの各セキュリティ・モデルは、WebアプリケーションおよびEJBの保護に関する2種類の動作、すなわち、ロールとポリシーがどこで定義されているか、および、どのようなURLパターンとEJBメソッドがセキュリティ・チェックを実行するセキュリティ・サービスをトリガーするかを定義します。
表4-1で、それぞれのモデルを比較します。
表4-1 セキュリティ・モデルの動作
| モデル | 使用するロールとポリシーの場所 | セキュリティ・チェックの実施方式 |
|---|---|---|
|
メタデータ・アノテーション 管理コンソールのデプロイメント記述子のみ(Java EE標準)としてカテゴリ化 |
EJB Beanファイル自体のメタデータ・アノテーションは、EJBのすべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定します。 |
クライアントから、アノテーションで指定されたロールで保護されているEJBメソッドが要求されたときのみ。 メタデータ・アノテーションはデプロイメント記述子(および管理コンソール)ベースのメカニズムと関連して使用できます。競合がある場合、デプロイメント記述子要素は対応するアノテーションを常にオーバーライドします。 |
|
デプロイメント記述子のみ(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メソッドに対して。 |
|
詳細 |
構成可能。 このモデルでは、アノテーションまたはデプロイメント記述子からのセキュリティ・データのみを使用する、セキュリティ・プロバイダからのデータのみを使用する、または基準とするセキュリティ・データをデプロイメント記述子からセキュリティ・プロバイダのデータベースにインポートしてさらに変更を加える、といった動作に構成できます。 |
構成可能。 |
以下の節では、各モデルについて説明し、それぞれに適したシナリオを提示します。
『Oracle WebLogic Server Enterprise JavaBeansの開発』のメタデータ・アノテーションおよびEJB 3.0 Beanファイルの概要に関する項に示すように、EJBプログラミング・モデルでは、メタデータ・アノテーション機能(http://www.oracle.com/technetwork/articles/hunter-meta-096020.htmlを参照)を使用して、アノテーション付きEJB Beanファイルを作成します。次に、WebLogicコンパイル・ツールweblogic.appc(またはこれと同等のAntタスクwlappc)を使用してBeanファイルをJavaクラス・ファイルにコンパイルし、必要となるEJBインタフェースやデプロイメント記述子など、関連するEJBアーティファクトを生成します。
使用できるセキュリティ関連アノテーションは次のとおりです。
javax.annotation.security.DeclareRoles — EJBのセキュリティ設定に使用するセキュリティ・ロールのリストを明示的に宣言します。
javax.annotation.security.RolesAllowed - EJBのメソッドを呼び出すことができるセキュリティ・ロールを指定します。すべてのメソッドを呼び出すことができるロールはクラス・レベルで指定し、特定のメソッドのみを呼び出すことができるロールはメソッド・レベルで指定します。
javax.annotation.security.DenyAll — どのロールでも呼び出すことができないメソッドを指定します。
javax.annotation.security.PermitAll — すべてのロールで呼び出すことができるメソッドを指定します。
javax.annotation.security.RunAs — EJBを実行するロールを指定します。デフォルトでは、EJBはそれを実際に呼び出したユーザーとして実行されます。
デプロイ時にデプロイヤは、これらのセキュリティ・ロールがまだ存在しない場合は作成し、WebLogic Server管理コンソールを使用してユーザーをこれらのロールにマッピングすることで、セキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。
このモデルでは、EJBでプログラムによる認可を実装しなくても、アプリケーション開発者にさらなる管理能力を付与できます。
表4-2 メタデータ・アノテーション:一般的なシナリオ
| 企業A、開発者 | 企業A、管理者/デプロイヤ |
|---|---|
|
企業Aでは、開発者ロールのユーザーは次のタスクを実行します。
|
企業Aでは、管理者またはデプロイヤのロールであるユーザーは次のタスクを実行します。
|
メタデータ・アノテーションはデプロイメント記述子(および管理コンソール)ベースのメカニズムと関連して使用できます。実行する場合は次の点に注意してください。
競合がある場合、デプロイメント記述子要素は対応するアノテーションを常にオーバーライドします。たとえば、アノテーションでメソッドに「すべてを拒否」を指定して、デプロイメント記述子で「開発者」ロールがそのメソッドへのアクセス権を保有すると指定した場合、「開発者」ロールにはそのメソッドへのアクセス権があります。
管理コンソールでカスタム・ロールを指定した場合、デプロイメント記述子またはアノテーションでのロール・マッピングはすべて無視されます。
セキュリティ関連アノテーションのすべてを使用する簡潔なステートレス・セッションEJBの例については、「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-3に、一般的なシナリオを示します。
このセキュリティ・モデルではJava EE DDに定義されたポリシーが使用され、WebLogic Server DDのプリンシパルのマッピングは無視されます。セキュリティ管理者が管理コンソールを使用してロール・マッピングを完了します。
このモデルを使用すると、開発チームのメンバーがそれぞれの専門分野に集中できます。WebアプリケーションやEJBの開発者は、どのURLパターンやEJBメソッドを保護するかを宣言するだけで済みます。セキュリティ管理者はその後で、所定のレルムに対する既存のロールとプリンシパルの階層に適したロール・マッピングを作成します。
開発者がデプロイメント記述子のポリシーを変更すると、その変更はWebアプリケーションまたはEJBを再デプロイした直後に認識されます。開発者がロール・マッピングを変更すると、その変更は再デプロイしなくても即座に有効になります。
このモデルは、開発者と管理者が作業を綿密に調整できない場合、またはロール・マッピングが頻繁に変更される場合に適しています。表4-4に、一般的なシナリオを示します。
このセキュリティ・モデルを使用すると、統合的で動的なセキュリティ管理を行えます。セキュリティ管理者が管理コンソールで作成したロールとポリシーが使用され、デプロイメント記述子に定義されているロールとポリシーは無視されます。
組織のセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル・ユーザー・インタフェースからすべてのセキュリティ構成を変更できます。ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーを、すべて管理コンソールを使用して定義できます。その結果、更新されたセキュリティ要件に基づく変更のプロセスがより効率的になります。
詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。そうした詳細な制御を行うには、保護するURLパターンやEJBメソッドに関する詳細な情報を、開発者から管理者に提供する必要があります。詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。(「カスタム・ロール・モデル」を参照)
またこのモデルでは、クライアントからどのURLが要求され、どのEJBメソッドが呼び出されようとしているかに関わらず、パーミッションがチェックされるので、わずかなパフォーマンスの低下が見られます。
表4-5に、一般的なシナリオを示します。
このモデルは、主に9.0より前のリリースとの後方互換性のために提供されています。
このモデルでは以下の動作を構成できます(「「ロール・マッピングの組合せを有効化」設定の理解」を参照)。
セキュリティ・チェックをすべてのURLおよびEJBメソッドに対して実施するか、デプロイメント記述子で保護されているものに限って実施するか。
(このモデルを、デプロイメント記述子で保護されているURLおよびEJBメソッドに対してのみセキュリティ・チェックを実施するように構成する場合、適用されません。)デプロイメント記述子に定義されているロールとポリシーのみを使用するか、レルムのセキュリティ・プロバイダで定義されているロールとポリシーのみを使用するか、またはデプロイメント記述子からレルムの認可プロバイダまたはロール・マッピング・プロバイダのデータベースにセキュリティ・データをインポートするか。
セキュリティ・データのインポート機能は以下のタスクのために用意されています。
管理コンソールを使用した完全なセキュリティ管理への移行手順として。このインポート機能は、WebアプリケーションやEJBの保護のみにWebLogic Server管理コンソールを使用することを計画しているが、デプロイメント記述子のセキュリティ・データを基準として使用する必要がある場合を想定して提供されています。
WebアプリケーションおよびEJBリソースのセキュリティ構成を再初期化して、デプロイメント記述子で指定されていた元の状態に戻すため。
データをインポートした後には、管理コンソールを使用してセキュリティ・データを変更できます。
|
警告: セキュリティ・データをインポートすると、セキュリティ・データの整合性にリスクが生じます。データをインポートする際には毎回セキュリティ・サービスによって、プロバイダのデータベースからのあらゆる関連データの削除と、デプロイメント記述子からのデータの再インポートが試行されます。インポートされたセキュリティ・データに変更を加えていた場合、その変更が無効になったり、削除されたりすることがあります。セキュリティ・データをインポートする場合には、Oracle 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管理コンソール・オンライン・ヘルプのスコープ指定セキュリティ・ロールの作成に関する項およびリソース・インスタンスのポリシーの作成に関する項を参照してください。
デプロイメント記述子およびアノテーションからセキュリティ・データをインポートするには、「デプロイメント記述子のロールとポリシーを初期化」を選択します。
|
警告: セキュリティ・データをインポートすると、セキュリティ・データの整合性にリスクが生じます。データをインポートする際には毎回セキュリティ・サービスによって、プロバイダのデータベースからのあらゆる関連セキュリティ・データの削除と、デプロイメント記述子およびアノテーションからのデータの再インポートが試行されます。インポートされたセキュリティ・データに変更を加えていた場合、その変更が無効になったり、削除されたりすることがあります。セキュリティ・データをインポートする場合には、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebアプリケーションおよびEJBのセキュリティの管理に関する項にある推奨事項に従ってください。 |
表4-6に、「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の設定値をさまざまに組み合せて、WebLogicセキュリティ・サービスで希望する動作を行う方法を示します。
表4-6 「ロールとポリシーのチェック」と「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-7で、この設定がWebアプリケーションとEJBに与える影響について比較します。
表4-7 ロール・マッピングの組合せの設定が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マッピングにコピーされます。
メタデータ・アノテーションの場合、EJBをコード化する際にセキュリティ関連アノテーションを追加して、すべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定します。デプロイ時にデプロイヤは、これらのセキュリティ・ロールがまだ存在しない場合は作成し、WebLogic Server管理コンソールを使用してユーザーをこれらのロールにマッピングすることで、セキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。
デプロイメント記述子(および管理コンソール)ベースのセキュリティの場合、セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。
管理コンソールを使用してのアプリケーションのデプロイ、セキュリティ・モデルの選択、ロールやポリシーの変更、および他の関連タスクの実行については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebアプリケーションおよびEJBのセキュリティの管理に関する項を参照してください。
デプロイメント記述子を使用してWebアプリケーションまたはEJBを保護する場合は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のWebアプリケーションでの宣言によるセキュリティの使用に関する項およびEJBでの宣言によるセキュリティの使用に関する項を参照してください。
