43 クロス・ドメイン・セキュリティの構成

この章では、WebLogicドメインのためのセキュリティ構成オプションの設定方法について、特にクロス・ドメイン・セキュリティを中心に説明します。

この章の内容は以下のとおりです。

• クロス・ドメイン・セキュリティのサポートに関する重要な情報

• WebLogic Serverドメイン間の信頼関係の有効化

• Java Authorization Contract for Containersの使用

• MBean属性の表示

• JAAS認可を使用するドメインの構成

注意: これらの節は、このリリースのWebLogic Serverのセキュリティ機能を使用するWebLogic Serverデプロイメントに適用されます。

クロス・ドメイン・セキュリティのサポートに関する重要な情報

この項では、クロス・ドメイン・セキュリティ・ソリューションのサポートに関する重要な情報について説明します。

このリリースのWebLogic Serverでは、JMS、JTA、MDB、WANレプリケーションなどのサブシステムでクロス・ドメイン・セキュリティを実装しています。これらのシステムはドメイン間で必要な資格証明の認証や送信を行うことができます。ただし、EJBコンテナはクロス・ドメイン・セキュリティのソリューションを実装していません。

WebLogic Serverドメイン間の信頼関係の有効化

WebLogic Serverでは、「クロス・ドメイン・セキュリティ」というドメイン信頼もサポートされています。クロス・ドメイン・セキュリティでは2つのドメイン間(ドメイン・ペア)の信頼関係が確立されて、一方のWebLogic Serverドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できるようになります。WebLogic Serverは、クロス・ドメイン・ユーザーのセキュリティ・ロールを確立し、各ドメインのWebLogic資格証明マッピング・セキュリティ・プロバイダを使用してクロス・ドメイン・ユーザーが使用する資格証明を格納します。

以前のリリースのWebLogic Serverでサポートされていたドメイン信頼は、現在は「グローバル信頼」と呼ばれます。グローバル信頼は、各ドメインで同じドメイン資格証明を使用することにより、複数のドメイン間で確立されます。2つ以上のドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメインAがドメインBを信頼し、ドメインBがドメインCを信頼する場合、次のようになります。

• ドメインAもドメインCを信頼します。

• ドメインBとドメインCの両方がドメインAを信頼します。

2つの方法の主な違いは、クロス・ドメイン・セキュリティでは特定の資格証明を使用して2つのドメイン間の信頼を有効にすることです。これに対して、グローバル信頼では、すべてのドメインと通信するために同じ資格証明が使用されます。

ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、クロス・ドメイン・セキュリティを使用する方法です。これは、クロス・ドメイン・アクション専用のユーザー・グループとロールを使用する後者のほうが、セキュリティをより細かく設定できるためです。

注意: クロス・ドメイン・セキュリティが2つのドメイン間で通信できるようにする場合、それらのドメインのグローバル信頼を有効にしないでください。 クロス・ドメイン・セキュリティのほうが、2つのドメイン間の通信の安全性が高まります。

次の項では、各ドメイン信頼の種類を構成する方法を説明します。

• WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化

• グローバル信頼の有効化

WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化

注意: クロス・ドメイン・セキュリティを有効にする前に、「クロス・ドメイン・セキュリティのサポートに関する重要な情報」を参照してください。

クロス・ドメイン・セキュリティの構成および使用方法を、次の項で説明します。

• クロス・ドメイン・セキュリティの構成

• クロス・ドメイン・セキュリティからのドメインの除外

• クロス・ドメイン・ユーザーの構成

• クロス・ドメイン・セキュリティ用の資格証明マッピングの構成

クロス・ドメイン・セキュリティの構成

2つのドメイン間(ドメイン・ペア)にクロス・ドメイン・セキュリティを構成すると、一方のWebLogic Serverドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できるようになります。複数のドメイン・ペアに対してクロス・ドメイン・セキュリティを有効化できます。

たとえば、Domain1からDomain4の4つのドメインがあるとします。4つすべてのドメインでクロス・ドメイン・セキュリティを有効化し、次のドメイン・ペアについてユーザーと資格証明のマップを追加できます(この後の項で説明します)。

• Domain1 - Domain2

• Domain1 - Domain3

• Domain1 - Domain4

• Domain2 - Domain3

• Domain2 - Domain4

