WebアプリケーションおよびEJBリソースの保護のオプション

4 WebアプリケーションおよびEJBリソースの保護のオプション

WebLogic Serverでは、Java EE標準モデルを含め、WebアプリケーションとEJBリソースを保護するためのいくつかのオプションが提供されます。

Java EE標準モデルでは、次のいずれかの方法でWebアプリケーションとEJBを保護できます。

デプロイメント記述子またはメタデータ・アノテーションを使用して宣言的に行う場合。

EJB 3.xの場合、EJBセキュリティ・メタデータ・アノテーションをEJB Beanクラスで直接指定して、EJBのすべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定できます。
プログラムによって行う場合。『WebLogicセキュリティ・サービスによるアプリケーションの開発』の次のトピックを参照してください。
- Webアプリケーションでのプログラムによるセキュリティの使用
  
  WebLogic Serverは、Webアプリケーションにプログラムによるセキュリティを実装するため、Java EEセキュリティAPI (JSR 375)のSecurityContextインタフェースのgetCallerPrincipal、getPrincipalsByType、isCallerInRole、hasAccessToWebResourceおよびauthenticateメソッド、HttpServletRequestインタフェースのgetUserPrincipalおよびisUserInRoleメソッドの使用をサポートしています。
- EJBでのプログラムによるセキュリティの使用
  
  WebLogic Serverは、EJBにプログラムによるセキュリティを実装するため、Java EEセキュリティAPI (JSR 375)のSecurityContextインタフェースのgetCallerPrincipal、getPrincipalsByTypeおよびisCallerInRoleメソッド、EJBContextインタフェースのisCallerInRoleおよびgetCallerPrincipalメソッドの使用をサポートしています。WebLogic Serverは、デプロイメント記述子でのsecurity-role-ref要素の使用もサポートしています。

環境によってはこのJava EE標準では柔軟性に欠けることもあるので、WebLogic ServerにはJava EE標準以外の選択肢としてさらに柔軟性の高いモデルも用意されています。

ノート:

JACC(JSR 115で定義されているJava Authorization Contract for Containers)を使用したセキュリティを実装する場合は、Java EE標準モデルを使用する必要があります。その他のWebLogic Serverモデルは使用できません。WebLogicリモート・コンソールで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デプロイメント記述子を使用できます。

ノート:

デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。

Webアプリケーション、EJB用のセキュリティ・モデルの比較

EJBの場合、アプリケーション開発者は、EJBメソッドを呼び出すことができるセキュリティ・ロールを指定するためにセキュリティ関連メタデータ・アノテーションを使用することで、デプロイヤのタスクを推進できます。アノテーションまたはデプロイメント記述子を使用する場合、セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。

デプロイメント記述子ベースの各セキュリティ・モデルは、WebアプリケーションおよびEJBの保護に関する2種類の動作、すなわち、ロールとポリシーがどこで定義されているか、および、どのようなURLパターンとEJBメソッドがセキュリティ・チェックを実行するセキュリティ・サービスをトリガーするかを定義します。

表4-1はセキュリティ・モデルの動作を比較しています。

表4-1 セキュリティ・モデルの動作

モデル. . .	使用するロールとポリシーの場所. . .	セキュリティ・チェックの実施方式. . .
メタデータ・アノテーション WebLogicリモート・コンソールでデプロイメント記述子のみ(Java EE標準)としてカテゴリ化	EJB Beanファイル自体のメタデータ・アノテーションは、EJBのすべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定します。	クライアントから、アノテーションで指定されたロールで保護されているEJBメソッドが要求されたときのみ。メタデータ・アノテーションはデプロイメント記述子(およびWebLogicリモート・コンソール)ベースのメカニズムと関連して使用できます。競合がある場合、デプロイメント記述子要素は対応するアノテーションを常にオーバーライドします。
デプロイメント記述子のみ(Java EE標準)	デプロイメント記述子`web.xml`、`weblogic.xml`、`ejb-jar.xml`、`weblogic-ejb-jar.xml`。 WebアプリケーションまたはEJBを含むアプリケーションに対してロールが定義されている場合、すべてのロールが論理OR演算子で結合されます。	クライアントから、デプロイメント記述子内のポリシーで保護されているURLまたはEJBメソッドが要求されたときのみ。デプロイメント記述子要素は、対応するアノテーションを(ある場合は)常にオーバーライドします。
カスタム・ロール	このモデルでは、セキュリティ・レルムに構成されたロール・マッピング・プロバイダによるロール・マッピングが使用されます。WebLogicリモート・コンソールを使用してプロバイダを構成できます。デプロイメント記述子またはアノテーションのロール・マッピングはすべて無視されます。このモデルでは、`web.xml`デプロイメント記述子と`ejb-jar.xml`デプロイメント記述子に定義されているポリシーが使用されます。	クライアントから、デプロイメント記述子内のポリシーで保護されているURLまたはEJBメソッドが要求されたときのみ。
カスタム・ロールおよびポリシー	セキュリティ・レルムに構成したロール・マッピング・プロバイダおよび認可プロバイダ。WebLogicリモート・コンソールを使用してプロバイダを構成できます。デプロイメント記述子またはアノテーションのロール・マッピングやポリシーはすべて無視されます。	すべてのURLとEJBメソッドに対して。
詳細	構成可能。このモデルでは、アノテーションまたはデプロイメント記述子からのセキュリティ・データのみを使用する、セキュリティ・プロバイダからのデータのみを使用する、または基準とするセキュリティ・データをデプロイメント記述子からセキュリティ・プロバイダのデータベースにインポートしてさらに変更を加える、といった動作に構成できます。	構成可能。

