| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-06 |
|
 前 |
 次 |
アプリケーションをOracle WebLogic Serverにデプロイするには、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle JDeveloper、またはWebSphere Application Serverコンソールのいずれかのツールを使用します。WebLogicサーバーに認識されている場所にビットを設定することで、アプリケーションを起動することもできます。この場合、サーバーを再起動する必要はありません。このような種類のアプリケーション起動は、ホット・デプロイとして知られています。
アプリケーションをデプロイするための推奨方法は、プラットフォーム、アプリケーションのタイプ、およびそのアプリケーションが開発中フェーズと開発後フェーズのどちらのフェーズにあるかによって異なります。たとえば、開発後フェーズでは通常、ホット・デプロイを使用して本番環境でアプリケーションを起動します。
この章で説明する推奨事項は、Oracle ADFアプリケーションと、OPSSを使用するJava EEアプリケーションにのみ当てはまります。
開発時には、Oracle JDeveloperを使用してアプリケーションを組込みOracle WebLogic Serverにデプロイすることが普通です。テスト環境または本番環境に移行したアプリケーションは、通常、Fusion Middleware ControlまたはOracle WebLogic Server管理コンソールあるいはホット・デプロイを使用してデプロイします。
この章では、Oracle ADFアプリケーションまたはPure Java EEアプリケーションのデプロイ時に実行する管理タスクを中心に説明します。最後の項では、アプリケーションを手動でパッケージ化する場合のみを対象として、セキュアJava EEアプリケーションのパッケージ要件について説明します。
この章の内容は次のとおりです。
補足ドキュメント
デプロイメントの詳細は、『Oracle Fusion Middleware管理者ガイド』の第8章「アプリケーションのデプロイ」を参照してください。
デプロイメントから本番に至るまで、アプリケーション全体のセキュリティ・ライフサイクルの概要は、『Oracle Fusion Middlewareセキュリティ概要』を参照してください。
デプロイ時におけるOracle ADF アプリケーションの保護の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
アプリケーションのライフ・サイクルの詳細は、第19.4項「付録: ADFアプリケーションのセキュリティ・ライフ・サイクル」を参照してください。
web.xmlやweblogic-application.xmlなど、アプリケーションのセキュリティ管理と構成に関連してEARファイルに含まれているファイルの詳細は、第21章「OPSSを使用するためのJava EEアプリケーションの手動構成」を参照してください。
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にデプロイします。
このフローを図示すると次のようになります。
この章で検討するアプリケーションのタイプは、Java EEアプリケーションです。Java EEアプリケーションは、さらにPure Java EEアプリケーションとOracle Fusion Middleware ADFアプリケーションに分類できます。この2種類のJava EEアプリケーションの相違点は、第1.5.1項「シナリオ1: Java EEアプリケーションのセキュリティ強化」および第1.5.2項「シナリオ2: Oracle ADFアプリケーションの保護」を参照してください。
表6-1は、開発したアプリケーションのデプロイに使用するツールをそのアプリケーションのタイプ別に示しています。
表6-1 開発したアプリケーションをデプロイするためのツール
| アプリケーション・タイプ | 使用するツール |
|---|---|
|
Pure Java EEアプリケーション |
Oracle WebLogic管理コンソール、Fusion Middleware Control、WebSphere Application Server Administrator Console、WebSphere Application Server WASAdminコマンド。推奨するツールはOracle WebLogic管理コンソールです。 |
|
Oracle ADFアプリケーション |
Fusion Middleware ControlまたはOPSSスクリプト。推奨ツールはFusion Middleware Controlです。 |
この項では、Oracle ADFセキュリティを使用するアプリケーションまたはOPSSを使用するJava EEアプリケーションを、Fusion Middleware ControlによってWebLogicサーバーにデプロイする際に使用可能なセキュリティ構成を中心に説明します。
具体的には、デプロイ設定の3番目のステージで「アプリケーション・セキュリティの構成」ページに表示されるオプションについて説明します。
このページの外観は、EARファイルのパッケージ内容に応じて次のようになります。
アプリケーション・ポリシーを設定したjazn-data.xmlをEARファイルにパッケージ化している場合は、アプリケーション・ポリシーの移行セクションが表示されます。
cwallet.ssoに収めた資格証明をEARファイルにパッケージ化している場合は、資格証明の移行セクションが表示されます。
前述のいずれもEARファイルにパッケージ化していない場合、このページにはデフォルトのJava EEセキュリティ・オプションが表示されます。
このページには、ポリシーの移行セクションが表示されます。その一部を次に示します。
このページの設定は、該当のドメイン・ストアへのアプリケーション・ポリシーと資格証明(アプリケーションEARファイルにパッケージ化される)の移行に関連するものです。次では、これらの設定について説明します。
これらの設定では、次のシナリオでポリシーの移行を制御します。
アプリケーションを初めてデプロイする場合、通常はポリシー・ストアにアプリケーション・ポリシーを移行します。そのためには、「アプリケーション・ポリシー移行」領域で「追加」を選択します。
なんらかの理由で移行しない場合は「無視」を選択します。オプションの「上書き」も使用できます。
以前のデプロイでアプリケーション・ポリシーを移行済であることを前提としてアプリケーションを再デプロイしている場合、パッケージ化したポリシーをドメイン内の既存のポリシーにマージするには「追加」を選択し、ポリシーを移行しないようにするには「無視」を選択します。
アプリケーションを再デプロイするときに、ドメインに設定した現在のアプリケーション・ポリシーを変更しない場合、つまり以前のデプロイの際に変更したポリシー・ストアの内容を保持する場合は、「無視」を選択します。
「追加」を選択すると、移行する権限とロールを指定できます。基本的な相違点は、ADFアプリケーションのロールと権限(本番環境で必要)と開発時のみのロールと権限(本番環境では不要)との差です。
ADFアプリケーションのロールと権限を移行して、開発時のみのセキュリティ・ロールと権限を移行しないようにするには、次のチェック・ボックスを選択します: アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。通常、本番環境へのデプロイ時には、このチェック・ボックスを選択します。このボックスを選択した場合は、アプリケーションをデプロイした後でそのアプリケーション・ロールをエンタープライズ・グループにマップする必要があります。
「追加」を選択した場合に、アプリケーション・ポリシーの移行先とする特定のストライプ(アプリケーション名を名前としたデフォルトのストライプとは異なるストライプ)を指定するには、「アプリケーション・ストライプID」ボックスにそのストライプの名前を入力します。
|
アプリケーション・ストライプについて: ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル |
|
一般的な使用例 このページでは、次の2つの一般的なシナリオで指定するポリシーの移行について説明します。
|
何も指定しない場合のデフォルト設定は、「追加」(デプロイの場合)と「無視」(再デプロイの場合)です。
これらの設定では、次のシナリオで資格証明の移行を制御します。
アプリケーションを初めてデプロイする場合、通常は資格証明ストアにアプリケーション資格証明を移行します。そのためには、「アプリケーション資格証明移行」領域で「追加」を選択します。
いずれの場合も(初めてのデプロイでもその後のデプロイでも)、なんらかの理由で移行しない場合は「無視」を選択します。
|
注意: 資格証明の移行を無視すると、資格証明を使用するアプリケーション・コードが動作しない場合があります。通常は、マップとキーが同じで値が異なる資格証明を手動で作成するという前提の下で「無視」オプションを選択します。 |
WebLogicサーバーを開発モードで稼働している場合にのみ、「上書き」オプションを使用できます。
何も入力しない場合は、デフォルトの「無視」になります。
Oracle ADFアプリケーションはJAAS認可を使用するJava EEアプリケーションで、通常は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管理者ガイド』のOracle ADFのデプロイおよびアンデプロイに関する項を参照してください。
この項の内容は次のとおりです。
デプロイ時に使用できるセキュリティ・オプションは、「Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。
Fusion Middleware Controlを使用してOracle ADFアプリケーションをテスト環境にデプロイするときには次の手順が発生します。
アプリケーションとパッケージ化されたアプリケーション固有のポリシーは、アプリケーションのデプロイ時に資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。
|
注意: ファイルベースのポリシー・ストア(つまり、 |
アプリケーションとパッケージ化されたアプリケーション固有の資格証明は、アプリケーションのデプロイ時に資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。
移行中にLDAPリポジトリにアクセスするために必要なブートストラップ資格証明は、Fusion Middleware Controlによって自動的に生成されます。手動設定の詳細は、第21.4.7項「ブートストラップ資格証明の手動による指定」を参照してください。
アプリケーションとパッケージ化されたアイデンティティは移行されません。ドメイン管理者はドメイン認証プロバイダを構成し(管理コンソールを使用)、必要に応じて、環境にあるアイデンティティ(エンタープライズ・ユーザーおよびグループ)を更新して、エンタープライズ・ユーザーおよびグループにアプリケーション・ロールをマップする(Fusion Middleware Controlを使用)必要があります。
その他の考慮事項
LDAPベースのセキュリティ・ストアを持つドメインにデプロイする場合は、アプリケーションのデータの整合性を保持するために、アプリケーションをクラスタ・レベルでデプロイするか、1つの管理対象サーバーにのみデプロイすることをお薦めします。
アプリケーションを複数の管理対象サーバーにデプロイするときは、管理サーバーを含めてデータが予期したとおりに移行されるようにしてください。
ドメイン・ストアの再関連付けは頻繁に行う操作ではなく、通常は、アプリケーションをデプロイする前のドメインを設定するときに行います。手順の詳細は、第8.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。
テスト環境へのアプリケーションのデプロイ後、管理者はFusion Middleware Controlまたは管理コンソールを使用していつでも次のタスクを実行できます。
エンタープライズ・グループへのアプリケーション・ロールのマップ。このマッピングが完了するまで、セキュリティは予期したとおりに動作しません。手順の詳細は、第9.2.2項「アプリケーション・ロールの管理」を参照してください。
新しいアプリケーション・ロールの作成または既存のアプリケーション・ロールのカスタマイズ。詳細は、第9.2.2項「アプリケーション・ロールの管理」を参照してください。
システム・ポリシーの管理。手順の詳細は、第9.2.3項「システム・ポリシーの管理」を参照してください。
資格証明の管理。手順の詳細は、第10.3項「資格証明ストアの管理」を参照してください。
|
注意: Fusion Middleware Controlを使用して、本番モードで実行しているサーバーからアプリケーションをアンデプロイすると、そのアプリケーション固有のポリシーがポリシー・ストアから自動的に削除されます。また、他のツールを使用してアプリケーションをアンデプロイする場合は、そのアプリケーション固有のポリシーを手動で削除する必要があります。 資格証明は、アプリケーションをアンデプロイしても削除できません。資格証明は、アプリケーションとパッケージ化することで有効になりますが、アプリケーションをアンデプロイしても資格証明は削除されません。 |
OPSSを使用せずにJavaの標準認可を使用するJava EEアプリケーションを保護するには、管理コンソールまたはOPSSスクリプトを使用して管理面で保護する方法と、デプロイメント・ディスクリプタを使用してプログラムで保護する方法の2通りがあります。
Oracle WebLogic ServerにデプロイしたJava EEアプリケーションは、WebLogicリソースとなります。したがって、管理者は、他のリソースの場合と同じ方法で、デプロイされたアプリケーションにセキュリティを設定できます。
デプロイ手順の詳細は、『Oracle Fusion Middleware管理者ガイド』のJava EEアプリケーションのデプロイおよびアンデプロイに関する項を参照してください。
WLSTコマンドを使用したアプリケーションのデプロイの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のデプロイ・コマンドに関する項を参照してください。
WebLogic Serverのデプロイ機能の概要は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「WebLogic Serverのデプロイについて」の章を参照してください。
関連ドキュメント
アプリケーション・リソースの保護の詳細は、次のドキュメントに記載されています。
Oracle Fusion Middleware Oracle WebLogic Serverのロールとポリシーを使用したリソースの保護の次の各項
アプリケーションのリソースに関する項
WebアプリケーションおよびEJBリソースの保護のオプションに関する項
Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの次の項
ロールとポリシーの使用したリソースの保護に関する項
『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護』の次の項
Webサービス・セキュリティの概要に関する項
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』の次の各項
Webアプリケーションの保護に関する項特に、Webアプリケーションでの宣言セキュリティの使用に関する項
Enterprise JavaBeans (EJBs)の保護に関する項
Javaセキュリティを使用したWebLogicリソースの保護に関する項
次の推奨事項は、JAAS認可を使用するJava EEアプリケーションにのみ当てはまります。このようなアプリケーションには、Oracle Application Development Frameworkアプリケーション、Oracle SOAアプリケーション、Oracle WebCenterアプリケーションなどがあります。標準認可を使用するJava EEアプリケーションは、この推奨事項の対象外です。標準認可を使用するJava EEアプリケーションのデプロイは、「標準Java EEアプリケーションのデプロイ」を参照してください。
アプリケーションをデプロイするための推奨ツールはFusion Middleware Controlです。後述の項で説明する操作を実行するユーザーは、LDAPリポジトリでスキーマをシードする権限など、適切な権限を持っている必要があります。
第5.2.1項「新しい本番環境の設定」の説明に従って本番環境が設定されていることを前提とします。
|
重要事項: 本番環境ではファイルベース・ストアは推奨されません。 |
新しい本番環境への移行は、ポリシー・プロバイダおよび資格証明プロバイダ以外のプロバイダの移行、ポリシー・プロバイダおよび資格証明プロバイダの移行、監査ポリシーの移行という3段階に分かれています。それぞれの段階の詳細は次の各項を参照してください。
移行はセキュリティ・データのバックアップおよびリカバリに使用できます。セキュリティ・データをバックアップするには、XMLベース・ストアに移行します。セキュリティ・データをリカバリするには、保存済のXMLベース・ストアからターゲットのセキュリティ・ストアに移行します。
本番環境でのプロバイダ(ポリシー・プロバイダおよび資格証明プロバイダ以外)の構成は、テスト環境で使用した構成と同じものとする必要があります。この場合のタスクとして、次のものが考えられます。
アイデンティティ・ストアの構成(WebLogic管理コンソールやOPSSスクリプトconfigureIdentityStoreを使用して必要なユーザーやグループのプロビジョンを行う場合など)。この最後のコマンドの詳細は、「アイデンティティの手動による移行」を参照してください。
テスト環境で実行したあらゆる特定のプロバイダの構成
|
注意: Oracle WebLogic Serverには、 |
アイデンティティ・データは、OPSSスクリプトmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。この移行が必要になる状況の例として、ファイルベースのアイデンティティ・ストアを使用するテスト環境からLDAPベースのアイデンティティ・ストアを使用する本番環境に移行する場合があります。
このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
このコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。
OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。
スクリプト・モードおよびインタラクティブ・モードの構文
WebLogicにアイデンティティを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore -type idStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-dstLdifFile LdifFileLocation]
migrateSecurityStore(type="idStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [dstLdifFile="LdifFileLocation"])
WebSphereへのアイデンティティの移行は、同じスクリプトを使用して行います。詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
引数(dstLdifFile以外はすべて必須)の意味は次のとおりです。
configFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。
srcでは、引数configFileで渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。
dstでは、引数configFileで渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。移行先ストアは、LDAPベースのアイデンティティ・ストアにする必要があります。サポートされているタイプの一覧は、第3.1.1項「サポートされているLDAPアイデンティティ・ストアのタイプ」を参照してください。
dstLdifFileでは、作成したLDIFファイルの相対パスまたは絶対パスを指定します。移行先がLDAPベースのOracle Internet Directoryストアである場合にのみ必要です。LDIFファイルはLDAPサーバーにはインポートされません。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
LDIFファイルを生成した後、通常は、このファイルを手動で編集して、LDIFファイルの最終的なインポート先となるLDAPリポジトリの属性をカスタマイズします。
本番環境では、OPSSセキュリティ・ストア(ポリシー、資格証明、およびキー・ストア)LDAPベースのOracle Internet Directoryに再関連付けすることを強くお薦めします。テスト用のポリシー・ストアおよび資格証明ストアもLDAPであったとしても、本番用のLDAPはテスト用のLDAPとは別のものとすることが前提となっています。テスト用のポリシー・ストアがファイルベースであったとしても、 権限に重複したパーミッションがないことを確認してください。「ポリシー管理」の注意を参照してください。
ストアを再関連付けする方法の詳細は、第8.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。
ポリシーおよび資格証明の移行は、アプリケーションのデプロイ時に自動的に処理できるほか、アプリケーションのデプロイ前またはデプロイ後に手動で実行することもできます。
WebLogic Serverにデプロイしたすべてのアプリケーションについて、(アプリケーション移行に関する特定の設定とは関係なく)ポリシーと資格証明の自動移行を無効にするには、システム・プロパティjps.deployment.handler.disabledをTRUEに設定します。
アプリケーションを本番環境にデプロイする際、管理者は次の点を把握している必要があります。
アプリケーションEARにパッケージ化したポリシーまたは資格証明がテスト環境で変更されているかどうか
この点を把握していることを前提として、アプリケーションを本番環境にデプロイする手順は次のとおりです。
Fusion Middleware Controlで次のオプションを使用して、アプリケーションのEARファイルを本番環境にデプロイします。
ポリシー(アプリケーションまたはシステム)がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション・ポリシー移行」領域で「無視」オプションを選択して、デプロイ時にポリシーを移行するオプションを無効にします。ポリシーが変更されていない場合は、「追加」を選択します。
|
注意: テスト環境でのアプリケーション・ロールの変更がテスト用のエンタープライズ・グループへのマッピングにまで及んでいても、「追加」(アプリケーション・ポリシーの移行)を選択し、同時に「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」チェック・ボックスを選択できます。 この組合せを選択した場合、アプリケーション・ポリシーは移行されますが、テスト用のエンタープライズ・グループへのマッピングは無視されます。後述のステップ3で、アプリケーション・ロールを本番用のエンタープライズ・グループに再マップする必要があります。 |
資格証明がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション資格証明移行」領域で「無視」オプションを選択して、デプロイ時に資格証明を移行するオプションを無効にします。資格証明が変更されていない場合は、「追加」を選択します。
次の説明に従い、スクリプトmigrateSecurityStoreを使用して、変更済のデータを移行します。
アプリケーション・ポリシーの移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPにアプリケーション・ポリシーおよびシステム・ポリシーを移行します。「ポリシーの手動による移行」のサンプルを参照してください。
アプリケーション資格証明の移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPに資格証明を移行します。「資格証明の手動による移行」のサンプルを参照してください。
いずれの場合も、必要に応じ、Fusion Middleware Controlを使用してアプリケーション・ロールを本番用のエンタープライズ・グループにマップします。
Fusion Middleware Controlを使用して、本番環境の管理資格証明が有効であることを確認します。特に、テスト用のパスワードと本番用のパスワードを照合してください。必要に応じて、本番用のデータを適宜変更します。
|
注意: アプリケーションのデプロイでポリシーを移行したときに、GUIDを再作成しなくても元のGUIDが保持されるようにアプリケーションを構成する方法があります。 この設定は、手動でのみ構成できます。詳細は、第21.4.1項「ポリシーの移行を制御するパラメータ」でパラメータ |
デフォルトでは、スクリプトmigrateSecurityStoreでGUIDが再作成されるので、このコマンドを使用して大量のポリシーを移行すると長時間を要する場合があります。そのため、テスト環境から本番環境への移行時には、Oracle Internet Directoryの一括操作を使用する別の手順によるポリシーと資格証明の移行を検討するようお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。
スクリプトmigrateSecurityStoreを使用して手動でポリシーを移行するには、移行元および移行先が指定されている構成ファイルをアセンブルする必要があります。
次のt2p-policies.xmlという構成ファイルの完全なサンプルは、LDAPストレージ、DBストレージおよびXMLストレージのポリシーの移行元の指定と、LDAPストレージおよびDBストレージのポリシーの移行先の指定を示しています。
<?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.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>
<serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="db.policystore.provider" type="POLICY_STORE">
<property value="DB_ORACLE" name="policystore.type"/>
<description>DB-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>
<!-- Source DB-based policy store instance -->
<serviceInstance provider="db.policystore.provider" name="policystore.db.source">
<description>Replace: mySourceDomain and mySourceRootName to appropriate
values according to your source DB policy store structure
</description>
<property value="DB_ORACLE" name="policystore.type"/>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@mySourceHost.com:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the source
datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="mySourceKeyName" />
<property name="bootstrap.security.principal.map" value="mySourceMapName" />
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</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>
<!-- Destination DB-based policy store instance -->
<serviceInstance provider="db.policystore.provider" name="policystore.db.destination">
<description>Replace: myDestDomain and myDestRootName to appropriate values
according to your destination DB policy store structure</description>
<property value="DB_ORACLE" name="policystore.type"/>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@myDestHostcom:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the destination datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="myDestKeyName" />
<property name="bootstrap.security.principal.map" value="myDestMapName" />
<!-- the value of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the value entered when the bootstrap credential was set up -->
</serviceInstance>
<!-- Bootstrap credentials to access source and destination LDAPs or DBs-->
<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="DBsourceContext">
<serviceInstanceRef ref="policystore.db.source"/>
</jpsContext>
<jpsContext name="LDAPdestinationContext">
<serviceInstanceRef ref="policystore.ldap.destination"/>
</jpsContext>
<jpsContext name="DBdestinationContext">
<serviceInstanceRef ref="policystore.db.destination"/>
</jpsContext>
<!-- Do not change the name of the next context -->
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
</jpsContexts>
</jpsConfig>
ここではLDAPストアやDBストアも移行するので、ブートストラップ資格証明ファイルcwallet.ssoが格納されているディレクトリを指定するbootstrap_credstore_contextというjps-contextがファイルに含まれています。さらに、前述のサンプルのマップ名とキー名の各ペアに対して、WLSTスクリプトaddBootStrapCredentialを使用して、対応するブートストラップ資格証明を指定する必要があります。この方法を次の例に示します。
wls:/offline> addBootStrapCredential(jpsConfigFile='jps-config.xml', map='myMapName', key='myKeyName', username='myUserName', password='myPassword')
myUserNameおよびmyPassawordには、ターゲット・データベースにアクセスするユーザー・アカウントの名前とパスワードを指定します。
migrateSecurityStoreの使用方法を示す後述の例は、次の点を前提としています。
スクリプトを実行するターゲット・システム上のディレクトリにファイルt2p-policies.xmlが格納されています。
テスト環境と本番環境で、LDAPまたはDBシステム・ポリシーのディレクトリ構造が同じです。このディレクトリ構造が異なっている場合は、本番環境のシステム・ポリシー・ディレクトリを、テスト環境側の対応する構造にあわせて手動で再構築してからスクリプトを実行します。
これらの前提の下で、テスト用の(移行元)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")
テスト用の(移行元)DBストアから本番用の(移行先)DBストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="policyStore",configFile="t2p-policies.xml",src="DBsourceContext",dst="DBdestinationContext")
スクリプトmigrateSecurityStoreではGUIDが再作成されるので、このコマンドを使用して大量の資格証明を移行すると長時間を要する場合があります。そのため、テスト環境から本番環境への移行時には、Oracle Internet Directoryの一括操作を使用する別の手順でポリシーと資格証明を移行することを検討するようお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。
migrateSecurityStoreを使用して手動で資格証明を移行するには、移行元および移行先が指定された構成ファイルをアセンブルする必要があります。
migrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。
次のt2p-credentials.xmlという構成ファイルの完全なサンプルは、LDAPストレージ、DBストレージおよびXMLストレージの資格証明の移行元の指定と、LDAPストレージおよびDBストレージの資格証明の移行先の指定を示しています。
<?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> <serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider" name="db.credentialstore.provider" type="CREDENTIAL_STORE"> <description>DB-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. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description> <property value="bootstrap" name="bootstrap.security.credential.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> <!-- Source DB-based credential store instance --> <serviceInstance provider="db.credentialstore.provider" name="credential.db.source"> <description>Replace: A. mySourceDomain and mySourceRootName to appropriate values according to your source DB credential store</description> <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/> <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/> <property value="jdbc:oracle:thin:@mySourceHost:1722:orcl" name="jdbc.url"/> <!-- the value of jdbc.url should be the value entered when the source datasource was set up --> <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/> <property name="bootstrap.security.principal.key" value="mySourceKeyName" /> <property name="bootstrap.security.principal.map" value="mySourceMapName" /> <!-- the values of bootstrap.security.principal.key and bootstratp.security.principal.map should be the values entered when the bootstrap credential was set up --> </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. ldap://myDestHost.com:3060 with the URL and port number of your destination LDAP</description> <property value="bootstrap" name="bootstrap.security.credential.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> <!-- Destination DB-based credential store instance --> <serviceInstance provider="db.credentialstore.provider" name="credential.db.destination"> <description>Replace: myDestDomain and myDestRootName to appropriate values according to your destination DB credential store</description> <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/> <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/> <property value="jdbc:oracle:thin:@myDestHost.com:1722:orcl" name="jdbc.url"/> <!-- the value of jdbc.url should be the value entered when the destination datasource was set up --> <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/> <property name="bootstrap.security.principal.key" value="myDestKeyName" /> <property name="bootstrap.security.principal.map" value="myDestMapName" /> <!-- the values of bootstrap.security.principal.key and bootstratp.security.principal.map should be the values entered when the bootstrap credential was set up --> </serviceInstance> <!-- Bootstrap credentials to access source and destination LDAPs and DBs --> <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="DBsourceContext"> <serviceInstanceRef ref="credential.db.source"/> </jpsContext> <jpsContext name="LDAPdestinationContext"> <serviceInstanceRef ref="credential.ldap.destination"/> </jpsContext> <jpsContext name="DBdestinationContext"> <serviceInstanceRef ref="credential.db.destination"/> </jpsContext> <!-- Do not change the name of the next context --> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext> </jpsContexts> </jpsConfig>
ここではLDAPストアやDBストアも移行するので、ブートストラップ資格証明ファイル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")
テスト用の(移行元)DBストアから本番用の(移行先)DBストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="credStore",configFile="t2p-credentials.xml",src="DBSourceContext",dst="DBdestinationContext")
この項で説明する別の手順によるストアの移行は、ソースのGUIDを保持する場合や、スクリプトmigrateSecurityStoreによる移行では長時間を要する大量のストアを移行する場合に適しています。
|
注意: 大量のストアの移行は、LDAPベースのストアでのみサポートされています。DBベースのストアではサポートされていません。 |
ここでは次のコードで示すように、ファイルjps-config.xmlでサービス・インスタンスを使用して移行元のポリシー・ストアLDAPを構成しているものとします。
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap"> <property name="policystore.type" value="OID" /> <property name="bootstrap.security.principal" value="bootstrap"/> <property name="oracle.security.jps.farm.name" value="cn=base_domain"/> <property name="oracle.security.jps.ldap.root.name" value="cn=mySrcRootName"/> <property name="ldap.url" value="ldap://myCompany.com:7766"/> </serviceInstance>
|
重要: 移行先のOracle Internet Directoryがリリース10.1.4.3.0の場合は、次の手順を実行する前にOracle Bug#8417224のパッチを適用する必要があります使用しているプラットフォームに対応するパッチをダウンロードするには、My Oracle Support( |
一括コマンドを使用して移行元のOracle Internet Directoryストアを移行先のOracle Internet Directoryストアに移行する手順は次のとおりです。
移行元のOracle Internet Directoryがあるシステムで、次の行に示すようにldifwriteを実行してLDIFファイルを生成します。
>ldifwrite connect="srcOidDbConnectStr" baseDN="cn=jpsnode, c=us" ldiffile="srcOid.ldif"
このコマンドでは、ノードcn=jpsnode, c=us以下のすべてのエントリがファイルsrcOid.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: 「ドメイン名」→「セキュリティ」→「監査ポリシー」に移動し、「エクスポート」をクリックします。
OPSSスクリプトexportAuditConfig。詳細は、付録C「exportAuditConfig」を参照してください。
次に、次のいずれかのツールを使用して、本番環境にファイルをインポートします。
Fusion Middleware Control: 「ドメイン名」→「セキュリティ」→「監査ポリシー」に移動し、「インポート」をクリックします。
OPSSスクリプトimportAuditConfig。詳細は、付録C「importAuditConfig」を参照してください。
前述のインポートとエクスポートの操作で移行できるのは監査ポリシーのみです。監査データ・ストアの設定は移行できません。テスト環境で監査データソースを構成していた場合は、本番環境でデータソースを構成する手順を繰り返します。詳細は、第13.2.2項「監査データソースの設定」を参照してください。
通常、テスト環境の監査データ・レコードを本番環境に移行することはありませんが、移行する場合は、データベースのインポート/エクスポート・ユーティリティを使用します。詳細は、第13.5.5項「データのインポートとエクスポート」を参照してください。
migrateSecurityStoreを使用して手動でキーおよび証明書を移行するには、移行元と移行先のサービス・インスタンスを指定する構成ファイルを作成します。次に、この項の末尾にある例に示すように、適切なオプションを指定してmigrateSecurityStoreコマンドを実行します。
次のt2p-keys.xmlという構成ファイルの完全な例は、LDAPストレージ、DBストレージおよびXMLストレージのキーストア・サービスの移行元の指定と、LDAPストレージおよびDBストレージのキーストア・サービスの移行先の指定を示しています。
<?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>
<!--The following service provider configuration serves file-based, LDAP based
And DB based keystore service instance -->
<serviceProvider type="KEY_STORE" name="keystore.provider" class="oracle.security.jps.internal.keystore.KeyStoreProvider">
<description>PKI Based Keystore Provider</description>
</serviceProvider>
</serviceProviders>
<serviceInstances>
<!-- Source XML-based keystore service instance -->
<serviceInstance location="./" provider="keystore.provider" name="keystore.file.source">
<property name="keystore.provider.type" value="file"/>
<property name="keystore.file.path" value="./"/>
<description>Replace keystore.file.path with the full path of the folder where the file-based source keystore service keystores.xml is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
</serviceInstance>
<!-- Source LDAP-based keystore service instance -->
<serviceInstance provider="keystore.provider" name="keystore.ldap.source">
<description>Replace: A. mySourceDomain and mySourceRootName to appropriate
values according to your source LDAP directory structure; B. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description>
<property value="bootstrap" name="bootstrap.security.credential.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"/>
<property name="keystore.provider.type" value="ldap"/>
</serviceInstance>
<!-- Source DB-based keystore service instance -->
<serviceInstance provider="keystore.provider" name="keystore.db.source">
<description>Replace: A. mySourceDomain and mySourceRootName to appropriate
values according to your source DB </description>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@mySourceHost:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the source datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="mySourceKeyName" />
<property name="bootstrap.security.principal.map" value="mySourceMapName" />
<property name="keystore.provider.type" value="db"/>
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</serviceInstance>
<!-- Destination LDAP-based keystore service instance -->
<serviceInstance provider="keystore.provider" name="keystore.ldap.destination">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your destination LDAP</description>
<property value="bootstrap" name="bootstrap.security.credential.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"/>
<property name="keystore.provider.type" value="ldap"/>
</serviceInstance>
<!-- Destination DB-based keystore service instance -->
<serviceInstance provider="keystore.provider" name="keystore.db.destination">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your destination DB </description>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@myDestHost.com:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the destination datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="myDestKeyName" />
<property name="bootstrap.security.principal.map" value="myDestMapName" />
<property name="keystore.provider.type" value="db"/>
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</serviceInstance>
<!-- Bootstrap credentials to access source and destination LDAPs and DBs -->
<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/bootstrap</description>
</serviceInstance>
</serviceInstances>
<jpsContexts>
<jpsContext name="FileSourceContext">
<serviceInstanceRef ref="keystore.file.source"/>
</jpsContext>
<jpsContext name="LDAPsourceContext">
<serviceInstanceRef ref="keystore.ldap.source"/>
</jpsContext>
<jpsContext name="DBsourceContext">
<serviceInstanceRef ref="keystore.db.source"/>
</jpsContext>
<jpsContext name="LDAPdestinationContext">
<serviceInstanceRef ref="keystore.ldap.destination"/>
</jpsContext>
<jpsContext name="DBdestinationContext">
<serviceInstanceRef ref="keystore.db.destination"/>
</jpsContext>
<!-- Do not change the name of the next context -->
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
</jpsContexts>
</jpsConfig>
ここではLDAPストアやDBストアも移行するので、ブートストラップ資格証明ファイルcwallet.ssoが格納されているディレクトリを指定するbootstrap_credstore_contextというjps-contextがファイルに含まれています。
例
|
注意: 次の |
テスト用の(移行元)LDAPストアから本番用の(移行先)LDAPストアにすべてのキーと証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="keyStore",configFile="t2p-keys.xml",
src="LDAPsourceContext",dst="LDAPdestinationContext")
テスト用の(移行元)XMLストアから本番用の(移行先)LDAPストアにすべてのキーと証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="keyStore",configFile="t2p-keys.xml",
src="FileSourceContext",dst="LDAPdestinationContext")
テスト用の(移行元)データベース・ストアから本番用の(移行先)データベース・ストアに、特定のアプリケーション・ストライプに対するキーと証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="stripeKeyStore",configFile="t2p-keys.xml",
src="DBSourceContext",dst="DBdestinationContext", srcStripe="application1", dstStripe="application2")