• Domain3 - Domain4

WebLogicドメインでクロス・ドメイン・セキュリティを構成するには、SecurityConfigurationMBean.CrossDomainSecurityEnabled属性をtrueに設定します。この操作は、WebLogic Server管理コンソールで行います。

1. 管理コンソールの左ペインで、「ドメイン構造」の下にあるドメイン名を選択します。

2. 「セキュリティ」を選択します。

3. 「クロス・ドメイン・セキュリティの有効化」を選択します。

クロス・ドメイン・セキュリティからのドメインの除外

管理するドメインのすべてではなく一部でクロス・ドメイン・セキュリティを有効にする場合、クロス・ドメイン・セキュリティを有効にしないドメインの名前を、SecurityConfigurationMBean.ExcludedDomainNames属性の除外ドメインのリストに追加する必要があります。

これは、クロス・ドメイン・セキュリティを有効化したWebLogicドメインそれぞれで行う必要があります。

たとえば、4つのドメイン(Domain1からDomain4)があり、なんらかの理由からDomain4ではクロス・ドメイン・セキュリティを有効にしない場合、Domain1、Domain2およびDomain3のSecurityConfigurationMBean.ExcludedDomainNames属性にDomain4を指定する必要があります。

WebLogic Server管理コンソールを使用してこれを行うには、次の手順を実行します。

1. 管理コンソールの左ペインで、「ドメイン構造」の下にあるドメイン名を選択します。

2. 「セキュリティ」を選択します。

3. 「除外するドメイン名」フィールドに、クロス・ドメイン・セキュリティを有効にしないドメインの名前をすべて入力します。複数のドメイン名を入力する場合は、セミコロンで区切るか、改行を挿入します。

4. 該当するドメインで手順1から3を繰り返します。

クロス・ドメイン・ユーザーの構成

WebLogic Serverのクロス・ドメイン・セキュリティでは、CrossDomainConnectorというグローバル・セキュリティ・ロール(リソース・タイプはremote)と、CrossDomainConnectorsというグループを使用します。リモート・ドメインからの呼出しリクエストは、CrossDomainConnectorロールにマップされているユーザーから実行する必要があります。

デフォルトでは、CrossDomainConnectorsグループにユーザーは登録されていません。

クロス・ドメイン・セキュリティを有効にするドメインごとにユーザーを作成し、そのユーザーをCrossDomainConnectorsグループに追加する必要があります。このようなユーザーとしては、通常は仮想的なシステム・ユーザーを使用し、できればCrossDomainConnectorセキュリティ・ロールによって付与される権限のみを付与するようにしてください。

たとえば、Domain1、Domain2、Domain3およびDomain4でクロス・ドメイン・セキュリティを有効にしたとします。各ケースで、パスワードを含むユーザー・アカウントを作成し、それをCrossDomainConnectorsグループに割り当てます。

• Domain1でユーザーUser1を作成します。

• Domain2でUser2を作成します。

• Domain3でUser3を作成します。

• Domain4でUser4を作成します。

WebLogic Server管理コンソールでユーザーを追加するには、次の手順を実行します。

1. コンソールの左ペインの「ドメイン構造」で、「セキュリティ・レルム」を選択します。

2. セキュリティ・レルムの名前を選択します。

3. 「ユーザーとグループ」ページを選択します。

4. 「新規」をクリックします。

5. ユーザーの名前とパスワードを入力します。デフォルトの認証プロバイダを受け入れることができます。

6. 「OK」をクリックします。

7. 作成したばかりのユーザーをユーザー・リストから選択します。

8. 「グループ」ページを選択します。

9. 使用可能なグループのリストからCrossDomainConnectorsを選択し、「選択済み」リストに移動します。

10. 「保存」をクリックします。

クロス・ドメイン・セキュリティ用の資格証明マッピングの構成

注意: 資格証明マッパーは、ドメインをその名前で識別します。したがって、信頼関係に関与する各ドメインに一意の名前を付けることが重要です。

クロス・ドメイン・セキュリティを有効にしたドメイン・ペアで、信頼されるリモート・ドメインで各ユーザーによって使用される資格証明を指定する必要があります。そのためには、接続するドメイン・ペアごとに資格証明マッピングを構成します。各資格証明マッピングでは、次を指定する必要があります。

