ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 9.0 ドキュメント > WebLogic リソースのセキュリティ > EJB および Web アプリケーション リソースの保護のオプション

WebLogic リソースのセキュリティ

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

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

以下の節では、エンタープライズ Java Bean (EJB) および Web アプリケーション リソースのリソース セキュリティ コンフィグレーションのオプションについて説明します。

注意 : この節で説明されている EJB リソースに対する手順は、メッセージ駆動型 Bean (MDB) にも適用できます。

 

セキュリティ方法とセキュリティ モデル

J2EE プラットフォームはデプロイメント記述子で Web アプリケーションおよび EJB のセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、Web アプリケーションおよび EJB リソースを保護する方法を選択できるようになっています。デプロイメント記述子のみを使用することも Administration Console のみを使用することもできます。また、一部の状況についてはデプロイメント記述子と Administration Console を組み合わせて使用できます。「セキュリティ方法の選択」を参照してください。

アプリケーションをデプロイする場合には、使用する方法に基づいてセキュリティ モデルを選択します。WebLogic では、個々のデプロイメントについて 3 種類のセキュリティ モデルがサポートされ、レルム全体のコンフィグレーションについては詳細セキュリティ モデルがサポートされます。「セキュリティ モデルの選択」を参照してください。

JACC セキュリティ

JSR 115 に定義されているように JACC (Java authorization Contract for Containers) を使用してセキュリティを実装している場合、Web アプリケーションおよび EJB に対する Administration Console でのセキュリティ機能は無効になります。デプロイメント記述子のみを使用してセキュリティを定義する必要があります。「デプロイメント記述子の使用」を参照してください。

 

セキュリティ方法の選択

Web アプリケーションおよび EJB リソースの保護については、以下の 3 つの方法から選択できます。

WebLogic Server Administration Console の使用

Administration Console を使用して Web アプリケーションおよび EJB リソースを保護する方法の主な利点は、セキュリティ管理が統合されていることです。組織のセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル ユーザ インタフェースからすべてのセキュリティ コンフィグレーションを変更できます。ユーザ、グループ、セキュリティ ロール、およびセキュリティ ポリシーを、すべて Administration Console を使用して定義できます。その結果、更新されたセキュリティ要件に基づく変更のプロセスがより効率的になります。

デプロイメント記述子の使用

J2EE デプロイメント記述子と WebLogic デプロイメント記述子を使用して Web アプリケーションおよび EJB リソースを保護する方法の主な利点は、Web アプリケーションと EJB に宣言的なセキュリティを追加するための一般的かつ標準的な方法であることです。また、この手法は多くの組織でよく知られている可能性があります。この手法を使用する場合、セキュリティ ロールとセキュリティ ポリシーは web.xml、weblogic.xml、ejb-jar.xml、weblogic-ejb-jar.xml デプロイメント記述子に指定されます。

Administration Console およびデプロイメント記述子の使用

現在デプロイメント記述子を使用して Web アプリケーションと EJB リソースを保護している企業では、WebLogic Server Administration Console の統合されたセキュリティ管理機能を利用することもできます。Administration Console では、既存のデプロイメント記述子から Web アプリケーションまたは EJB モジュールのデプロイメントにセキュリティ コンフィグレーションをコピーできます。セキュリティ コンフィグレーションをロール マッピング プロバイダと認可プロバイダのデータベースにコピーした場合、セキュリティ ロールとセキュリティ ポリシーに対する以後の更新は Administration Console を使用して行います。

 

セキュリティ モデルの選択

セキュリティ モデルは、選択したセキュリティ方法に応じて異なります (「セキュリティ方法の選択」を参照してください)。アプリケーションをデプロイする予定の場合は、複数のセキュリティ モデルから選択できます。WebLogic Server Administration Console のデプロイメント ツールを使用している場合、オプションが次のように表示されます。

図 4-1 Administration Console: [デプロイメント アシスタント] の [セキュリティ] セクション

Administration Console: [デプロイメント アシスタント] の [セキュリティ] セクション