各モデルについて

以下の節では、各モデルについて説明し、それぞれに適したシナリオを提示します。

メタデータ・アノテーション

『Oracle WebLogic Server Enterprise JavaBeansの開発』のメタデータ・アノテーションとEJB Beanファイルの概要に関する項で説明されているように、EJBプログラミング・モデルはメタデータ・アノテーション機能を使用します。この機能では、注釈付けされたEJB Beanファイルを作成し、標準Javaコンパイラを使用してクラスをコンパイルし、生成されたクラスをデプロイメントのためにターゲット・モジュールにパッケージできます。実行時に、WebLogic Serverはアノテーションを解析して、必要な動作のアスペクトをBeanファイルに適用します。

使用できるセキュリティ関連アノテーションは次のとおりです。

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リモート・コンソールを使用してユーザーをこれらのロールにマッピングすることで、セキュリティ・レルムを更新します。詳細は、Oracle WebLogicリモート・コンソール・オンライン・ヘルプのセキュリティ・ポリシーおよびロールを参照してください。

このモデルでは、EJBでプログラムによる認可を実装しなくても、アプリケーション開発者にさらなる管理能力を付与できます。

表4-2 メタデータ・アノテーション:一般的なシナリオ

企業A、開発者	企業A、管理者/デプロイヤ
企業Aでは、開発者ロールのユーザーは次のタスクを実行します。セキュリティ関連メタデータ・アノテーションを1つ以上追加します。 WebLogicコンパイル・ツールweblogic.appc (またはこれと同等のAntタスクwlappc)を使用してBeanファイルをコンパイルします。アプリケーションを管理者/デプロイヤに引き継ぎます。必要なロールに関する手順を提供します。	企業Aでは、管理者またはデプロイヤのロールであるユーザーは次のタスクを実行します。 WebLogicリモート・コンソールを使用して、必ずロールが存在して適切にグループおよびユーザーにマップされているようにします。アノテーションのみが想定されるようにするため、アプリケーションをWebLogicリモート・コンソールでデプロイメント記述子のみ(Java EE標準)としてデプロイします。

企業A、開発者

企業A、管理者/デプロイヤ

企業Aでは、開発者ロールのユーザーは次のタスクを実行します。

セキュリティ関連メタデータ・アノテーションを1つ以上追加します。
WebLogicコンパイル・ツールweblogic.appc (またはこれと同等のAntタスクwlappc)を使用してBeanファイルをコンパイルします。
アプリケーションを管理者/デプロイヤに引き継ぎます。必要なロールに関する手順を提供します。

企業Aでは、管理者またはデプロイヤのロールであるユーザーは次のタスクを実行します。

WebLogicリモート・コンソールを使用して、必ずロールが存在して適切にグループおよびユーザーにマップされているようにします。
アノテーションのみが想定されるようにするため、アプリケーションをWebLogicリモート・コンソールでデプロイメント記述子のみ(Java EE標準)としてデプロイします。

メタデータ・アノテーションはデプロイメント記述子(およびWebLogicリモート・コンソール)のメカニズムと関連して使用できます。実行する場合は次の点に注意してください。