• リソース・プロトコル(cross-domain-protocol)

• ローカル・ドメインと対話する必要のあるリモート・ドメインの名前

• ローカル・ドメインとの対話を認可されたリモート・ドメインのユーザーの名前

• ローカル・ドメインとの対話を認可されたリモート・ドメインのユーザーのパスワード

たとえば、「クロス・ドメイン・ユーザーの構成」のユーザーの例を使用した場合は、次のようにドメイン・ペアを構成します。

注意: 構成するドメインが複数ある場合は、1つのドメイン・ペアを構成してから次のペアを構成することをお薦めします。

• リモート・ドメイン: Domain2、リモート・ユーザー: User2、リモート・ユーザー・パス: password-for-User2をDomain1の資格証明マップに移入します。

  リモート・ドメイン: Domain1、リモート・ユーザー: User1、リモート・ユーザー・パス: password-for-User1をDomain2の資格証明マップに移入します。

• リモート・ドメイン: Domain3、リモート・ユーザー: User3、リモート・ユーザー・パス: password-for-User3をDomain1の資格証明マップに移入します。

  リモート・ドメイン: Domain1、リモート・ユーザー: User1、リモート・ユーザー・パス: password-for-User1をDomain3の資格証明マップに移入します。

• リモート・ドメイン: Domain4、リモート・ユーザー: User4、リモート・ユーザー・パス: password-for-User4をDomain1の資格証明マップに移入します。

  リモート・ドメイン: Domain1、リモート・ユーザー: User1、リモート・ユーザー・パス: password-for-User1をDomain4の資格証明マップに移入します。

• リモート・ドメイン: Domain3、リモート・ユーザー: User3、リモート・ユーザー・パス: password-for-User3をDomain2の資格証明マップに移入します。

  リモート・ドメイン: Domain2、リモート・ユーザー: User2、リモート・ユーザー・パス: password-for-User2をDomain3の資格証明マップに移入します。

• リモート・ドメイン: Domain4、リモート・ユーザー: User4、リモート・ユーザー・パス: password-for-User4をDomain2の資格証明マップに移入します。

  リモート・ドメイン: Domain2、リモート・ユーザー: User2、リモート・ユーザー・パス: password-for-User2をDomain4の資格証明マップに移入します。

• リモート・ドメイン: Domain4、リモート・ユーザー: User4、リモート・ユーザー・パス: password-for-User4をDomain3の資格証明マップに移入します。

  リモート・ドメイン: Domain3、リモート・ユーザー: User3、リモート・ユーザー・パス: password-for-User3をDomain4の資格証明マップに移入します。

クロス・ドメイン・セキュリティ用の資格証明マッピングを構成するには、WebLogic Server管理コンソールの左パネルで「セキュリティ・レルム」をクリックします。

1. セキュリティ・レルムの名前をクリックします(デフォルトはmyrealm)。

2. 「資格証明マッピング」→「デフォルト」を選択して、「新規」をクリックします。

3. 「セキュリティ資格証明マッピングのリモート・リソースを作成」ページで次の操作を行います。

   • 「クロスドメイン・プロトコルの使用」を選択します。

   • 「リモート・ドメイン」フィールドに、ローカル・ドメインと対話する必要のあるリモート・ドメインの名前を入力します。

4. 「次へ」をクリックします。

5. 「新しいセキュリティ資格証明マップ・エントリの作成」ページで次の内容を入力します。

   • ローカル・ユーザー: cross-domain

   • リモート・ユーザー: ローカル・ドメインとの対話を認可されたリモート・ドメインに構成されているユーザー。

   • パスワード: リモート・ユーザーのパスワード。

6. 「終了」をクリックします。

7. 必要に応じて手順1から6を繰り返します。

このタスクの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「クロス・ドメイン・セキュリティの資格証明マッピングの作成」を参照してください。

グローバル信頼の有効化

警告: WebLogicドメイン間のグローバル信頼を有効にすると、サーバーは中間者攻撃に対して無防備な状態になる可能性があります。本番環境で信頼関係を有効にする場合、十分に注意を払う必要があります。専用の通信チャネルなどの強力なネットワーク・セキュリティや、強力なファイアウォールによる保護の実施をお薦めします。 ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、「WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化」で説明した資格証明マッパーを使用する方法です。これは、後者のほうがセキュリティをより細かく制御できるためです。