選択したセキュリティ モデルはデプロイメントの生存期間に渡って適用されます。セキュリティ モデルを変更するには、そのデプロイメントを削除して新しいデプロイメントを作成する必要があります。

注意 : レルムの設定の [セキュリティ モデル] で、デプロイメントのデフォルトのセキュリティ モデルを設定できます。詳細については、Administration Console オンライン ヘルプの「デフォルトのセキュリティ デプロイメント モデルの設定」を参照してください。

以下の節で各モデルについて説明します。

DD のみモデル

このモデルは、上記の 図 4-1 の最初の [セキュリティ] オプションに対応します。

このセキュリティ モデルでは、開発者によって J2EE デプロイメント記述子 (DD) および WebLogic Server DD に定義されたロールおよびポリシーのみが使用されます。管理者はセキュリティ プリンシパル (グループまたはユーザ) が適切にマップされているかを確認します。表 4-1 に一般的なシナリオを示します。

表 4-1 DD のみ : 一般的なシナリオ

企業 A、開発者

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

  • J2EE DD のロールに EJB または Web URL をマップする。

  • WebLogic Server DD のプリンシパルにロールをマップする。

  • アプリケーションを管理者/デプロイ担当者に引き継ぐ。

  • WebLogic Server Administration Console を使用して、必ずグループが存在して適切にユーザにマップされているようにする。

詳細については、『WebLogic Security プログラミングの概要』の「Using Declarative Security With Web Applications」および「Using Declarative Security With EJBs」を参照してください。

DD のみを選択した場合、デフォルトでは組み合わせた形のロール マッピングが使用されます。詳細については、「[ロール マッピングの組み合わせを有効化] 設定について」を参照してください。

カスタム ロール モデル

このモデルは、上記の図 4-1 の 2 番目の [セキュリティ] オプションに対応します。

このセキュリティ モデルでは J2EE DD に定義されたポリシーが使用され、WebLogic Server DD のプリンシパルのマッピングは無視されます。管理者は Administration Console を使用してすべてのロール マッピングを行います。表 4-2 に一般的なシナリオを示します。

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

企業 A、ISV 開発者または
企業 B、開発者

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

  • EJB/URL を J2EE デプロイメント記述子のロールにマップする。

  • アプリケーションを管理者/デプロイ担当者に引き継ぐ。

  • WebLogic Server Administration Console を使用してセキュリティ ロールを定義する。

詳細については、Administration Console オンライン ヘルプの「スコープ指定セキュリティ ロールの作成」を参照してください。

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

このモデルは、上記の図 4-1 の 3 番目の [セキュリティ] オプションに対応します。

このセキュリティ モデルではデプロイメント記述子に定義されているあらゆるロールとポリシーが無視されます。管理者は Administration Console を使用してリソースを保護します。表 4-3 に一般的なシナリオを示します。

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

企業 A、開発者

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

  • J2EE DD、WebLogic Server DD へのマッピングは行わない。

  • アプリケーションを管理者/デプロイ担当者に引き継ぐ。

  • WebLogic Administration Console を使用して、EJB および Web アプリケーションのロールおよびポリシーを定義する。

詳細については、Administration Console オンライン ヘルプの「スコープ指定セキュリティ ロールの作成」および「セキュリティ ポリシーの作成」を参照してください。

セキュリティ レルム コンフィグレーション (詳細モデル)

このモデルは、上記の図 4-1 の 4 番目の [セキュリティ] オプションに対応します。

このセキュリティ モデルを使用すると、セキュリティ レルムの EJB および Web アプリケーション リソースを含むすべてのデプロイメントに対して、単一のセキュリティ モデルを定義できます。このモデルでは、以下のセキュリティ方法から 1 つを選択できます。

注意 : 現在のリリースより前の WebLogic Server では、この方法が利用できる唯一のセキュリティ モデルでした。EJB および Web アプリケーションを引き続き以前のリリースと同様の方法で保護する場合は、詳細セキュリティを選択します。

詳細オプションを選択する場合には、初回のデプロイメントの後に以下のレルムのセキュリティ コンフィグレーションを設定する必要があります。

詳細については「詳細セキュリティ モデルの使い方」を参照してください。

 

