43 クロス・ドメイン・セキュリティの構成
これらの節は、このリリースのWebLogic Serverのセキュリティ機能を使用するWebLogic Serverデプロイメントに適用されます。
ノート:
このリリースのWebLogic Serverでは、JMS、JTA、MDB、WANレプリケーションなどのサブシステムでクロス・ドメイン・セキュリティを実装しています。これらのシステムはドメイン間で必要な資格証明の認証や送信を行うことができます。ただし、EJBコンテナはクロス・ドメイン・セキュリティのソリューションを実装していません。WebLogic Serverドメイン間の信頼関係の有効化
WebLogic Serverでは、一方のWebLogicドメインのサブジェクト内のプリンシパルがもう一方のドメイン内で呼出しを実行できるように、2つのドメイン間の信頼を確立するクロス・ドメイン・セキュリティがサポートされています。WebLogic Serverは、クロス・ドメイン・ユーザーのセキュリティ・ロールを確立し、各ドメインのWebLogic資格証明マッピング・セキュリティ・プロバイダを使用してクロス・ドメイン・ユーザーが使用する資格証明を格納します。
以前のリリースのWebLogic Serverでサポートされていたドメイン信頼は、現在は「グローバル信頼」と呼ばれます。グローバル信頼は、各ドメインで同じドメイン資格証明を使用することにより、複数のドメイン間で確立されます。2つ以上のドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメインAがドメインBを信頼し、ドメインBがドメインCを信頼する場合、次のようになります。
-
ドメインAもドメインCを信頼します。
-
ドメインBとドメインCの両方がドメインAを信頼します。
2つの方法の主な違いは、クロス・ドメイン・セキュリティでは特定の資格証明を使用して2つのドメイン間の信頼を有効にすることです。これに対して、グローバル信頼では、すべてのドメインと通信するために同じ資格証明が使用されます。
ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、クロス・ドメイン・セキュリティを使用する方法です。これは、クロス・ドメイン・アクション専用のユーザー・グループとロールを使用する後者のほうが、セキュリティをより細かく設定できるためです。
ノート:
クロス・ドメイン・セキュリティが2つのドメイン間で通信できるようにする場合、それらのドメインのグローバル信頼を有効にしないでください。
クロス・ドメイン・セキュリティのほうが、2つのドメイン間の通信の安全性が高まります。
次の項では、各ドメイン信頼の種類を構成する方法を説明します。
WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化
ノート:
このリリースのWebLogic Serverでは、JMS、JTA、MDB、WANレプリケーションなどのサブシステムでクロス・ドメイン・セキュリティを実装しています。これらのシステムはドメイン間で必要な資格証明の認証や送信を行うことができます。ただし、EJBコンテナはクロス・ドメイン・セキュリティのソリューションを実装していません。
クロス・ドメイン・セキュリティの構成および使用方法については、次の項を参照してください。
クロス・ドメイン・セキュリティの構成
2つのドメイン間(ドメイン・ペア)にクロス・ドメイン・セキュリティを構成すると、一方のWebLogicドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できるようになります。複数のドメイン・ペアに対してクロス・ドメイン・セキュリティを有効化できます。
たとえば、Domain1
からDomain4
の4つのドメインがあるとします。4つすべてのドメインでクロス・ドメイン・セキュリティを有効化し、次のドメイン・ペアについてユーザーと資格証明のマップを追加できます(この後の項で説明します):
-
Domain1
-Domain2
-
Domain1
-Domain3
-
Domain1
-Domain4
-
Domain2
-Domain3
-
Domain2
-Domain4
-
Domain3
-Domain4
WebLogicドメインでクロス・ドメイン・セキュリティを構成するには、SecurityConfigurationMBean.CrossDomainSecurityEnabled
属性をtrue
に設定します。WebLogic Server管理コンソールでこの操作をするには:
- 管理コンソールの左ペインで、「ドメイン構造」の下にあるドメイン名を選択します。
- 「セキュリティ」を選択します。
- 「クロス・ドメイン・セキュリティの有効化」を選択します。
クロス・ドメイン・セキュリティからのドメインの除外
管理するドメインのすべてではなく一部でクロス・ドメイン・セキュリティを有効にする場合、クロス・ドメイン・セキュリティを有効にしないドメインの名前を、SecurityConfigurationMBean.ExcludedDomainNames
属性の除外ドメインのリストに追加する必要があります。
これは、クロス・ドメイン・セキュリティを有効化したWebLogicドメインそれぞれで行う必要があります。
たとえば、4つのドメイン(Domain1
からDomain4
)があり、なんらかの理由からDomain4
ではクロス・ドメイン・セキュリティを有効にしない場合、Domain1
、Domain2
およびDomain3
のSecurityConfigurationMBean.ExcludedDomainNames
属性にDomain4
を指定する必要があります。
WebLogic Server管理コンソールを使用してこれを行うには:
- 管理コンソールの左ペインで、「ドメイン構造」の下にあるドメイン名を選択します。
- 「セキュリティ」を選択します。
- 「除外するドメイン名」フィールドに、クロス・ドメイン・セキュリティを有効にしないドメインの名前をすべて入力します。複数のドメイン名を入力する場合は、セミコロンで区切るか、改行を挿入します。
- 該当するドメインでステップ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管理コンソールでユーザーを追加するには:
- コンソールの左ペインの「ドメイン構造」で、「セキュリティ・レルム」を選択します。
- セキュリティ・レルムの名前を選択します。
- 「ユーザーとグループ」ページを選択します。
- 「新規」をクリックします。
- ユーザーの名前とパスワードを入力します。デフォルトの認証プロバイダを受け入れることができます。
- 「OK」をクリックします。
- 作成したばかりのユーザーをユーザー・リストから選択します。
- 「グループ」ページを選択します。
- 使用可能なグループのリストから
CrossDomainConnectors
を選択し、「選択済み」リストに移動します。 - 「保存」をクリックします。
クロス・ドメイン・セキュリティ用の資格証明マッピングの構成
ノート:
資格証明マッパーは、ドメインをその名前で識別します。したがって、信頼関係に関与する各ドメインに一意の名前を付けることが重要です。
クロス・ドメイン・セキュリティを有効にしたドメイン・ペアで、信頼されるリモート・ドメインで各ユーザーによって使用される資格証明を指定する必要があります。そのためには、接続するドメイン・ペアごとに資格証明マッピングを構成します。各資格証明マッピングでは、次を指定する必要があります。
-
リソース・プロトコル(
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管理コンソールの左パネルで「セキュリティ・レルム」をクリックします。
このタスクの詳細は、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およびサーブレット・コンテナのデプロイメントおよび認可のかわりに使用できます。コマンドライン・ユーティリティを使用してJACCを使用するようにWebLogic Serverを構成します。
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属性の表示
SecurityConfigurationMBean.AnonymousAdminLookupEnabled
属性を使用して、MBean APIからのWebLogic Server 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管理コンソールでこれらの属性を設定するには:
ノート:
プリンシパルでGUIDとDNのデータを使用するようにドメインが構成される場合、他のWebLogicドメイン(特に古いドメイン)との相互運用に影響があります。これは、IDエンティティを渡す方法が変更されることで生じます。
Oracle Platform Security Serviceのプリンシパルの比較の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のプリンシパル名の比較ロジックに関する項を参照してください。WebLogicドメインにアイデンティティを渡す場合の詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントの開発』を参照してください。