WebLogic Serverでは、2つ以上のドメインの間にグローバル信頼を確立できます。そのためには、それぞれのドメインに同じドメイン資格証明を指定します。デフォルトでは、ドメインの資格証明はランダムに生成されるため、2つのドメインが同じドメインの資格証明を持つことはありません。

2つのWebLogicドメインを相互運用する場合は、生成された資格証明を選択した資格証明で置き換えて、同じ資格証明をそれぞれのドメインで設定する必要があります。構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン間のグローバル信頼の有効化に関する項を参照してください。

2つのドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、Domain AがDomain Bを信頼し、Domain BがDomain Cを信頼する場合には、Domain AもDomain Cを信頼し、Domain BとDomain Cの両方がDomain Aを信頼する関係です。

ドメイン間のグローバル信頼が確立されると、一方のWebLogicドメインのサブジェクト内のプリンシパルがもう一方のドメインのプリンシパルとして受け付けられます。この機能が有効になっている場合、IDはWebLogicドメイン間でRMI接続を介して渡されます(2番目のドメインでの認証は不要)。(たとえば、Domain 1にJoeとしてログインします。Domain 2へのRMI呼出しを行います。Joeは認証されています)。WebLogic Serverは、プリンシパルの作成時にドメイン資格証明でプリンシパルに署名します。サブジェクトがリモート・ソースから受信されると、プリンシパルが検証されます。(署名が再作成され、一致する場合、リモート・ドメインは同じドメイン資格証明を持ちます)。検証が失敗すると、エラーが生成されます。検証が成功すると、そのプリンシパルはローカルで作成されたかのように信頼されます。

注意: クリア・テキスト形式の資格証明は、次にconfig.xmlファイルがディスクに保存されるときに暗号化されます。

管理対象サーバー環境でドメイン間のグローバル信頼を有効にする場合は、両方のドメインの管理サーバーとすべての管理対象サーバーを停止してから、再起動する必要があります。この手順を行わないと、再起動されなかったサーバーでは、再起動されたサーバーが信頼されなくなります。

WebLogicドメイン間のグローバル信頼を有効化するときには、次の点に注意してください。

• ドメインは認証を必要とせずにリモート・プリンシパルを信頼するので、ドメインの認証データベースに定義されていない、認証済ユーザーがドメイン内に存在できることになります。この状況により、認可の問題が発生するおそれがあります。

• ドメイン内の認証済みユーザーは、元のドメインとの信頼関係が有効化されている他のドメインに再認証なしでアクセスできます。こうしたログインに対する監査はなく、グループ・メンバーシップは検証されません。そのため、Joeが、認証された元のドメインのAdministratorsグループのメンバーである場合、Joeは自動的にRMI呼出しの対象となるすべての信頼されたドメインのAdministratorsグループのメンバーになります。

• Domain 1がDomain 1とDomain 3の両方を信頼している場合、Domain 1とDomain 3は暗黙的にお互いを信頼するようになっています。そのため、Domain 1のAdministratorsグループのメンバーは、Domain 3のAdministratorsグループのメンバーになります。こうした信頼関係は、本来目的とする信頼関係ではない場合もあります。

• WLSUser PrincipalクラスおよびWLSGroup Principalクラスを拡張した場合、カスタムPrincipalクラスは、信頼を共有するすべてのドメインのサーバーのCLASSPATHにインストールされる必要があります。

これらの問題を回避するため、2つのドメイン間でグローバル信頼を有効にする方法ではなく、「WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化」で説明する方法をお薦めします。

Java Authorization Contract for Containersの使用

バージョン12.2.1のWebLogic Serverでは、JACC (Java Authorization Contract for Containers)標準のバージョン1.5をサポートしています。JACC標準は、WebLogic Serverが提供するEJBおよびサーブレット・コンテナのデプロイメントおよび認可のかわりに使用できます。WebLogicドメインでJACCを使用するように構成すると、EJBおよびサーブレット認可の決定は、JACCフレームワーク内のクラスによって行われます。WebLogic Server内における他の認可決定はすべて、引き続きWebLogicセキュリティ・フレームワークによって行われます。WebLogic JACCプロバイダの詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJava Authorization Contract for Containersの使用に関する項を参照してください。