詳細セキュリティ モデルの使い方

注意 : このセクションの内容は、EJB および Web アプリケーションをデプロイメントごとにでなくセキュリティ レルム レベルで制御する方法 (詳細セキュリティ オプション) を選択した場合にのみ適用されます。

WebLogic Server Administration Console またはデプロイメント記述子のどちらを使用して Web アプリケーションおよび EJB リソースを保護する場合でも、WebLogic Server の 2 つの重要な設定 ([ロールとポリシーのチェック] と [今後の再デプロイの設定]) について理解しておく必要があります。これらの設定についての理解が不十分な場合、セキュリティ コンフィグレーションが不適切なものになったり、失われたりすることがあります。

詳細セキュリティ オプションを使用して Web アプリケーションまたは EJB リソースを保護しようとする前には、以下の節をお読みください。

セキュリティ ロールとセキュリティ ポリシーをチェックする方法について

パフォーマンスを管理するためには、WebLogic Server Administration Console で WebLogic Security サービスがセキュリティを制御する方法を指定する必要があります。この指定には、図 4-2 に示す [ロールとポリシーのチェック] ドロップダウン メニューを使用します。

図 4-2 Administration Console: 詳細セキュリティ モデルのレルムの設定

Administration Console: 詳細セキュリティ モデルのレルムの設定

[ロールとポリシーのチェック] ドロップダウン メニューの値を [すべての Web アプリケーションと EJB] に変更した場合は、その Web アプリケーションまたは EJB モジュールが再デプロイされたときに WebLogic Security サービスが実行する処理を指定する必要があります。詳細については、「[今後の再デプロイの設定] について」を参照してください。

注意 : [ロールとポリシーのチェック] 設定は、それが設定されている WebLogic Server ドメインのすべての WebLogic Server インスタンス (サーバ) に影響します。

fullyDelegateAuthorization フラグの使い方

fullyDelegateAuthorization フラグ (WebLogic Server の起動時に設定するコマンドライン引数) を使用して、Web アプリケーションおよび EJB リソースでのセキュリティの制御方法を指定することもできます。

注意 : この設定は、詳細セキュリティ モデルを使用する場合にのみ適用されます。

fullyDelegateAuthorization フラグの値を false に設定すると、WebLogic Security サービスでは、関連するデプロイメント記述子でセキュリティが指定されている Web アプリケーションと EJB リソースに対してのみ、セキュリティ チェックが実行されます。

このフラグを設定するには、以下のように入力します。

-Dweblogic.security.fullyDelegateAuthorization = boolean_value

boolean_value は true または false であり、WebLogic Server インスタンスを起動するたびにコマンドラインで入力します。

注意 : 管理サーバと管理対象サーバの両方で fullyDelegateAuthorization フラグが同じように設定されているようにしてください。

[今後の再デプロイの設定] について

[ロールとポリシーのチェック] ドロップダウン メニューの [すべての Web アプリケーションと EJB] で、WebLogic Security サービスによるセキュリティの制御を決定した場合、これらの Web アプリケーションおよび EJB リソースの保護に使用する方法を WebLogic Server に通知することも必要です (詳細については、「セキュリティ方法の選択」を参照してください)。この指定には、図 4-2 にある [今後の再デプロイの設定] ドロップダウン メニューを使用します。

[今後の再デプロイの設定] ドロップダウン メニューの値は、以下のように設定します。

警告 : [今後の再デプロイの設定] の切り替えは、セキュリティ コンフィグレーションが不適切になったり失われたりするおそれがあるのでお勧めできません。設定を切り替える必要がある場合 (特に「Administration Console およびデプロイメント記述子の使用」で説明した状況の場合) は、「詳細セキュリティ モデルでの組み合わせた方法の使用」の指示に従います。

[ロールとポリシーのチェック] と [今後の再デプロイの設定] の相互作用のしくみ

表 4-4 に、[ロールとポリシーのチェック] と [今後の再デプロイの設定] の設定値をさまざまに組み合わせて WebLogic Security サービスの動作を実現する方法を示します。

