| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.2) E47967-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.2) E47967-02 |
|
前 |
次 |
アプリケーションをOracle WebLogic Serverにデプロイするには、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlまたはOracle JDeveloperのいずれかのツールを使用します。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 ADFアプリケーションの保護の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。
アプリケーション・ライフサイクルの詳細は、第16.7項「付録 - ADFアプリケーションのセキュリティ・ライフサイクル」を参照してください。
web.xmlやweblogic-application.xmlなど、アプリケーションのセキュリティ管理と構成に関連してEARファイルに含まれているファイルの詳細は、第18章「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。推奨するツールはOracle WebLogic管理コンソールです。 |
|
Oracle ADFアプリケーション |
Fusion Middleware ControlまたはWLSTコマンド。推奨ツールは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ファイルにパッケージ化される)の移行に関連するものです。次では、これらの設定について説明します。
「アプリケーション・ポリシー移行」の設定
これらの設定では、次のシナリオでポリシーの移行を制御します。
アプリケーションを初めてデプロイする場合、通常はOPSSセキュリティ・ストアにアプリケーション・ポリシーを移行します。そのためには、「アプリケーション・ポリシー移行」領域で「追加」を選択します。
なんらかの理由で移行しない場合は「無視」を選択します。オプションの「上書き」も使用できます。
以前のデプロイでアプリケーション・ポリシーを移行済であることを前提としてアプリケーションを再デプロイしている場合、パッケージ化したポリシーをドメイン内の既存のポリシーにマージするには「追加」を選択し、ポリシーを移行しないようにするには「無視」を選択します。
アプリケーションを再デプロイするときに、ドメインに設定した現在のアプリケーション・ポリシーを変更しない場合、つまり以前のデプロイの際に変更したOPSSセキュリティ・ストアの内容を保持する場合は、「無視」を選択します。
「追加」を選択すると、移行する権限とロールを指定できます。基本的な相違点は、ADFアプリケーションのロールと権限(本番環境で必要)と開発時のみのロールと権限(本番環境では不要)との差です。
ADFアプリケーションのロールと権限を移行して、開発時のみのセキュリティ・ロールと権限を移行しないようにするには、次のチェック・ボックスを選択します: アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。通常、本番環境へのデプロイ時には、このチェック・ボックスを選択します。このボックスを選択した場合は、アプリケーションをデプロイした後でそのアプリケーション・ロールをエンタープライズ・グループにマップする必要があります。
「追加」を選択した場合に、アプリケーション・ポリシーの移行先とする特定のストライプ(アプリケーション名を名前としたデフォルトのストライプとは異なるストライプ)を指定するには、「アプリケーション・ストライプID」ボックスにそのストライプの名前を入力します。
|
アプリケーション・ストライプについて: OPSSセキュリティ・ストアは、論理的に複数のストライプにパーティション化されており、ファイル |
|
一般的な使用例 このページでは、次の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の管理』の第8.4項にあるOracle ADFアプリケーションのデプロイおよびアンデプロイに関する説明を参照してください。
この項の内容は次のとおりです。
デプロイ時に使用できるセキュリティ・オプションは、「Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。
Fusion Middleware Controlを使用してOracle ADFアプリケーションをテスト環境にデプロイするときには次の手順が発生します。
ポリシー管理
アプリケーションとパッケージ化されたアプリケーション固有のポリシーは、アプリケーションがデプロイされるときにOPSSセキュリティ・ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。
|
注意: ファイルベースのOPSSセキュリティ・ストア(つまり、 |
資格証明管理
アプリケーションとパッケージ化されたアプリケーション固有の資格証明は、アプリケーションのデプロイ時に資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。
移行中にLDAPリポジトリにアクセスするために必要なブートストラップ資格証明は、Fusion Middleware Controlによって自動的に生成されます。
アイデンティティ管理
アプリケーションとパッケージ化されたアイデンティティは移行されません。ドメイン管理者はドメイン認証プロバイダを構成し(管理コンソールを使用)、必要に応じて、環境にあるアイデンティティ(エンタープライズ・ユーザーおよびグループ)を更新して、エンタープライズ・ユーザーおよびグループにアプリケーション・ロールをマップする(Fusion Middleware Controlを使用)必要があります。
その他の考慮事項
LDAPベースのセキュリティ・ストアを持つドメインにデプロイする場合は、アプリケーションのデータの整合性を保持するために、アプリケーションをクラスタ・レベルでデプロイするか、1つの管理対象サーバーにのみデプロイすることをお薦めします。
アプリケーションを複数の管理対象サーバーにデプロイするときは、管理サーバーを含めてデータが予期したとおりに移行されるようにしてください。
ドメイン・ストアの再関連付けは頻繁に行う操作ではなく、通常は、アプリケーションをデプロイする前のドメインを設定するときに行います。手順の詳細は、第9.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。
テスト環境へのアプリケーションのデプロイ後、管理者はFusion Middleware Controlまたは管理コンソールを使用していつでも次のタスクを実行できます。
エンタープライズ・グループへのアプリケーション・ロールのマップ。このマッピングが完了するまで、セキュリティは予期したとおりに動作しません。手順の詳細は、第10.2.2項「アプリケーション・ロールの管理」を参照してください。
新しいアプリケーション・ロールの作成または既存のアプリケーション・ロールのカスタマイズ。詳細は、第10.2.2項「アプリケーション・ロールの管理」を参照してください。
システム・ポリシーの管理。手順の詳細は、第10.2.3項「システム・ポリシーの管理」を参照してください。
資格証明の管理。手順の詳細は、第11章「資格証明ストアの管理」を参照してください。
|
注意: Fusion Middleware Controlを使用して、本番モードで実行しているサーバーからアプリケーションをアンデプロイすると、そのアプリケーション固有のポリシーがOPSSセキュリティ・ストアから自動的に削除されます。また、他のツールを使用してアプリケーションをアンデプロイする場合は、そのアプリケーション固有のポリシーを手動で削除する必要があります。 資格証明は、アプリケーションをアンデプロイしても削除できません。資格証明は、アプリケーションとパッケージ化することで有効になりますが、アプリケーションをアンデプロイしても資格証明は削除されません。 |
OPSSを使用せずにJavaの標準認可を使用するJava EEアプリケーションを保護するには、管理コンソールまたはWLSTコマンドを使用して管理面で保護する方法と、デプロイメント・ディスクリプタを使用してプログラムで保護する方法の2通りがあります。
Oracle WebLogic ServerにデプロイしたJava EEアプリケーションは、WebLogicリソースとなります。したがって、管理者は、他のリソースの場合と同じ方法で、デプロイされたアプリケーションにセキュリティを設定できます。
デプロイ手順の詳細は、『Oracle Fusion Middlewareの管理』の第8.3項にあるJava EEアプリケーションのデプロイおよびアンデプロイに関する説明を参照してください。
WebLogic Serverのデプロイ機能の概要は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「WebLogic Serverデプロイメントの理解」を参照してください。
関連ドキュメント
アプリケーション・リソースの保護の詳細は、次のドキュメントに記載されています。
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の次の各項
アプリケーションのリソースに関する項
WebアプリケーションおよびEJBリソースの保護のオプションに関する項
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次の項
ロールとポリシーの使用したリソースの保護に関する項
『Oracle WebLogic Server WebLogic Webサービスの保護』の次の項
Webサービス・セキュリティの概要に関する項
『WebLogicセキュリティ・サービスによるアプリケーションの開発』の次の各項
Webアプリケーションの保護に関する項特に、Webアプリケーションでの宣言セキュリティの使用に関する項
Enterprise JavaBeans (EJBs)の保護に関する項
Javaセキュリティを使用したWebLogicリソースの保護に関する項
アプリケーションでは、Oracle Fusion Middleware監査フレームワークを使用して、監査機能を提供できます。OPSSでは、監査フレームワークとの統合を可能にする監査サービスが提供されます。
監査機能を使用するには、アプリケーションをデプロイする際に、監査サービスにアプリケーションを登録する必要があります。
監査フレームワークの一般的な予備知識については、第13章を参照してください。
アプリケーションを監査サービスに統合する手順の詳細は、第25.2項を参照してください。
特定の構成ファイルをアプリケーションEARファイルでパッケージ化する必要があります。
アプリケーションの監査可能イベントを記述するイベント定義ファイル
ローカライズ可能な要素が含まれる翻訳ファイル
第6.5.1項で説明したパッケージ・ファイルに加えて、OPSSデプロイメント・ディスクリプタ・ファイルに特定の監査登録パラメータを構成することもできます。このディスクリプタ・ファイルもEARでパッケージ化されます。これらのファイルは、アプリケーションのデプロイ時に、監査登録サービスによって自動的に処理されます。
詳細は、25.4項を参照してください。
次の推奨事項は、JAAS認可を使用するJava EEアプリケーションにのみ当てはまります。このようなアプリケーションには、Oracle Application Development Frameworkアプリケーション、Oracle SOAアプリケーション、Oracle WebCenterアプリケーションなどがあります。標準認可を使用するJava EEアプリケーションは、この推奨事項の対象外です。標準認可を使用するJava EEアプリケーションのデプロイは、「標準Java EEアプリケーションのデプロイ」を参照してください。
アプリケーションをデプロイするための推奨ツールはFusion Middleware Controlです。後述の項で説明する操作を実行するユーザーは、LDAPリポジトリでスキーマをシードする権限など、適切な権限を持っている必要があります。
第5.2.1項「新しい本番環境の設定」の説明に従って本番環境が設定されていることを前提とします。
|
重要事項: 本番環境ではファイルベース・ストアは推奨されません。 |
新しい本番環境への移行は、次の段階に分かれています。
移行はセキュリティ・データのバックアップおよびリカバリにも使用できます。セキュリティ・データをバックアップするには、XMLベース・ストアに移行します。セキュリティ・データをリカバリするには、保存済のXMLベース・ストアからターゲットのセキュリティ・ストアに移行します。
本番環境でのプロバイダ(ポリシー・プロバイダおよび資格証明プロバイダ以外)の構成は、テスト環境で使用した構成と同じものとする必要があります。この場合のタスクとして、次のものが考えられます。
アイデンティティ・ストアの構成(WebLogic管理コンソールやWLSTコマンドmigrateSecurityStoreを使用して必要なユーザーやグループのプロビジョニングを行う場合など)。この最後のコマンドの詳細は、「migrateSecurityStoreを使用したアイデンティティの移行」を参照してください。
テスト環境で実行したあらゆる特定のプロバイダの構成
|
注意: Oracle WebLogic Serverには、 |
アイデンティティ・データは、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに移行できます。この移行が必要になる状況の例として、ファイルベースのアイデンティティ・ストアを使用するテスト環境からLDAPベースのアイデンティティ・ストアを使用する本番環境に移行する場合があります。
このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
このコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。
WLSTコマンドを実行するためのプラットフォーム固有の要件については、第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。
スクリプト・モードおよびインタラクティブ・モードの構文
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"])
引数(dstLdifFile以外はすべて必須)の意味は次のとおりです。
configFileでは、構成ファイルjps-config.xmlの相対パスまたは絶対パスを指定します。
srcでは、引数configFileで渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。このコマンドでWLS組込みLDAPを移行元ストアにすることはできません。
dstでは、引数configFileで渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。移行先ストアは、LDAPベースのアイデンティティ・ストアにする必要があります。サポートされているタイプの一覧は、第3.1.1項「アイデンティティ・ストアのタイプとWebLogic認証プロバイダ」を参照してください。
dstLdifFileでは、作成したLDIFファイルの相対パスまたは絶対パスを指定します。移行先が組込みLDAPなど、LDAPベースのOracle Internet Directoryストアである場合にのみ適用されます。LDIFファイルはLDAPサーバーにはインポートされず、通常は手動編集が必要です。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
LDIFファイルを生成した後、通常は、このファイルを手動で編集して、LDIFファイルの最終的なインポート先となるLDAPリポジトリの属性をカスタマイズします。
|
重要: 出力LDIFファイルの各ユーザーのパスワードは、実際のユーザー・パスワードではなく、仮の文字列weblogicです。移行先がLDAPベースのOracle Internet Directoryストアの場合、仮の文字列はchangeです。 LDIFファイルをターゲットのLDAPストアにインポートする前に、セキュリティ管理者がこのファイルを編集して、仮のパスワードを実際のパスワードに変更する必要があります。 |
本番環境では、OPSSセキュリティ・ストア(ポリシー、資格証明およびキー・ストア)をLDAPベースのOracle Internet Directoryに再関連付けすることを強くお薦めします。テスト用のポリシー・ストアおよび資格証明ストアもLDAPであったとしても、本番用のLDAPはテスト用のLDAPとは別のものとすることが前提となっています。テスト用のOPSSセキュリティ・ストアがファイルベースであったとしても、権限に重複したパーミッションがないことを確認してください。「ポリシー管理」の注意を参照してください。
ポリシー、資格証明およびキーの移行は、アプリケーションのデプロイ時に自動的に処理できる他、アプリケーションのデプロイ前またはデプロイ後にWLSTコマンドmigrateSecurityStoreを使用して実行することもできます(詳細は、次の各項を参照してください)。
|
重要事項: サーバーの停止と再起動を必要としない、アプリケーションのホット・デプロイを行う場合、セキュリティ・ストアにそのアプリケーションと同じ名前のストライプが含まれていない場合にかぎり、ファイル |
WebLogic Serverにデプロイしたすべてのアプリケーションについて、(アプリケーション移行に関する特定の設定とは関係なく)ポリシーと資格証明の自動移行を無効にするには、システム・プロパティjps.deployment.handler.disabledをTRUEに設定します。
アプリケーションを本番環境にデプロイする際、管理者は次の点を把握している必要があります。
アプリケーションEARにパッケージ化したポリシーまたは資格証明がテスト環境で変更されているかどうか
この点を把握していることを前提として、アプリケーションを本番環境にデプロイする手順は次のとおりです。
Fusion Middleware Controlで次のオプションを使用して、アプリケーションのEARファイルを本番環境にデプロイします。
ポリシー(アプリケーションまたはシステム)がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション・ポリシー移行」領域で「無視」オプションを選択して、デプロイ時にポリシーを移行するオプションを無効にします。ポリシーが変更されていない場合は、「追加」を選択します。
|
注意: テスト環境でのアプリケーション・ロールの変更がテスト用のエンタープライズ・グループへのマッピングにまで及んでいても、「追加」(アプリケーション・ポリシーの移行)を選択し、同時に「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」チェック・ボックスを選択できます。 この組合せを選択した場合、アプリケーション・ポリシーは移行されますが、テスト用のエンタープライズ・グループへのマッピングは無視されます。後述のステップ3で、アプリケーション・ロールを本番用のエンタープライズ・グループに再マップする必要があります。 |
資格証明がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション資格証明移行」領域で「無視」オプションを選択して、デプロイ時に資格証明を移行するオプションを無効にします。資格証明が変更されていない場合は、「追加」を選択します。
次の説明に従い、スクリプトmigrateSecurityStoreを使用して、変更済のデータを移行します。
アプリケーション・ポリシーの移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPにアプリケーション・ポリシーおよびシステム・ポリシーを移行します。「migrateSecurityStoreを使用したポリシーの移行」のサンプルを参照してください。
アプリケーション資格証明の移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPに資格証明を移行します。「migrateSecurityStoreを使用した資格証明の移行」のサンプルを参照してください。
いずれの場合も、必要に応じ、Fusion Middleware Controlを使用してアプリケーション・ロールを本番用のエンタープライズ・グループにマップします。
Fusion Middleware Controlを使用して、本番環境の管理資格証明が有効であることを確認します。特に、テスト用のパスワードと本番用のパスワードを照合してください。必要に応じて、本番用のデータを適宜変更します。
|
注意: アプリケーションのデプロイでポリシーを移行したときに、GUIDを再作成しなくても元のGUIDが保持されるようにアプリケーションを構成する方法があります。 この設定は、手動でのみ構成できます。詳細は、第18.5.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.credstore">
<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.credstore"/>
</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.credstore"> <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.credstore"/> </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のパッチを適用する必要がありますOracle Internet Directoryパッチのリストは、第9章「LDAPベースのOPSSセキュリティ・ストアの使用」を参照してください。 |
一括コマンドを使用して移行元の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章「バルク操作の実行」を参照してください。
この項では、様々なタイプの監査コンテンツを移行する方法について説明します。
監査メタデータおよび監査ポリシーの移行
監査メタデータは、属性グループ、カテゴリ、イベントなどの監査アーティファクトで構成されています。この情報は監査メタデータ・ストアに保管されます。
移行元コンテキストから移行先コンテキストへの監査メタデータの移行には、WLSTコマンドmigrateSecurityStoreを使用します。いずれのコンテキストのメタデータも、XML、データベースまたはLDAPベースのストアに保管されます。このため、たとえば次の移行を実行できます。
監査メタデータをXMLファイルからドメインセキュリティ・ストアに移行する。
監査メタデータをドメイン・セキュリティ・ストアからXMLファイルに移行する。
次のことに留意してください:
監査メタデータのタイプは、システム定義とコンポーネント定義の2種類あります。
監査メタデータの移行時に、移行先ストアの既存のデータを上書きするか保持するかを選択できます。選択に基づき、後述のように、migrateSecurityStoreは特定のルールに従って、移行先ストアのシステムおよびコンポーネント定義を置き換える方法を決定します。
次の構文を使用して、監査メタデータを移行します。
migrateSecurityStore(type="auditStore", configFile="jps_config_file_location", src="sourceContext", dst="destinationContext" [,overWrite="{true|false}"])
このコマンドを使用して、移行元コンテキスト内に構成された監査サービスのメタデータを移行先コンテキストの監査サービスに移行できます。ソースおよびターゲット・コンテキストの監査メタデータは、XML、LDAPおよびDBベース・ストア内にある可能性があります。
このパラメータは次のとおりです。
configFileでは、構成ファイルの絶対パスまたは相対パスによる場所を指定します。通常、この構成ファイルはスクリプトで使用するためにのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのjps-contextがあります。
srcでは、引数configFileで渡す構成ファイル内のjps-contextの名前を指定します。これはソース・メタデータ・ストアです。
dstでは、引数configFileで渡す構成ファイル内の別のjps-contextの名前を指定します。これはターゲット・メタデータ・ストアです。
overWriteはターゲット・ストア内の既存のメタデータを上書きするかどうかを示します。trueは既存のメタデータを上書きし、falseは特定の条件に合致しないかぎり既存のメタデータを上書きしません。オプションで、デフォルトはfalseです。overWriteフラグは、次のように解釈されます。
システム定義はフラグの値にかかわらず上書きされません。
overwrite=trueの場合、ターゲット・ストア内のコンポーネント定義はソース・ストアの定義で置き換えられます。
overwrite=falseの場合、ソースおよびターゲット・ストア内のコンポーネント定義のメジャーおよびマイナー・バージョンが比較されます。メジャー・バージョンが同じで、ソース・コンポーネント定義内のマイナー・バージョンが高い場合、ターゲット・ストア内のコンポーネント定義はソース・ストアの定義で置き換えられます。そうでない場合、上書きはスキップされます。
監査レコードの移行
通常、テスト環境の監査データ・レコードを本番環境に移行することはありませんが、移行する場合は、データベースのインポート/エクスポート・ユーティリティを使用します。詳細は、第14.6.5項「データのインポートとエクスポート」を参照してください。
この項では、キーストア・アーティファクト(つまり、キーおよび証明書)をキーストア間で移行する方法を説明します。内容は次のとおりです。
キーストア・アーティファクト(キーおよび証明書)を次の2つの異なるコンテキストで移行できます。
移行元キーストアと移行先キーストアが同じドメインに含まれている場合。つまり、移行元キーストアと移行先キーストアで同じ暗号化鍵が使用される場合。
移行元キーストアと移行先キーストアが異なるドメインに含まれている場合。つまり、移行元キーストアと移行先キーストアで異なる暗号化鍵が使用される場合。
migrateSecurityStore WLSTコマンドを使用して、セキュリティ・アーティファクトを移行します。ドメイン内の移行の場合、このコマンドによって単一の構成ファイルが取得されます。ドメイン間の移行の場合は、次に説明するように別々のファイルが必要です。
キーおよび証明書を、両方のストアが同じドメイン内に含まれる場合にmigrateSecurityStoreを使用して移行するには、構成ファイルを作成して、移行元および移行先のサービス・インスタンスを指定します。次に、WLSTコマンドmigrateSecurityStoreを、適切なオプションを指定して使用します(この項の最後のサンプルを参照してください)。
キーストアが同一ドメイン内に含まれる場合は、移行元サービス・コンテキストと移行先サービス・コンテキストの指定に1つの構成ファイルで十分です。
次の構成ファイルのサンプル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.credstore">
<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.credstore"/>
</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")
移行元キーストアと移行先キーストアが異なるドメインに含まれる場合にキーストア・データを移行するには、2つの異なる構成ファイルを使用する必要があります。これは、キーストアの暗号化に使用する暗号化鍵が異なれば、ブートストラップ資格証明ストアも異なるからです。
WLSTコマンドmigrateSecurityStoreを使用する場合は、次のようになります。
構成ファイル内の移行元キーストアのコンテキストが、個別パラメータsrcConfigFileとして渡されます。
第6.6.4.2項で説明したドメイン内の移行と同じように、構成ファイル内の移行先キーストアのコンテキストが、パラメータConfigFileとして渡されます。
例
テスト用の(移行元)LDAPストアから本番用の(移行先)LDAPストアにすべてのキーと証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。
>migrateSecurityStore(type="keyStore", srcConfigFile="/source_domain/config/fmwconfig/jps-config.xml", configFile="/target_domain/config/fmwconfig/jps-config.xml", src="ksSrc", dst="ksDst")