WebLogic Serverを起動するコマンドに次のプロパティを指定して、WebLogic ServerがJACCを使用するように構成します。

-Djavax.security.jacc.PolicyConfigurationFactory.provider
-Djavax.security.jacc.policy.provider
-Dweblogic.security.jacc.RoleMapperFactory.provider

これらのプロパティの指定の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のWebLogic JACCプロバイダの有効化に関する項を参照してください。

ドメインの管理サーバーと管理対象サーバーは、同じJACC構成を持つ必要があります。管理サーバーのJACC設定を変更した場合、セキュリティの低下を防ぐため、管理対象サーバーを再起動して管理サーバーと同じ設定を適用します。そうしないと、管理対象サーバーは実際にはJACCの下で動作しているのに、ドメイン内のEJBとサーブレットがWebLogicセキュリティ・フレームワークのロールとポリシーによって保護されているように見える場合があります。

MBean属性の表示

「匿名Adminのルックアップを有効化」オプションでは、MBean APIからのWebLogic Server MBeanに対する読取り専用の匿名アクセスを許可するかどうかを指定します。この匿名アクセスを使用すると、WebLogic Server MBean認可プロセスによる保護が明示的に示されていない任意のMBean属性の値を参照できます。このオプションは後方互換性を確実にするために、デフォルトで有効になっています。セキュリティを高めるには、この匿名アクセスを無効にします。

WebLogic Server管理コンソールで「匿名Adminのルックアップを有効化」オプションの設定を検証するには、「ドメイン」→「セキュリティ」→「全般」を選択するか、SecurityConfigurationMBean.AnonymousAdminLookupEnabled属性を表示します。

JAAS認可を使用するドメインの構成

WebLogicドメインのセキュリティ構成は、JAAS認可を使用するように変更できます。JAAS認可は、WebLogicセキュリティ・サービスとは異なる方法でサブジェクトを解釈します。たとえば、OPSS (Oracle Platform Security Services)でJavaポリシー・プロバイダによって保護されるリソースへのアクセスをプリンシパルがリクエストする場合、プリンシパルは、ポリシー・ストアに含まれる名前で構築される別のプリンシパルと比較されます。(この比較は、Principal.equals()メソッドが呼び出されると行われます。)2つのプリンシパル・オブジェクトの適切な属性が一致する場合、アクセスは許可されます。

保護されたリソースへのアクセス決定を判断する場合、WebLogicセキュリティ・サービスでプリンシパルの比較は使用されません。ただし、デフォルトのWebLogicドメインでプリンシパルの比較が行われる場合、プリンシパル名の比較では大文字/小文字が区別され、プリンシパル名のみが比較されます。JAAS認可を使用するには、次のプリンシパル比較動作に適応するようにWebLogicドメインのセキュリティ構成を変更できます。

• プリンシパル名の比較では大文字/小文字は区別されません。

• WebLogicプリンシパル・オブジェクトのGUIDとDNのデータは比較に含まれます。

プリンシパル・オブジェクトをJAAS認可で使用するようにWebLogicドメインのセキュリティ構成を変更するには、次のMBean属性の設定を使用できます。

SecurityConfigurationMBean.PrincipalEqualsCaseInsensitive="true"
SecurityConfigurationMBean.PrincipalEqualsCompareDnAndGuid="true"

これらの属性を設定するには、WebLogic Server管理コンソールで次の操作を行います。

1. 管理コンソールの左ペインで、「ドメイン構造」の下にあるドメイン名を選択します。

2. 「構成」→「セキュリティ」を選択して、「詳細」をクリックします。

3. 次の各エントリの横にあるチェック・ボックスを選択します。

   • Principal Equalsの大文字/小文字を区別しない

   • Principal EqualsでDNとGUIDを比較

注意: プリンシパルでGUIDとDNのデータを使用するようにドメインが構成される場合、他のWebLogicドメイン(特に古いドメイン)との相互運用に影響があります。これは、IDエンティティを渡す方法が変更されることで生じます。

Oracle Platform Security Serviceのプリンシパルの比較の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のプリンシパル名の比較ロジックに関する項を参照してください。WebLogicドメインにIDを渡す場合の詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントの開発』を参照してください。