表 4-4 [ロールとポリシーのチェック] と [今後の再デプロイの設定] の相互作用

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

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

[ロールとポリシーのチェック] の設定値

[今後の再デプロイの設定] の設定値

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

Administration Console のみを使用する。

[すべての Web アプリケーションと EJB]

[デプロイメント記述子のロールとポリシーを無視]

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

Web アプリケーションまたは EJB モジュールのデプロイ時に、セキュリティ データをデプロイメント記述子からコンフィグレーション済みの認可プロバイダおよびロール マッピング プロバイダのデータベースにコピーするか再初期化して、その後、セキュリティ ロールとセキュリティ ポリシーの変更をその他の方法で行う。

注意 : Web アプリケーションまたは EJB モジュールがデプロイされるたびに、セキュリティ データはコピーまたは再初期化される。

[すべての Web アプリケーションと EJB]

[デプロイメント記述子のロールとポリシーを初期化]

デプロイメント記述子で指定されている Web アプリケーションおよび EJB のメソッドのみ (デフォルト コンフィグレーション)

デプロイメント記述子のみを使用する。

[デプロイメント記述子で保護された Web アプリケーションと EJB]

--

[ロールとポリシーのチェック] と [今後の再デプロイの設定] の変更方法

この設定を変更するには、Administration Console を使用します。詳細については、Administration Console オンライン ヘルプの「[今後の再デプロイの設定] の設定の復帰」を参照してください。

詳細セキュリティ モデルでの組み合わせた方法の使用

「Administration Console およびデプロイメント記述子の使用」で説明したように、WebLogic Server Administration Console と J2EE/WebLogic のデプロイメント記述子の設定は組み合わせられます。これは一般的に、以下の 2 つの理由から行います。

警告 : 組み合わせた方法をこの他の目的で使用することはお勧めしません。

以下の節では、組み合わせた方法を使用して Web アプリケーションおよび EJB リソースを保護する手順について説明します。

デプロイメント記述子からセキュリティ コンフィグレーションをコピーする

以下の手順は、詳細セキュリティ モデルを使用しているか WebLogic Server のバージョン 8.x からアップグレードしていて、現在 J2EE および WebLogic デプロイメント記述子で Web アプリケーションおよび EJB リソースを保護しているが、今後は WebLogic Server Administration Console のみを使用して保護することを考えている管理者に向けて書かれたものです。

デプロイメント記述子および Administration Console の両方でセキュリティ コンフィグレーションを管理する方法は推奨されるものではありません。これは、Administration Console を使用した完全なセキュリティ管理に移行するための手順の 1 つに過ぎません。

警告 : 組み合わせた方法を使用する場合、Web アプリケーションおよび EJB リソースのセキュリティ コンフィグレーションがオーバーライドされる可能性があります。そのため、適切なセキュリティ コンフィグレーションが Web アプリケーションおよび EJB リソースと必ず同じ場所にあるように十分注意してください。

Web アプリケーションまたは EJB リソースのセキュリティ コンフィグレーションをコピーして、以後 WebLogic Server Administration Console で変更を行うようにするには、次の手順に従います。

手順 2: コピーしたセキュリティ ポリシーを検証する (省略可能)

コピーしたセキュリティ ポリシーを検証するには、表 4-5 の該当するカラムに示された手順に従います。

表 4-5 リソース タイプに基づく、コピーしたセキュリティ ポリシーの検証 

手順

Web アプリケーション リソース

EJB リソース

1

Web アプリケーションの web.xml デプロイメント記述子を開き、<url-pattern> および <http-method> 要素の内容と、<auth-constraint> 要素の <role-name> 下位要素の内容を記録しておく。

EJB の ejb-jar.xml デプロイメント記述子を開き、<method-permission> 要素の内容、特に <role-name>、<ejb-name>、および <method-name> 下位要素の内容を記録しておく。

2

Administration Console を使用して、各リソースのセキュリティ ポリシーおよび関連付けられたセキュリティ ロールを表示する。Administration Console オンライン ヘルプの「Web アプリケーション リソースへのアクセス」を参照。