競合がある場合、デプロイメント記述子要素は対応するアノテーションを常にオーバーライドします。たとえば、アノテーションでメソッドに「すべてを拒否」を指定して、デプロイメント記述子で、「開発者」ロールがそのメソッドへのアクセス権を保有すると指定した場合、「開発者」ロールにはそのメソッドへのアクセス権があります。
WebLogicリモート・コンソールでカスタム・ロールを指定した場合、デプロイメント記述子またはアノテーションでのロール・マッピングはすべて無視されます。

すべてのセキュリティ関連アノテーションを使用する単純なステートレス・セッションEJBの例は、『Oracle WebLogic Server Enterprise JavaBeansの開発』の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に、一般的なシナリオを示します。

表4-3 デプロイメント記述子のみ :一般的なシナリオ

企業A、開発者	企業A、管理者/デプロイヤ
企業Aでは、開発者ロールのユーザーは次のタスクを実行します。 Java EE DDのロールにEJBまたはWeb URLをマップします。 WebLogic Server DDのプリンシパルにロールをマップします。アプリケーションを管理者/デプロイヤに引き継ぎます。	企業Aでは、管理者またはデプロイヤのロールであるユーザーは次のタスクを実行します。 WebLogicリモート・コンソールを使用して、必ずグループが存在して適切にユーザーにマップされているようにします。

企業A、開発者

企業A、管理者/デプロイヤ

企業Aでは、開発者ロールのユーザーは次のタスクを実行します。

Java EE DDのロールにEJBまたはWeb URLをマップします。
WebLogic Server DDのプリンシパルにロールをマップします。
アプリケーションを管理者/デプロイヤに引き継ぎます。

企業Aでは、管理者またはデプロイヤのロールであるユーザーは次のタスクを実行します。

WebLogicリモート・コンソールを使用して、必ずグループが存在して適切にユーザーにマップされているようにします。

カスタム・ロール・モデル

このセキュリティ・モデルではJava EE DDに定義されたポリシーが使用され、WebLogic Server DDのプリンシパルのマッピングは無視されます。セキュリティ管理者がWebLogicリモート・コンソールを使用してロール・マッピングを完了します。

このモデルを使用すると、開発チームのメンバーがそれぞれの専門分野に集中できます。WebアプリケーションやEJBの開発者は、どのURLパターンやEJBメソッドを保護するかを宣言するだけで済みます。セキュリティ管理者はその後で、所定のレルムに対する既存のロールとプリンシパルの階層に適したロール・マッピングを作成します。

開発者がデプロイメント記述子のポリシーを変更すると、その変更はWebアプリケーションまたはEJBを再デプロイした直後に認識されます。開発者がロール・マッピングを変更すると、その変更は再デプロイしなくても即座に有効になります。

このモデルは、開発者と管理者が作業を綿密に調整できない場合、またはロール・マッピングが頻繁に変更される場合に適しています。表4-4に、一般的なシナリオを示します。

表4-4 カスタム・ロールのみ:一般的なシナリオ

企業A、企業B、開発者	企業B、管理者/デプロイヤ
企業AからのISV開発者または企業Bからの開発者は次のタスクを実行します。 EJB/URLをJava EEデプロイメント記述子のロールにマップします。アプリケーションを管理者/デプロイヤに引き継ぎます。	企業Bからの管理者またはデプロイヤは次のタスクを実行します。 WebLogicリモート・コンソールを使用してセキュリティ・ロールを定義します。

企業A、企業B、開発者

企業B、管理者/デプロイヤ

企業AからのISV開発者または企業Bからの開発者は次のタスクを実行します。

EJB/URLをJava EEデプロイメント記述子のロールにマップします。
アプリケーションを管理者/デプロイヤに引き継ぎます。

企業Bからの管理者またはデプロイヤは次のタスクを実行します。

WebLogicリモート・コンソールを使用してセキュリティ・ロールを定義します。

カスタム・ロールおよびポリシー・モデル

このセキュリティ・モデルを使用すると、統合的で動的なセキュリティ管理を行えます。セキュリティ管理者がWebLogicリモート・コンソールで作成したロールとポリシーが使用され、デプロイメント記述子に定義されているロールとポリシーは無視されます。

組織のセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル・ユーザー・インタフェースからすべてのセキュリティ構成を変更できます。ユーザー、グループ、セキュリティ・ロールおよびセキュリティ・ポリシーを、すべてWebLogicリモート・コンソールを使用して定義できます。その結果、更新されたセキュリティ要件に基づく変更のプロセスがより効率的になります。

詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。そうした詳細な制御を行うには、保護するURLパターンやEJBメソッドに関する詳細な情報を、開発者から管理者に提供する必要があります。詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。(「カスタム・ロール・モデル」を参照)

またこのモデルでは、クライアントからどのURLが要求され、どのEJBメソッドが呼び出されようとしているかに関わらず、パーミッションがチェックされるので、わずかなパフォーマンスの低下が見られます。

表4-5に、一般的なシナリオを示します。

表4-5 カスタム・ロールおよびポリシー:一般的なシナリオ

企業A、開発者	企業A、管理者/デプロイヤ
Java EE DD、WebLogic Server DDへのマッピングは行いません。アプリケーションを管理者/デプロイヤに引き継ぎます。	WebLogicリモート・コンソールを使用して、EJBおよびWebアプリケーションのロールおよびポリシーを定義します。

詳細モデル

このモデルは、主に9.0より前のリリースとの後方互換性のために提供されています。

このモデルでは以下の動作を構成できます(「「ロール・マッピングの組合せを有効化」設定の理解」を参照)。

セキュリティ・チェックをすべてのURLおよびEJBメソッドに対して実施するか、デプロイメント記述子で保護されているものに限って実施するか。
(このモデルを、デプロイメント記述子で保護されているURLおよびEJBメソッドに対してのみセキュリティ・チェックを実施するように構成する場合、適用されません。)デプロイメント記述子に定義されているロールとポリシーのみを使用するか、レルムのセキュリティ・プロバイダで定義されているロールとポリシーのみを使用するか、またはデプロイメント記述子からレルムの認可プロバイダまたはロール・マッピング・プロバイダのデータベースにセキュリティ・データをインポートするか。

(このモデルを、レルムのセキュリティ・プロバイダに定義されているロールとポリシーのみを使用するように構成する場合、適用されません。)親アプリケーションのロールとWebアプリケーションまたはEJBのロールを結合するか、親アプリケーションのロールをオーバーライドするか。

このモデルの構成を変更すると、このモデルを使用するすべてのWebアプリケーションおよびEJBにその変更が適用されます。たとえば、詳細モデルを構成してすべてのURLとメソッドに対してセキュリティ・チェックを実施するようにしてから、複数のEJBをデプロイして詳細モデルを使用するように構成するとします。この場合、クライアントでどのEJBのどのメソッドを呼び出そうとした場合にも、毎回EJBコンテナによってセキュリティ・チェックが要求されます。その後、詳細モデルを変更してデプロイメント記述子で保護されているEJBメソッドにのみセキュリティ・チェックを実施するようにすると、EJBコンテナでは即座に、複数のEJBにおいて保護されているメソッドにのみセキュリティ・チェックが要求されるようになります。

詳細セキュリティ・モデルの理解

ノート:

この節の内容は、詳細セキュリティ・モデルを使用するWebアプリケーションおよびEJBのみに適用されるものです。

詳細セキュリティ・モデルではなく、代替セキュリティ・モデルを使用することをお薦めします。「Webアプリケーション、EJB用のセキュリティ・モデルの比較」を参照してください

詳細モデルは、「ロールとポリシーのチェック」、「WebアプリケーションまたはEJBのデプロイ時」、および「ロール・マッピングの組合せを有効化」という3つの設定で構成されます。これらの設定を理解していないと、セキュリティ・データが不適切なものになったり、失われたりすることがあります。

このモデルの構成を変更すると、このモデルを使用するすべてのWebアプリケーションおよびEJBにその変更が適用されます。

以下の節では、詳細セキュリティ・モデルの設定について説明します。

「ロールとポリシーのチェック」設定の理解

「ロールとポリシーのチェック」の設定では、セキュリティ・サービスによってすべてのURLとEJBモジュールに対してセキュリティ・チェックが実施されるのか、デプロイメント記述子およびアノテーションで保護されたものに対してのみ実施されるのかを決定します。

WLSTを使用して、「ロールとポリシーのチェック」の値を次のように設定します:

WebアプリケーションおよびEJBリソースのうち、関連するデプロイメント記述子(DD)およびアノテーションにセキュリティの指定があるものに対してのみセキュリティ・チェックを実施するには、RealmMBean.FullyDelegateAuthorizationをfalseに設定します。

ノート:

この選択は、デプロイメント記述子のみのセキュリティ・モデルと似ています。セキュリティ・サービスでは、WebアプリケーションまたはEJBのデプロイメント記述子およびアノテーションに定義されているロールおよびポリシーのみが使用されます。
すべてのWebアプリケーションおよびEJBリソースに対してセキュリティ・チェックを実施するには、対象とするWebLogicリソースのデプロイメント記述子およびアノテーションにセキュリティ設定があるかどうかにかかわらず、RealmMBean.FullyDelegateAuthorizationをtrueに設定します。

ノート:

これを選択した場合、「WebアプリケーションまたはEJBのデプロイ時」設定も併せて構成できます。

WebアプリケーションまたはEJBのデプロイ時」設定の理解

「WebアプリケーションまたはEJBのデプロイ時」の設定では、セキュリティ・サービスでデプロイメント記述子およびアノテーションのロールおよびポリシーのデータを無視するか、WebアプリケーションやEJBをデプロイするたびに、ロール・マッピング・プロバイダや認可プロバイダのデータベースにデータをインポートするかを決定します。

ノート:

この設定は「ロールとポリシーのチェック」で「すべてのWebアプリケーションとEJB」を設定した場合にのみ有効です(RealmMBean.FullyDelegateAuthorization=true)。

WLSTを使用して、「WebアプリケーションまたはEJBのデプロイ時」の値を次のように設定します:

WebLogicリモート・コンソールのみを使用してWebアプリケーションとEJBリソースを保護するには、RealmMBean.DeployPolicyIgnoredとRealmMBean.DeployRoleIgnoredの両方をtrueに設定します。

この時点で、WebLogicリモート・コンソールを使用してリソースの保護を開始できます。Oracle WebLogicリモート・コンソール・オンライン・ヘルプのスコープ指定ロールの作成およびリソース・インスタンスのポリシーの作成を参照してください。
デプロイメント記述子およびアノテーションからセキュリティ・データをインポートするには、RealmMBean.DeployPolicyIgnoredとRealmMBean.DeployRoleIgnoredの両方をfalseに設定します。

ノート:

セキュリティ・データをインポートすると、セキュリティ・データの整合性にリスクが生じます。データをインポートする際には毎回セキュリティ・サービスによって、プロバイダのデータベースからのあらゆる関連セキュリティ・データの削除と、デプロイメント記述子およびアノテーションからのデータの再インポートが試行されます。インポートされたセキュリティ・データに変更を加えていた場合、その変更が無効になったり、削除されたりすることがあります。

「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の相互作用

表4-6に、「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の設定値をさまざまに組み合せて、WebLogicセキュリティ・サービスで希望する動作を行う方法を示します。

表4-6 「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の相互作用

セキュリティを制御する対象. . .	WebアプリケーションおよびEJBリソースに対するセキュリティの設定. . .	「ロールとポリシーのチェック」の設定値. . .	「WebアプリケーションまたはEJBのデプロイ時」の設定値. . .
すべてのWebアプリケーションおよびEJBリソース	WebLogicリモート・コンソールのみ使用	すべてのWebアプリケーションとEJB	デプロイメント記述子のロールとポリシーを無視
すべてのWebアプリケーションおよびEJBリソース	WebアプリケーションまたはEJBリソースのデプロイ時に、セキュリティ・データをデプロイメント記述子およびアノテーションから構成済みの認可プロバイダおよびロール・マッピング・プロバイダのデータベースにコピーするか再初期化して、その後、セキュリティ・ロールとセキュリティ・ポリシーの変更をその他の方法で行います。ノート: WebアプリケーションまたはEJBリソースがデプロイされるたびに、セキュリティ・データはコピーまたは再初期化されます。	すべてのWebアプリケーションとEJB	デプロイメント記述子のロールとポリシーを初期化
デプロイメント記述子およびアノテーションで指定されているWebアプリケーションおよびEJBのメソッドのみ(デフォルト構成)	デプロイメント記述子およびアノテーションのみを使用する	デプロイメント記述子で保護されたWebアプリケーションとEJB	--

セキュリティを制御する対象. . .

WebアプリケーションおよびEJBリソースに対するセキュリティの設定. . .

「ロールとポリシーのチェック」の設定値. . .

「WebアプリケーションまたはEJBのデプロイ時」の設定値. . .

すべてのWebアプリケーションおよびEJBリソース

WebLogicリモート・コンソールのみ使用

すべての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のセキュリティに与える影響

