|
|
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 用のセキュリティ機能は Administration Console では無効になります。『WebLogic Security プログラマーズ ガイド』の「Java Authorization Contract for Containers の使用」を参照してください。 |
セキュリティ モデルは Web アプリケーションまたは EJB をデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、その Web アプリケーションまたは EJB を削除してから再デプロイする必要があります。
以下の節では、Web アプリケーションや EJB (Enterprise Java Bean) リソースを保護するためのオプションについて説明します。
| 注意 : | この節で説明されている EJB リソースに対する手順は、メッセージ駆動型 Bean (MDB) にも適用できます。 |
各セキュリティ モデルでは、Web アプリケーションおよび EJB の保護に関して 2 種類の動作、すなわち、どこに定義されているロールとポリシーを使用するか、およびどのような URL パターンや EJB メソッドに対して Security サービスがトリガされ、セキュリティ チェックが実行されるかが決まっています。表 4-1 で、それぞれのモデルを比較します。
以下の節では、各モデルについて説明し、それぞれに適したシナリオを提示します。
これは標準の Java EE モデルで、Web アプリケーションおよび EJB に対して宣言型セキュリティを追加するための広く知られた方法です。このモデルでは、開発者によって Java EE デプロイメント記述子 (DD) および WebLogic Server DD に定義されたロールおよびポリシーのみが使用されます。デプロイメント記述子のセキュリティ プリンシパル (グループやユーザ) が存在し、セキュリティ レルムに適切にマップされているかどうかについて、セキュリティ管理者による確認が必要になります。
| 注意 : | このモデルは、EAR に適用するアプリケーション スコープのロールに影響を与えます。このモデルでは、Security サービスは 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 のプリンシパルのマッピングは無視されます。セキュリティ管理者が Administration Console を使用してロール マッピングを完了します。
このモデルを使用すると、開発チームのメンバーがそれぞれの専門分野に集中できます。Web アプリケーションや EJB の開発者は、どの URL パターンや EJB メソッドを保護するかを宣言するだけで済みます。セキュリティ管理者はその後で、所定のレルムに対する既存のロールとプリンシパルの階層に適したロール マッピングを作成します。
開発者がデプロイメント記述子のポリシーを変更すると、その変更は Web アプリケーションまたは EJB を再デプロイした直後に認識されます。開発者がロール マッピングを変更すると、その変更は再デプロイしなくても即座に有効になります。
このモデルは、開発者と管理者が作業を綿密に調整できない場合、またはロール マッピングが頻繁に変更される場合に適しています。表 4-3 に、一般的なシナリオを示します。
このセキュリティ モデルを使用すると、統合的で動的なセキュリティ管理を行えます。セキュリティ管理者が Administration Console で作成したロールとポリシーが使用され、デプロイメント記述子に定義されているロールとポリシーは無視されます。
組織のセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル ユーザ インタフェースからすべてのセキュリティ コンフィグレーションを変更できます。ユーザ、グループ、セキュリティ ロール、およびセキュリティ ポリシーを、すべて Administration Console を使用して定義できます。その結果、更新されたセキュリティ要件に基づく変更のプロセスがより効率的になります。
このモデルは、Web アプリケーションまたは EJB の全体を保護するだけでよい場合に適しています。ただし、特定の URL パターンや EJB モジュールを大量かつ詳細に制御する必要がある場合にはあまり適していません。そうした詳細な制御を行うには、保護する URL パターンや EJB メソッドに関する詳細な情報を、開発者から管理者に提供する必要があります。詳細な制御が必要な場合には、カスタム ロール モデルの使用を検討してください (「カスタム ロール モデル」を参照)。
またこのモデルでは、クライアントからどの URL が要求され、どの EJB メソッドが呼び出されようとしているかに関わらず、パーミッションがチェックされるので、わずかなパフォーマンスの低下が見られます。
表 4-4 に、一般的なシナリオを示します。
このモデルは、主に 9.0 より前のリリースとの下位互換性のために提供されています。
このモデルでは以下の動作をコンフィグレーションできます (「[ロール マッピングの組み合わせを有効化] 設定について」を参照)。
セキュリティ データのインポート機能は以下のタスクのために用意されています。
データをインポートした後には、Administration Console を使用してセキュリティ データを変更できます。
| 警告 : | セキュリティ データをインポートすると、セキュリティ データの整合性にリスクが生じます。データをインポートする際には毎回 Security サービスによって、プロバイダのデータベースからのあらゆる関連データの削除と、デプロイメント記述子からのデータの再インポートが試行されます。インポートされたセキュリティ データに変更を加えていた場合、その変更が無効になったり、削除されたりすることがあります。セキュリティ データをインポートする場合には、Administration Console オンライン ヘルプの「Web アプリケーションおよび EJB のセキュリティの管理」にある推奨事項に従ってください。 |
このモデルのコンフィグレーションを変更すると、このモデルを使用するすべての Web アプリケーションおよび EJB にその変更が適用されます。たとえば、詳細モデルをコンフィグレーションしてすべての URL とメソッドに対してセキュリティ チェックを実施するようにしてから、複数の EJB をデプロイして詳細モデルを使用するようにコンフィグレーションするとします。この場合、クライアントでどの EJB のどのメソッドを呼び出そうとした場合にも、毎回 EJB コンテナによってセキュリティ チェックが要求されます。その後、詳細モデルを変更してデプロイメント記述子で保護されている EJB メソッドにのみセキュリティ チェックを実施するようにすると、EJB コンテナでは即座に、複数の EJB において保護されているメソッドにのみセキュリティ チェックが要求されるようになります。
| 注意 : | この節の内容は、詳細セキュリティ モデルを使用する Web アプリケーションおよび EJB のみに適用されるものです。 |
詳細モデルは、Administration Console の [ロールとポリシーのチェック]、[Web アプリケーションまたは EJB のデプロイ時]、および [ロール マッピングの組み合わせを有効化] という 3 つの設定でコンフィグレーションします。これらの設定を理解していないと、セキュリティ データが不適切なものになったり、失われたりすることがあります。
このモデルのコンフィグレーションを変更すると、このモデルを使用するすべての Web アプリケーションおよび EJB にその変更が適用されます。
以下の節では、詳細セキュリティ モデルの設定について説明します。
[ロールとポリシーのチェック] の設定では、Security サービスによってすべての URL と EJB モジュールに対してセキュリティ チェックが実施されるのか、デプロイメント記述子で保護されたものに対してのみ実施されるのかを決定します。
[ロールとポリシーのチェック] の値は以下のように設定します。
| 注意 : | この設定を選択した場合の動作は、デプロイメント記述子のみのセキュリティ モデルと似ています。Security サービスでは、Web アプリケーションまたは EJB のデプロイメント記述子に定義されているロールおよびポリシーが使用されます。 |
| 注意 : | これを選択した場合、[Web アプリケーションまたは EJB のデプロイ時] 設定も併せてコンフィグレーションできます。 |
[Web アプリケーションまたは EJB のデプロイ時] の設定では、Security サービスでデプロイメント記述子のロールおよびポリシーのデータを無視するか、Web アプリケーションや EJB をデプロイするたびに、ロール マッピング プロバイダや認可プロバイダのデータベースにデータをインポートするかを決定します。
| 注意 : | この設定は [ロールとポリシーのチェック] で [すべての Web アプリケーションと EJB] を設定した場合にのみ有効です。 |
[Web アプリケーションまたは EJB のデプロイ時] の値は以下のように設定します。
| 警告 : | セキュリティ データをインポートすると、セキュリティ データの整合性にリスクが生じます。データをインポートする際には毎回 Security サービスによって、プロバイダのデータベースからのあらゆる関連セキュリティ データの削除と、デプロイメント記述子からのデータの再インポートが試行されます。インポートされたセキュリティ データに変更を加えていた場合、その変更が無効になったり、削除されたりすることがあります。セキュリティ データをインポートする場合には、Administration Console オンライン ヘルプの「Web アプリケーションおよび EJB のセキュリティの管理」にある推奨手順に従ってください。 |
表 4-5 に、[ロールとポリシーのチェック] と [Web アプリケーションまたは EJB のデプロイ時] の設定値をさまざまに組み合わせて、WebLogic Security サービスで希望する動作を行う方法を示します。
[ロール マッピングの組み合わせを有効化] の設定では、エンタープライズ アプリケーション、Web アプリケーション、および EJB コンテナ内のロール マッピングがどのように相互作用するかを決定します。
この設定は、8.x バージョンとの下位互換性のために提供されています。バージョン 9.x で初めからデプロイされたすべてのアプリケーションにおいて、この設定のデフォルト値は「true」(有効) です。以前バージョン 8.1 でデプロイして 9.x にアップグレードしたアプリケーションにおけるこの設定のデフォルト値は「false」(無効) です。以下のどちらかに当てはまる場合、[ロール マッピングの組み合わせを有効化] のデフォルト値を変更することを検討してください。
表 4-6 で、この設定が Web アプリケーションと EJB に与える影響について比較します。
web.xml ファイル内の 1 つまたは複数のポリシーで、weblogic.xml ファイル内にロール マッピングが存在しないロールが指定されている場合、Web アプリケーション コンテナは未定義のロールがプリンシパルの名前であると想定する。そのため、想定されたプリンシパルがロール名にマップされる。たとえば、web.xml ファイルのポリシーの 1 つに以下のようなスタンザがあり、
|
|
以下の例で、ロール マッピングの組み合わせが有効な場合と無効な場合におけるロール マッピングの動作の違いについて示します。
MyAppEar に MyAppWAR が含まれ、MyAppWAR に MyEJB が含まれます。プリンシパル マッピングへのロール (p1 および p2) は以下のとおりです。
組み合わせたロール マッピングが有効になっている場合、ロール マッピングは以下のようになります。
組み合わせたロール マッピングが無効になっている場合、ロール マッピングは以下のようになります。
MyAppEar に MyAppWAR が含まれます。ロールからプリンシパルへのマッピングは以下のとおりです。
組み合わせたロール マッピングが有効になっている場合、ロール マッピングは以下のようになります。
| 注意 : | 組み合わせたロールの動作なので、このマッピングは同じになります。 |
組み合わせたロール マッピングが無効になっている場合、ロール マッピングは以下のようになります。
| 注意 : | Web アプリケーションにマッピングが定義されていない場合、このマッピングは同じになります。EAR マッピングが WAR マッピングにコピーされます。 |
セキュリティ モデルは Web アプリケーションまたは EJB をデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、その Web アプリケーションまたは EJB を削除してから再デプロイする必要があります。
Administration Console を使用してのアプリケーションのデプロイ、セキュリティ モデルの選択、ロールやポリシーの変更、および他の関連タスクの実行については、Administration Console オンライン ヘルプの「Web アプリケーションおよび EJB のセキュリティの管理」を参照してください。
デプロイメント記述子を使用して Web アプリケーションまたは EJB リソースを保護する場合は、『WebLogic Security プログラマーズ ガイド』の「Web アプリケーションでの宣言によるセキュリティの使用」または「EJB での宣言によるセキュリティの使用」を参照してください。
  
|