Administration Console を使用して、各リソースのセキュリティ ポリシーおよび関連付けられたセキュリティ ロールを表示する。Administration Console オンライン ヘルプの「EJB リソースへのアクセス」を参照。

手順 3: コピーしたセキュリティ ロールを検証する (省略可能)

コピーしたセキュリティ ロールを検証するには、表 4-6 の該当するカラムに示された手順に従います。

表 4-6 リソース タイプに基づく、コピーしたセキュリティ ロールの検証 

手順

Web アプリケーション リソース

EJB リソース

1

Web アプリケーションの weblogic.xml デプロイメント記述子を開き、<security-role-assignment> 要素の内容、特に <role-name> および <principal-name> の各下位要素の内容を記録しておく。

注意 : デプロイメント記述子で Web アプリケーションに対して <externally-defined> 要素が使用されている場合、実際にはスコープ ロールが定義されないため、Web アプリケーションのスコープ ロールはコピーできない。

EJB の weblogic-ejb-jar.xml デプロイメント記述子を開き、<security-role-assignment> 要素の内容、特に <role-name> および <principal-name> 下位要素の内容を記録しておく。

注意 : デプロイメント記述子で EJB に対して <externally-defined> 要素が使用されている場合、実際にはスコープ ロールが定義されないため、EJB のスコープ ロールはコピーできない。

2

Administration Console を使用して、各リソースのセキュリティ ロールを表示する。Administration Console オンライン ヘルプの「Web アプリケーション リソースへのアクセス」を参照。

Administration Console を使用して、各リソースのセキュリティ ロールを表示する。Administration Console オンライン ヘルプの「EJB リソースへのアクセス」を参照。

セキュリティ コンフィグレーションを再初期化する

Web アプリケーションおよび EJB リソースのセキュリティ コンフィグレーションを再初期化して、デプロイメント記述子で指定されていた元の状態に戻すには、次の手順に従います。

[ロール マッピングの組み合わせを有効化] 設定について

[ロール マッピングの組み合わせを有効化] 設定は、WebLogic Server の旧バージョン (8.x) との下位互換性のために用意されています。初めからバージョン 9.x でデプロイされたすべてのアプリケーションにおけるこの設定のデフォルト値は「true」 (有効) です。以前バージョン 8.1 でデプロイして 9.x にアップグレードしたアプリケーションにおけるこの設定のデフォルト値は「false」 (無効) です。

[ロール マッピングの組み合わせを有効化] 設定では、エンタープライズ アプリケーション、Web アプリケーション、および EJB コンテナのロール マッピングの対話方法が決定されます。表 4-7 に、これらの対照的な動作についてまとめます。

表 4-7 [ロール マッピングの組み合わせを有効化] フラグの対照的な動作

[ロール マッピングの組み合わせを有効化] が無効の場合

[ロール マッピングの組み合わせを有効化] が有効の場合

デフォルトでは、各コンテナのロール マッピングが他のコンテナに対して排他的である (<externally-defined> 記述子要素に定義されている場合を除く)。

アプリケーションのロール マッピングが EJB および Web アプリケーションのマッピングと組み合わされ、すべてのプリンシパル マッピングが含まれる。

ロール マッピングが Web アプリケーションに定義されていない限り、Web アプリケーション コンテナではあらゆるロール マッピングが web.xml に定義されていると見なす。

Web アプリケーション コンテナでは、web.xml のロールへの基本的な参照を使用して空のロール マップを作成する。

EJB のロール マッピングは web.xml に定義されている必要がある。他のコンテナに定義されているロール マッピングは、<externally-defined> が定義されていない限り使用されない。

EJB コンテナでは、web.xml のロールへの基本的な参照を使用して空のロール マップを作成する。

使用例

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

EAR、WAR、および EJB の例

MyAppEar に MyAppWAR が含まれ、MyAppWAR に MyEJB が含まれます。プリンシパル マッピングへのロール (p1 および p2) は以下のとおりです。

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

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

EAR および WAR の例

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

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

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

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

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

デフォルト設定を変更する

[ロール マッピングの組み合わせを有効化] のデフォルト値の変更が必要になる理由としては、以下の 2 つがあります。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次