| Oracle Fusion Middlewareセキュリティ・ガイド 11gリリース1（11.1.1） B56235-01 |
|
 戻る |
 次へ |
アプリケーションをOracle WebLogic Serverにデプロイするには、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlまたはOracle JDeveloperのいずれかのツールを使用します。
アプリケーションをデプロイするための推奨ツールは、アプリケーションのタイプと、アプリケーションが開発中フェーズと開発後フェーズのどちらのフェーズにあるかによって異なります。この章で説明する推奨事項は、Oracle ADFアプリケーションと、OPSSを使用するJavaEEアプリケーションにのみ当てはまります。
開発時には、Oracle JDeveloperを使用してアプリケーションを組込みOracle WebLogic Serverにデプロイすることが普通です。テスト環境または本番環境に移行したアプリケーションは、通常、Fusion Middleware ControlまたはOracle WebLogic Server管理コンソールを使用してデプロイします。
この章では、Oracle ADFアプリケーションまたはPure JavaEEアプリケーションのデプロイ時に実行する管理タスクを中心に説明します。最後の項では、アプリケーションを手動でパッケージ化する場合のみを対象として、セキュアJavaEEアプリケーションのパッケージ要件について説明します。
この章の内容は次のとおりです。
補足ドキュメント
デプロイの詳細は、Oracle Fusion Middlewareの管理者ガイドの第8章「アプリケーションのデプロイ」を参照してください。
開発から本番に至るまでのアプリケーションのセキュリティ・ライフサイクル全体の概要は、『Oracle Fusion Middlewareセキュリティ概要』を参照してください。
開発段階のOracle ADFアプリケーションの保護の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
開発サイクルの概要は、第14.1.1項「開発サイクル」を参照してください。
Oracle ADFアプリケーションをリモートのOracle WebLogic Serverにデプロイするまでの一般的な手順は次のとおりです。
Oracle JDeveloperを使用して開発者がOracle ADFアプリケーションを開発し、その過程でOracle ADFセキュリティ・ウィザードを使用してOracle ADFのセキュリティを設定します。
Oracle JDeveloperを使用し、テスト環境でのテスト・サイクルでアプリケーションの自動デプロイ先となる統合WebLogic Serverに、アプリケーションのユーザーとグループ、認可ポリシーおよび資格証明をコピーします。
開発者が、ポリシーと資格証明をパッケージ化した、アプリケーションのEARファイルを作成します。
Fusion Middleware Controlを使用して、ドメイン管理者がこのEARファイルをリモートのOracle WebLogic Serverにデプロイします。
このフローを図示すると次のようになります。
この章で検討するアプリケーションのタイプは、JavaEEアプリケーションです。JavaEEアプリケーションは、さらにPure JavaEEアプリケーションとOracle Fusion Middleware ADFアプリケーションに分類できます。この2種類のJavaEEアプリケーションの相違点は、第2.5.1項「シナリオ1: JavaEEアプリケーションのセキュリティの強化」および第2.5.2項「シナリオ2: Oracle ADFアプリケーションの保護」を参照してください。
表7-1は、開発したアプリケーションのデプロイに使用するツールをそのアプリケーションのタイプ別に示しています。
表7-1 開発したアプリケーションをデプロイするためのツール
| アプリケーション・タイプ | 使用するツール |
|---|---|
|
Pure JavaEEアプリケーション |
Oracle WebLogic管理コンソール、Fusion Middleware ControlまたはWLSTコマンド。推奨ツールはOracle WebLogic管理コンソールです。 |
|
Oracle ADFアプリケーション |
Fusion Middleware ControlまたはWLSTコマンド。推奨ツールはFusion Middleware Controlです。 |
この項では、Oracle ADFのセキュリティを使用するアプリケーションまたはOPSSを使用するJavaEEアプリケーションを、Fusion Middleware Controlを使用してデプロイする際に使用できるセキュリティ構成について説明します。具体的には、デプロイ設定の第3段階である「アプリケーション・セキュリティの構成」ページのオプションを中心とした説明です。
このページの外観は、EARファイルのパッケージ内容に応じて次のようになります。
アプリケーション・ポリシーを設定したjazn-data.xmlをEARファイルにパッケージ化している場合は、アプリケーション・ポリシーの移行セクションが表示されます。
cwallet.ssoに収めた資格証明をEARファイルにパッケージ化している場合は、資格証明の移行セクションが表示されます。
前述のいずれもEARファイルにパッケージ化していない場合、このページにはデフォルトのJava EEセキュリティ・オプションが表示されます。
このページには、ポリシーと資格証明の両方の移行セクションが表示されます。その一部を次に示します。
このページの設定は、該当のドメイン・ストアへのアプリケーション・ポリシーと資格証明（アプリケーションEARファイルにパッケージ化される）の移行に関連するものです。次では、これらの設定について説明します。
「アプリケーション・ポリシー移行」の設定
これらの設定では、次のシナリオでポリシーの移行を制御できます。
アプリケーションを初めてデプロイする場合、通常はドメイン・ポリシー・ストアにアプリケーション・ポリシーを移行します。そのためには、「アプリケーション・ポリシー移行」領域で「追加」を選択します。
なんらかの理由で移行しない場合は「無視」を選択します。
アプリケーションがすでにデプロイ済で、現在のデプロイ以前に移行したアプリケーション・ポリシーが存在する場合、パッケージ化したポリシーをドメイン内の既存のポリシーにマージするには「追加」を選択し、移行せずに現在のアプリケーション・ドメイン・ポリシーを保持するには「無視」を選択します。
いずれの場合も、「追加」を選択したときは、「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」チェック・ボックスを選択すると、エンタープライズ・グループやエンタープライズ・ユーザーを参照しないアプリケーション・ロールと権限のみを移行できます。このチェック・ボックスを選択すると、アプリケーションで完全には記述されていないポリシー、つまりパッケージ化したポリシーで定義していないエンタープライズ・ユーザーまたはグループを参照しているポリシーは移行されません。
|
注意: 「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」チェック・ボックスで、エンタープライズ・ユーザーおよびグループに対するアプリケーション・ロールのマッピングの動作を制御できます。通常、本番環境へのデプロイ時には、このチェック・ボックスの選択を解除します。 |
いずれの場合も、「追加」を選択したときに、アプリケーション・ポリシーの移行先とする特定のストライプ（アプリケーション名を名前としたデフォルトのストライプとは異なるストライプ）を指定するには、「アプリケーションID」ボックスにそのストライプの名前を入力します。
|
注意: ドメイン・ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイルsystem-jazn-data.xmlのapplications要素で指定したアプリケーション名ごとにストライプが1つずつあります。各ストライプで、特定のアプリケーションに関するドメイン・ポリシーのサブセットを特定します。 |
「アプリケーション資格証明移行」の設定
これらの設定では、次のシナリオで資格証明の移行を制御できます。
アプリケーションを初めてデプロイする場合、通常はドメイン資格証明ストアにアプリケーション資格証明を移行します。そのためには、「アプリケーション資格証明移行」領域で「追加」を選択します。
いずれの場合も（初めてのデプロイでもその後のデプロイでも）、なんらかの理由で移行しない場合は「無視」を選択します。
|
注意: 資格証明の移行を無視すると、資格証明を使用するアプリケーション・コードが動作しない場合があります。通常は、マップとキーが同じで値が異なる資格証明を手動で作成するという前提の下で「無視」オプションを選択します。 |
Oracle ADFアプリケーションはJAAS認可を使用するJavaEEアプリケーションで、通常はOracle JDeveloperを使用して開発し、テストします。この環境により、開発者はアプリケーションをパッケージ化し、このOracle JDeveloperと統合した組込みOracle WebLogic Serverにデプロイできます。テスト環境または本番環境にアプリケーションを移行するとき、デプロイにはOracle Fusion Middleware Controlを使用し、そのフレームワークで提供されるOracle ADFのセキュリティ機能すべてを活用します。詳細は、「概要」を参照してください。
Fusion Middleware Controlを使用してOracle ADFアプリケーションをデプロイする方法の具体的な手順は、次の項を参照してください。
Oracle Fusion Middleware Controlのオンライン・ヘルプ・システムのFusion Middleware Controlを使用したアプリケーションのデプロイに関する項
Oracle Fusion Middlewareの管理者ガイドの第8.4項のOracle ADFアプリケーションのデプロイとアンデプロイに関する項
この項の内容は次のとおりです。
デプロイ時に使用できるセキュリティ・オプションは、「Fusion Middleware Controlを使用したJavaEEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。
Fusion Middleware Controlを使用してOracle ADFアプリケーションをテスト環境にデプロイするときには次の手順が発生します。
ポリシー管理
アプリケーションとパッケージ化されたアプリケーション固有のポリシーは、アプリケーションがデプロイされるときにドメイン資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。
資格証明管理
アプリケーションとパッケージ化されたアプリケーション固有の資格証明は、アプリケーションがデプロイされるときにドメイン資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。
移行中にLDAPリポジトリにアクセスするために必要なブートストラップ資格証明は、Fusion Middleware Controlによって自動的に生成されます。手動設定の詳細は、第15.4.7項「ブートストラップ資格証明の手動による指定」を参照してください。
アイデンティティ管理
アプリケーションとパッケージ化されたアイデンティティは移行されません。ドメイン管理者はドメイン認証プロバイダを構成し（管理コンソールを使用）、必要に応じて、環境にあるアイデンティティ（エンタープライズ・ユーザーおよびグループ）を更新して、エンタープライズ・ユーザーおよびグループにアプリケーション・ロールをマップする（Fusion Middleware Controlを使用）必要があります。
その他の考慮事項
LDAPベースのセキュリティ・ストアを持つドメインにデプロイする場合は、アプリケーションのデータの整合性を保持するために、アプリケーションをクラスタ・レベルでデプロイするか、1つの管理対象サーバーにのみデプロイすることをお薦めします。
アプリケーションを複数の管理対象サーバーにデプロイするときは、管理サーバーを含めてデータが予期したとおりに移行されるようにしてください。
ドメイン・ストアの再関連付けは頻繁に行う操作ではなく、通常は、アプリケーションをデプロイする前のドメインを設定するときに行います。手順の詳細は、第8.2.1項「Fusion Middleware Controlを使用したドメイン・ストアの再関連付け」を参照してください。
テスト環境へのアプリケーションのデプロイ後、管理者はFusion Middleware Controlまたは管理コンソールを使用していつでも次のタスクを実行できます。
エンタープライズ・グループへのアプリケーション・ロールのマップ。このマッピングが完了するまで、セキュリティは予期したとおりに動作しません。手順の詳細は、第8.4.1.1項「アプリケーション・ポリシーの管理」を参照してください。
新しいアプリケーション・ロールの作成または既存のアプリケーション・ロールのカスタマイズ。詳細は、第8.4.1.2項「アプリケーション・ロールの管理」を参照してください。
システム・ポリシーの管理。手順の詳細は、第8.4.1.3項「システム・ポリシーの管理」を参照してください。
資格証明の管理手順の詳細は、第9.5.1項「Fusion Middleware Controlを使用した資格証明の管理」を参照してください。
|
注意: Fusion Middleware Controlを使用して、本番モードで実行しているサーバーからアプリケーションをアンデプロイすると、そのアプリケーション固有のポリシーがドメイン・ポリシー・ストアから自動的に削除されます。また、他のツールを使用してアプリケーションをアンデプロイする場合は、そのアプリケーション固有のポリシーを手動で削除する必要があります。資格証明は、アプリケーションをアンデプロイしても削除できません。資格証明は、アプリケーションとパッケージ化することで有効になりますが、アプリケーションをアンデプロイしても資格証明は削除されません。 |
OPSSを使用せずにJavaの標準認可を使用するJavaEEアプリケーションを保護するには、管理コンソールまたはWLSTスクリプト（コマンドラインまたはスクリプト・モード）を使用して管理面で保護する方法と、デプロイメント・ディスクリプタを使用してプログラムで保護する方法の2通りがあります。
Oracle WebLogic ServerにデプロイしたJavaEEアプリケーションは、WebLogicリソースとなります。したがって、管理者は、他のリソースの場合と同じ方法で、デプロイされたアプリケーションにセキュリティを設定できます。
デプロイ手順の詳細は、Oracle Fusion Middlewareの管理者ガイドのJavaEEアプリケーションのデプロイとアンデプロイに関する第8.3項を参照してください。
WLSTコマンドを使用したアプリケーションのデプロイの詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool Command Reference』のデプロイメント・コマンドに関する項を参照してください。
WebLogic Serverのデプロイメント機能の概要は、『Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server』のWebLogic Serverのデプロイメントに関する項を参照してください。
関連ドキュメント
アプリケーション・リソースの保護の詳細は、次のドキュメントに記載されています。
『Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server』
アプリケーションのリソースに関する項
WebアプリケーションおよびEJBリソースの保護のオプションに関する項
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプ
ロールとポリシーの使用したリソースの保護に関する項
『Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server』
Webサービス・セキュリティの概要に関する項
『Oracle Fusion Middleware Programming Security for Oracle WebLogic Server』
Webアプリケーションの保護に関する項（特に、Webアプリケーションでの宣言セキュリティの使用に関する項）
Enterprise JavaBeans（EJBs）の保護に関する項
Javaセキュリティを使用したWebLogicリソースの保護に関する項
次の推奨事項は、JAAS認可を使用するJavaEEアプリケーションにのみ当てはまります。このようなアプリケーションには、Oracle Application Development Frameworkアプリケーション、Oracle SOAアプリケーション、Oracle WebCenterアプリケーションなどがあります。標準認可を使用するJavaEEアプリケーションは、この推奨事項の対象外です。標準認可を使用するJavaEEアプリケーションのデプロイは、「標準JavaEEアプリケーションのデプロイ」を参照してください。
アプリケーションをデプロイするための推奨ツールはFusion Middleware Controlです。後述の項で説明する操作を実行するユーザーは、LDAPリポジトリでスキーマをシードする権限など、適切な権限を持っている必要があります。
第6.2.1項「新しい本番環境の設定」の説明に従って本番環境が設定されていることを前提とします。
新しい本番環境への移行は、ポリシー・プロバイダおよび資格証明プロバイダ以外のプロバイダの移行、ポリシー・プロバイダおよび資格証明プロバイダの移行、監査ポリシーの移行という3段階に分かれています。それぞれの段階の詳細は次の各項を参照してください。
本番環境でのプロバイダ（ポリシー・プロバイダおよび資格証明プロバイダ以外）の構成は、テスト環境で使用した構成と同じものとする必要があります。この構成として、次のものが考えられます。
ユーザーのプロビジョニングなどのアイデンティティ・ストアの構成（WebLogic管理コンソールを使用）
発行者リストのSAML構成
テスト環境で実行したあらゆる特定のプロバイダの構成
|
注意: Oracle WebLogic Serverには、packコマンドやunpackコマンドなど、ドメインの作成に役立つ様々なツールが用意されています。詳細は、『Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands』を参照してください。 |
アイデンティティ・データは、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。この移行が必要になる状況の例として、ファイルベースのアイデンティティ・ストアを使用するテスト環境からLDAPベースのアイデンティティ・ストアを使用する本番環境に移行する場合があります。
このコマンドはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
後述のコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力すると、応答が即座に表示されます。スクリプト・モードの場合、コマンドはテキスト・ファイル（ファイル名拡張子は.py）に記述されるので、シェル・スクリプトのディレクティブのように入力なしで実行できます。
|
重要: シェル内でセキュリティ関連のWLSTコマンドを起動する前に、次のサンプルで説明するように、wlst.shスクリプトを実行する必要があります。
> sh $ORACLE_HOME/common/bin/wlst.sh これにより、必要なJARがクラスパスに確実に追加されるようになります。新しいシェル内で前述のコマンドを実行しないと、WLSTコマンドが使用できない状態になります。 オンライン・コマンドを実行する前に、次のようにサーバーに接続します。
>java weblogic.WLST
>connect(' |
スクリプト・モードおよびインタラクティブ・モードの構文
アイデンティティを移行するには、次のスクリプト構文（1番目の記述）またはインタラクティブな構文（2番目の記述）を使用します（ここでは、見やすくするために各引数をそれぞれ別の行に記述しています）。
migrateSecurityStore -type idStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-dstLdifFile LdifFileLocation]
migrateSecurityStore(type="idStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [dstLdifFile="LdifFileLocation"])
引数（dstLdifFile以外はすべて必須）の意味は次のとおりです。
configFileでは、構成ファイルjps-config.xmlの位置を、このコマンドを実行するディレクトリを基準とした相対パスで指定します。
srcでは、引数configFileで渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。
dstでは、引数configFileで渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。移行先ストアには、XMLベースのストアまたはOracle Internet Directoryサーバーで支援されるLDAPベースのストアを指定できます。それ以外のストアは移行先としてサポートされていません。
dstLdifFileでは、LDIFファイルを作成する場所を指定します。移行先がLDAPベースのOracle Internet Directoryストアである場合にのみ必要です。LDIFファイルはLDAPサーバーにはインポートされません。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
LDIFファイルを生成した後、通常は、このファイルを手動で編集して、LDIFファイルの最終的なインポート先となるLDAPリポジトリの属性をカスタマイズします。
本番環境では、ポリシー・ストアおよび資格証明ストアをLDAPベースのリポジトリに再関連付けすることを強くお薦めします。テスト用のポリシー・ストアおよび資格証明ストアもLDAPであったとしても、本番用のLDAPはテスト用のLDAPとは別のものとすることが前提となっています。ストアを再関連付けする方法の詳細は、第8.2.1項「Fusion Middleware Controlを使用したドメイン・ストアの再関連付け」を参照してください。
ポリシーおよび資格証明の移行は、アプリケーションのデプロイ時に自動的に処理できるほか、アプリケーションのデプロイ前またはデプロイ後に手動で実行することもできます。
アプリケーションを本番環境にデプロイする際、管理者は次の点を把握している必要があります。
アプリケーションEARにパッケージ化したポリシーまたは資格証明がテスト環境で変更されているかどうか
この点を把握していることを前提として、アプリケーションを本番環境にデプロイする手順は次のとおりです。
Fusion Middleware Controlで次のオプションを使用して、アプリケーションのEARファイルを本番環境にデプロイします。
ポリシー（アプリケーションまたはシステム）がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション・ポリシー移行」領域で「無視」オプションを選択して、デプロイ時にポリシーを移行するオプションを無効にします。ポリシーが変更されていない場合は、「追加」を選択します。
|
注意: テスト環境でのアプリケーション・ロールの変更がテスト用のエンタープライズ・グループへのマッピングにまで及んでいても、「追加」（アプリケーション・ポリシーの移行）を選択し、同時に「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」チェック・ボックスを選択できます。この組合せを選択した場合、アプリケーション・ポリシーは移行されますが、テスト用のエンタープライズ・グループへのマッピングは無視されます。後述の手順3で、アプリケーション・ロールを本番用のエンタープライズ・グループに再マップする必要があります。 |
資格証明がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション資格証明移行」領域で「無視」オプションを選択して、デプロイ時に資格証明を移行するオプションを無効にします。資格証明が変更されていない場合は、「追加」を選択します。
次の説明に従い、コマンドmigrateSecurityStoreを使用して、変更済のデータを移行します。
アプリケーション・ポリシーの移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPにアプリケーション・ポリシーおよびシステム・ポリシーを移行します。「ポリシーの手動による移行」のサンプルを参照してください。
アプリケーション資格証明の移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPに資格証明を移行します。「資格証明の手動による移行」のサンプルを参照してください。
いずれの場合も、必要に応じ、Fusion Middleware Controlを使用してアプリケーション・ロールを本番用のエンタープライズ・グループにマップします。
Fusion Middleware Controlを使用して、本番環境の管理資格証明が有効であることを確認します。特に、テスト用のパスワードと本番用のパスワードを照合してください。必要に応じて、本番用のデータを適宜変更します。
コマンドmigrateSecurityStoreではGUIDが再作成されるので、このコマンドを使用して大量のポリシーを移行すると長時間を要する場合があります。そのため、テスト環境から本番環境への移行時には、Oracle Internet Directoryの一括操作を使用する別の手順でポリシーと資格証明を移行することを検討するようお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。
コマンドmigrateSecurityStoreを使用して手動でポリシーを移行するには、移行元と移行先を指定している構成ファイルをアセンブルする必要があります。
次のt2p-policies.xmlという構成ファイルの完全なサンプルは、LDAPポリシーおよびXMLポリシーの移行元とLDAPポリシーの移行先の指定を示しています。
<?xml version="1.0" encoding="UTF-8" standalone='yes'?> <jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1"> <serviceProviders> <serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE"> <description>Bootstrap credential provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE"> <description>XML-based policy store provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="ldap.policystore.provider" type="POLICY_STORE"> <property value="OID" name="policystore.type"/> <description>LDAP-based policy store provider</description> </serviceProvider> </serviceProviders> <serviceInstances> <!-- Source XML-based policy store instance --> <serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml.source"> <description>Replace location with the full path of the folder where the system-jazn-data.xml is located in the source file system </description> </serviceInstance> <!-- Source LDAP-based policy store instance --> <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.source"> <description>Replace: A. mySourceDomain and mySourceRootName to appropriate values according to your source LDAP directory structure; B. OID with OVD, if your source LDAP is OVD; C. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description> <property value="OID" name="policystore.type"/> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/> <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://mySourceHost.com:3060" name="ldap.url"/> </serviceInstance> <!-- Destination LDAP-based policy store instance --> <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.destination"> <description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. OID with OVD, if your destination LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your destination LDAP</description> <property value="OID" name="policystore.type"/> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/> <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://myDestHost.com:3060" name="ldap.url"/> </serviceInstance> <!-- Bootstrap credentials to access source and destination LDAPs --> <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred"> <description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in destinationDomain/config/fmwconfig/</description> </serviceInstance> </serviceInstances> <jpsContexts> <jpsContext name="XMLsourceContext"> <serviceInstanceRef ref="policystore.xml.source"/> </jpsContext> <jpsContext name="LDAPsourceContext"> <serviceInstanceRef ref="policystore.ldap.source"/> </jpsContext> <jpsContext name="LDAPdestinationContext"> <serviceInstanceRef ref="policystore.ldap.destination"/> </jpsContext> <!-- Do not change the name of the next context --> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext> </jpsContexts> </jpsConfig>
ここではLDAPストアも移行するので、ブートストラップ資格証明ファイルcwallet.ssoが格納されているディレクトリを指定するbootstrap_credstore_contextというjps-contextがファイルに含まれています。
コマンドmigrateSecurityStoreの使用方法を示す後述の例は、次の点を前提としています。
コマンドを実行するターゲット・システム上のディレクトリにファイルt2p-policies.xmlが格納されていること。
テスト環境と本番環境とでLDAPシステム・ポリシーのディレクトリ構造が同じであること。このディレクトリ構造が異なっている場合は、本番環境のシステム・ポリシー・ディレクトリを、テスト環境側の対応する構造に合せて手動で再構築した後でコマンドを実行します。
これらの前提の下で、テスト用の（移行元）LDAPストアから本番用の（移行先）LDAPストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="policyStore",configFile="t2p-policies.xml",src="LDAPsourceContext",dst="LDAPdestinationContext")
同様に、テスト用の（移行元）XMLストアから本番用の（移行先）LDAPストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="policyStore",configFile="t2p-policies.xml",src="XMLsourceContext",dst="LDAPdestinationContext")
コマンドmigrateSecurityStoreではGUIDが再作成されるので、このコマンドを使用して大量の資格証明を移行すると長時間を要する場合があります。そのため、テスト環境から本番環境への移行時には、Oracle Internet Directoryの一括操作を使用する別の手順でポリシーと資格証明を移行することを検討するようお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。
コマンドmigrateSecurityStoreを使用して手動で資格証明を移行するには、移行元と移行先を指定している構成ファイルをアセンブルする必要があります。
コマンドmigrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。
次のt2p-credentials.xmlという構成ファイルの完全なサンプルは、LDAP資格証明およびXML資格証明の移行元とLDAP資格証明の移行先の指定を示しています。
<?xml version="1.0" encoding="UTF-8" standalone='yes'?> <jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1"> <serviceProviders> <serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE"> <description>File-based credential provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE"> <description>LDAP-based credential provider</description> </serviceProvider> </serviceProviders> <serviceInstances> <!-- Source file-based credential store instance --> <serviceInstance location="myFileBasedCredStoreLocation" provider="credstoressp" name="credential.file.source"> <description>Replace location with the full path of the folder where the file-based source credential store cwallet.sso is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description> </serviceInstance> <!-- Source LDAP-based credential store instance --> <serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.source"> <description>Replace: A. mySourceDomain and mySourceRootName to appropriate values according to your source LDAP directory structure; B. OID with OVD, if your source LDAP is OVD; C. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description> <property value="OID" name="credstore.type"/> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/> <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://mySourceHost.com:3060" name="ldap.url"/> </serviceInstance> <!-- Destination LDAP-based credential store instance --> <serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.destination"> <description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. OID with OVD, if your destination LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your destination LDAP</description> <property value="OID" name="credstore.type"/> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/> <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://myDestHost.com:3060" name="ldap.url"/> </serviceInstance> <!-- Bootstrap credentials to access source and destination LDAPs --> <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred"> <description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in destinationDomain/config/fmwconfig/</description> </serviceInstance> </serviceInstances> <jpsContexts> <jpsContext name="FileSourceContext"> <serviceInstanceRef ref="credential.file.source"/> </jpsContext> <jpsContext name="LDAPsourceContext"> <serviceInstanceRef ref="credential.ldap.source"/> </jpsContext> <jpsContext name="LDAPdestinationContext"> <serviceInstanceRef ref="credential.ldap.destination"/> </jpsContext> <!-- Do not change the name of the next context --> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext> </jpsContexts> </jpsConfig>
ここではLDAPストアも移行するので、ブートストラップ資格証明ファイルcwallet.ssoが格納されているディレクトリを指定するbootstrap_credstore_contextというjps-contextがファイルに含まれています。
コマンドmigrateSecurityStoreの使用方法を示す後述の例は、コマンドを実行するターゲット・システム上のディレクトリにファイルt2p-credentials.xmlが格納されていることを前提とします。
この前提の下で、テスト用の（移行元）LDAPストアから本番用の（移行先）LDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="credStore",configFile="t2p-credentials.xml",src="LDAPsourceContext",dst="LDAPdestinationContext")
同様に、テスト用の（移行元）XMLストアから本番用の（移行先）LDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="credStore",configFile="t2p-credentials.xml",src="FileSourceContext",dst="LDAPdestinationContext")
この項で説明する別の手順によるストアの移行は、ソースのGUIDを保持する場合や、コマンドmigrateSecurityStoreによる移行では長時間を要する大量のストアを移行する場合に適しています。
ここでは次のコードで示すように、ファイルjps-config.xmlでサービス・インスタンスを使用して移行元のポリシー・ストアLDAPを構成しているものとします。
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
<property name="policystore.type" value="OID" />
<property name="security.principal" value="cn=orcladmin"/>
<property name="oracle.security.jps.farm.name" value="cn=base_domain"/>
<property name="lasp.example.com" value="cn=jpsnode,c=us"/>
<property name="ldap.url" value="ldap://myCompany.com:7766"/>
</serviceInstance>
プロパティldap.example.comは、移行元のOracle Internet Directoryリポジトリにあるストアのベース・ノードを示します。
|
重要: 移行先のOracle Internet Directoryがリリース10.1.4.3.0の場合は、次の手順を実行する前にOracle Bug#8417224のパッチを適用する必要があります。使用しているプラットフォームに対応するパッチをダウンロードするには、My Oracle Support（http://myoraclesupport.oracle.com）にアクセスしてください。 |
一括コマンドを使用して移行元のOracle Internet Directoryストアを移行先のOracle Internet Directoryストアに移行する手順は次のとおりです。
移行元のOracle Internet Directoryがあるシステムで、次の行に示すようにldfiwriteを実行してLDIFファイルを生成します。
>ldifwrite connect="srcOidDbConnectStr" baseDN="cn=jpsnode, c=us" ldiffile="srcOid.ldif"
このコマンドでは、ノードcn=jpsnode, c=us以下のすべてのエントリがファイルsrcOid.ldifに書き込まれます。生成したLDIFファイルを、次に実行するコマンドで使用できるように、必要に応じて移行先のOracle Internet Directoryファイル・システムに移動します。
移行先のOracle Internet Directoryノードで、JPSスキーマがシード済であることを確認します。
移行元のOracle Internet Directoryシステムで、次の行に示すようにbulkloadを実行してスキーマ・エラーや不適切なエントリがないことを確認します。
>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
重複するDN（移行元のディレクトリと移行先のディレクトリとの間で共通するエントリ）が検出された場合は、予期しない結果が生じないようにそれらのDNを確認します。
移行先のDBをバックアップします。次の手順に失敗した場合（その結果、DBが破損した場合）は、DBをリストアする必要があります。
次の行に示すようにbulkloadを実行して、移行先のOracle Internet Directoryにデータをロードします。
>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
前述のコマンドの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の第14章「一括操作の実行」を参照してください。
監査ポリシーを移行するには、次に説明するエクスポート操作とインポート操作を使用します。
まず、次のいずれかのツールを使用して、テスト環境からファイルに監査構成をエクスポートします。
Fusion Middleware Control: 「ドメイン名」→「セキュリティ」→「監査ポリシー」に移動し、「エクスポート」をクリックします。
WLSTコマンドexportAuditConfig。詳細は、付録C「exportAuditConfig」を参照してください。
次に、次のいずれかのツールを使用して、本番環境にファイルをインポートします。
Fusion Middleware Control: 「ドメイン名」→「セキュリティ」→「監査ポリシー」に移動し、「インポート」をクリックします。
WLSTコマンドimportAuditConfig。詳細は、付録C「importAuditConfig」を参照してください。
前述のインポートとエクスポートの操作で移行できるのは監査ポリシーのみです。監査データ・ストアの設定は移行できません。テスト環境で監査データソースを構成していた場合は、本番環境でデータソースを構成する手順を繰り返します。詳細は、第12.2.2項「監査データソースの設定」を参照してください。
通常、テスト環境の監査データ・レコードを本番環境に移行することはありませんが、移行する場合は、データベースのインポート/エクスポート・ユーティリティを使用します。詳細は、第12.5.5項「データのインポートとエクスポート」を参照してください。