ロール・マッピングの組合せが無効ロール・マッピングの組合せが有効

ロール・マッピングの組合せが無効	ロール・マッピングの組合せが有効
各コンテナのロール・マッピングは、`<externally-defined>`記述子要素で定義されていない限り、他のコンテナに対して排他的なものとなります。	アプリケーションのロール・マッピングがEJBおよびWebアプリケーションのマッピングと組み合せられることで、すべてのプリンシパル・マッピングが含まれるようになります。セキュリティ・サービスでは、ロール・マッピングが論理`OR`演算子と組み合せられます。
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ファイルで定義する必要があります。その他のコンテナで定義されたロール・マッピングは、`<externally-defined>`記述子要素で定義されていない限り、使用されません。	ejb-jar.xmlファイル内の1つまたは複数のポリシーで、weblogic-ejb-jar.xmlファイル内にマッピングが存在しないロールが指定されている場合、EJBコンテナは未定義のロールに対して空のマップを作成します(つまり、ロールはプリンシパルを含まないものとして明示的に定義されます)。したがって、そのようなポリシーで保護されるメソッドにはアクセスできません。

各コンテナのロール・マッピングは、<externally-defined>記述子要素で定義されていない限り、他のコンテナに対して排他的なものとなります。

アプリケーションのロール・マッピングがEJBおよびWebアプリケーションのマッピングと組み合せられることで、すべてのプリンシパル・マッピングが含まれるようになります。セキュリティ・サービスでは、ロール・マッピングが論理OR演算子と組み合せられます。

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ファイルで定義する必要があります。その他のコンテナで定義されたロール・マッピングは、<externally-defined>記述子要素で定義されていない限り、使用されません。

ejb-jar.xmlファイル内の1つまたは複数のポリシーで、weblogic-ejb-jar.xmlファイル内にマッピングが存在しないロールが指定されている場合、EJBコンテナは未定義のロールに対して空のマップを作成します(つまり、ロールはプリンシパルを含まないものとして明示的に定義されます)。したがって、そのようなポリシーで保護されるメソッドにはアクセスできません。

使用例

以下の例で、ロール・マッピングの組合せが有効な場合と無効な場合におけるロール・マッピングの動作の違いについて示します。

EAR、WAR、および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コンテナでは、外部的に定義されている必要があり、定義されていない場合にはデプロイメントが失敗します。

EARおよびWARの例

MyAppEarにMyAppWARが含まれます。ロールからプリンシパルへのマッピングは以下のとおりです。

MyAppEARの記述子では、myRole = p1
MyAppWARの記述子では、myRole = (何も定義されません)

組み合せたロール・マッピングが有効になっている場合、ロール・マッピングは以下のようになります。

EARコンテナでは、myRoleがp1にマップされます。
WARコンテナでは、myRoleがp1にマップされます。

組み合せたロールの動作なので、このマッピングは同じになります。

組み合せたロール・マッピングが無効になっている場合、ロール・マッピングは以下のようになります。

EARコンテナでは、myRoleがp1にマップされます。
WARコンテナでは、myRoleがMyRoleにマップされます。

Webアプリケーションにマッピングが定義されていない場合、このマッピングは同じになります。EARマッピングがWARマッピングにコピーされます。

Webアプリケーション、EJBの保護

メタデータ・アノテーションの場合、EJBをコード化する際にセキュリティ関連アノテーションを追加して、すべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定します。デプロイ時にデプロイヤは、これらのセキュリティ・ロールがまだ存在しない場合は作成し、WebLogicリモート・コンソールを使用してユーザーをこれらのロールにマッピングすることで、セキュリティ・レルムを更新します。詳細は、Oracle WebLogicリモート・コンソール・オンライン・ヘルプのセキュリティ・ポリシーおよびロールを参照してください。

デプロイメント記述子(およびWebLogicリモート・コンソール)ベースのセキュリティの場合、セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。

WebLogicリモート・コンソールを使用した、アプリケーションのデプロイ、セキュリティ・モデルの選択、ロールやポリシーの変更、他の関連タスクの実行については、Oracle WebLogicリモート・コンソール・オンライン・ヘルプのアプリケーションのデプロイを参照してください。

デプロイメント記述子を使用してWebアプリケーションまたはEJBを保護する場合は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のWebアプリケーションでの宣言によるセキュリティの使用に関する項およびEJBでの宣言によるセキュリティの使用に関する項を参照してください。