6 セキュア・アプリケーションのデプロイ

通常、Oracle WebLogic Server管理コンソールまたはOracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用して、アプリケーションをOracle WebLogic Serverにデプロイします。WebLogic Serverに認識されている場所にビットを設定することによって、サーバーを再起動せずにアプリケーションを起動することもできます。このようなアプリケーション起動は、ホット・デプロイとして知られています。

この章での推奨事項は、OPSSを使用するJava EEアプリケーションに当てはまります。

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

• Oracle ADFアプリケーションの開発

• デプロイのためのツールの選択

• 新しい環境へのOracle ADFアプリケーションのデプロイ

• 標準Java EEアプリケーションのデプロイ

• 監査対応アプリケーションのデプロイ

• テスト環境から本番環境への移行

関連項目:

『Oracle Fusion Middlewareの管理』のアプリケーションのデプロイ

Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

「Oracle ADFアプリケーションの保護」

OPSSを使用するためのJava EEアプリケーションの構成

Oracle ADFアプリケーションの開発

Oracle Application Development Framework (Oracle ADF)アプリケーションをデプロイする場合、次のようにします。

• JDeveloperを使用してアプリケーションを開発し、Oracle ADFウィザードを使用してアプリケーションのセキュリティを構成します。

• JDeveloperを使用し、テスト・サイクルでアプリケーションのデプロイ先となる統合WebLogic Serverに、アプリケーションのユーザー、ロール、ポリシーおよび資格証明をコピーします。

• アプリケーションのポリシーおよび資格証明をパックしたアプリケーションのエンタープライズ・アーカイブ(EAR)ファイルを作成します。

• Fusion Middleware Controlを使用して、EARファイルをWebLogic Serverにデプロイします。

図6-1は、Oracle ADFアプリケーションを開発するワークフローを示しています。

図6-1 Oracle ADFアプリケーションを開発するためのワークフロー

「図6-1 Oracle ADFアプリケーションを開発するためのワークフロー」の説明

開発段階では、Oracle JDeveloperを使用してアプリケーションを組込みWebLogic Serverにデプロイします。テスト環境または本番環境に移行したアプリケーションは、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)またはWebLogic Server管理コンソールあるいはホット・デプロイを使用してデプロイします。

アプリケーションをデプロイするための推奨方法は、プラットフォーム、アプリケーションのタイプ、およびそのアプリケーションが開発中フェーズと開発後フェーズのどちらのフェーズにあるかによって異なります。

関連項目:

「Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ」

デプロイのためのツールの選択

表6-1に、Java EEアプリケーションのデプロイに使用するツールを示します。

表6-1 Java EEアプリケーションをデプロイするためのツール

Java EEアプリケーション	使用ツール
Oracle ADF以外	WebLogic Server管理コンソール、Fusion Middleware Control。推奨ツールはWebLogic Server管理コンソールです。
Oracle ADF	Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)。推奨ツールはFusion Middleware Controlです。

関連項目:

「Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ」

Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ

この項では、OPSSを使用するJava EEアプリケーションをFusion Middleware Controlを使用してデプロイする際に使用可能なセキュリティ構成について説明します。

アプリケーション・セキュリティの構成ページに表示されるコンテンツは、EARファイルにパッケージ化されている内容により異なります。

• アプリケーション・ポリシーを設定したjazn-data.xmlをEARファイルにパッケージ化している場合、ページにはポリシーの移行セクションが表示されます。

• cwallet.ssoファイルに収めた資格証明をEARファイルにパッケージ化している場合、ページには資格証明の移行セクションが表示されます。

• これらのファイルのいずれもEARファイルに含まれていない場合、ページにはデフォルトのJava EEセキュリティ・オプションが表示されます。

このページの設定は、セキュリティ・ストアへの(アプリケーションEARファイルにパックされた)アプリケーションのポリシーおよび資格証明の移行を制御します。

デプロイ時のアプリケーション・ポリシーの移行

デプロイ時にパックしたアプリケーション・ポリシーを移行するには、アプリケーションを1つのWebLogic Serverにのみデプロイします。パックしたポリシーとともにアプリケーションを複数の管理対象サーバーにデプロイする場合は、デプロイメントに管理サーバーを含める必要があるため、パックしたポリシーでsystem-jazn-data.xmlドメイン・ファイルが更新されます。

• アプリケーションを初めてデプロイする場合、セキュリティ・ストアにアプリケーション・ポリシーを移行するため、「アプリケーション・ポリシー移行」領域で「追加」を選択します。

  なんらかの理由で移行しない場合は、「無視」を選択します。オプションの「上書き」も使用できます。

• 以前のデプロイでアプリケーション・ポリシーが移行済であることを前提としてアプリケーションを再デプロイしている場合、パックしたポリシーをドメイン内のポリシーにマージするには「追加」を選択し、ポリシーを移行しないようにするには「無視」を選択します。

  「無視」オプションは、アプリケーションを再デプロイする場合、または以前のデプロイの際に変更したセキュリティ・ストアの内容を保持する場合に選択します。

• 「追加」を選択した場合は、移行する権限付与およびロールを指定します。基本的な相違点は、Oracle ADFアプリケーションのロールおよび権限付与と、開発時のみのロールおよび権限付与との差です。

  Oracle ADFアプリケーションのロールおよび権限付与を移行して、開発時のみのセキュリティ・ロールおよび権限付与を移行しないようにするには、次を選択します: アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。これは、本番環境へのデプロイ時に選択します。アプリケーションをデプロイした後でアプリケーション・ロールをエンタープライズ・グループにマップする必要があります。

• 「追加」を選択した場合は、「アプリケーション・ストライプID」テキスト・フィールドにそのストライプの名前を入力して、アプリケーション・ポリシーの移行先とする特定のストライプ(アプリケーション名を名前としたデフォルトのストライプとは異なるストライプ)を指定します。

• 何も指定しない場合、デフォルト設定は「追加」(デプロイの場合)と「無視」(再デプロイの場合)です。

デプロイ時のアプリケーション資格証明の移行

• アプリケーションを初めてデプロイする場合、資格証明ストアにアプリケーション資格証明を移行します。そのためには、「アプリケーション資格証明移行」領域で「追加」を選択します。

• 資格証明を移行しないようにするには「無視」(デフォルト値)を選択します。

  注意:

  資格証明の移行を無視すると、資格証明を使用するアプリケーション・コードが動作しない場合があります。マップとキーが同じで値が異なる資格証明を作成した場合は「無視」を選択します。

• 「上書き」がサポートされるのは、WebLogic Serverが開発モードで稼働している場合のみです。

新しい環境へのOracle ADFアプリケーションのデプロイ

テスト環境または本番環境にOracle ADFアプリケーションを移行するとき通常は、Fusion Middleware Controlを使用してデプロイし、フレームワークで提供されるADFのセキュリティ機能すべてを活用します。

次の各項では、アプリケーションを新しい環境に移行する場合に含まれるタスクについて説明します。

• テスト環境へのデプロイ

• テスト環境から本番環境への移行

テスト環境へのデプロイ

ファイル・セキュリティ・ストアを使用するアプリケーションをデプロイする前に、権限付与に重複したパーミッションが含まれていないことを確認します。権限付与でパーミッションが重複している(パーミッションの名前とクラスが同じ)場合は、移行でエラーがレポートされ、停止します。解決するには、jazn-data.xmlファイルを編集して、重複しているパーミッションを削除します。

Fusion Middleware Controlを使用してOracle ADFアプリケーションをデプロイするときには次のプロセスが発生します。

• アプリケーションとともにパックされたアプリケーション・ポリシーは、セキュリティ・ストアに自動的に移行されます。

• アプリケーションとともにパックされたアプリケーション資格証明は、資格証明ストアに自動的に移行されます。

• 移行中に、LDAPリポジトリへのアクセスに必要なブートストラップ資格証明が作成されます。

アプリケーションとともにパックされたアイデンティティは移行されません。認証プロバイダを(WebLogic Server管理コンソールを使用して)構成し、必要に応じて、アイデンティティを更新して、エンタープライズ・ユーザーおよびグループにアプリケーション・ロールを(Fusion Middleware Controlを使用して)マップする必要があります。

LDAPセキュリティ・ストアがあるドメインにデプロイし、アプリケーション・データの整合性を保持する場合は、アプリケーションをクラスタ・レベルでデプロイするか、1つの管理対象サーバーにのみデプロイすることをお薦めします。

アプリケーションを複数の管理対象サーバーにデプロイするときは、データが予期したとおりに移行されるよう管理サーバーを含めます。

関連項目:

デプロイ後の一般的な管理タスク

デプロイ後の一般的な管理タスク

アプリケーションのデプロイ後に、Fusion Middleware ControlまたはWebLogic Server管理コンソールを使用して、次を実行します。

• セキュリティ・プロバイダの管理

• アプリケーション・ポリシーの作成およびカスタマイズ

• アプリケーション・ロールの作成およびカスタマイズ

• システム・ポリシーの管理

• 資格証明の管理

• キーストアの管理

• 監査データの管理

Fusion Middleware Controlを使用して、本番モードで実行しているサーバーからアプリケーションをアンデプロイすると、アプリケーション・ポリシーがセキュリティ・ストアから削除されます。他のツールを使用してアプリケーションをアンデプロイする場合は、そのポリシーを手動で削除する必要があります。

資格証明は、アプリケーションをアンデプロイしても削除されません。

関連項目:

Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成

アプリケーション・ポリシーの管理

アプリケーション・ロールの管理

システム・ポリシーの管理

Fusion Middleware Controlを使用した資格証明の管理

Fusion Middleware Controlを使用したキーストアの管理

監査ストアの管理

標準Java EEアプリケーションのデプロイ

OPSSを使用せずにJavaの標準認可を使用するJava EEアプリケーションを保護するには、WebLogic Server管理コンソールまたはWLSTコマンドを使用して管理面で保護する方法と、デプロイメント・ディスクリプタを使用してプログラムで保護する方法の2通りがあります。

WebLogic ServerにデプロイしたJava EEアプリケーションはWebLogicリソースとなるため、他のWebLogicリソースの場合と同じ方法で、アプリケーションにセキュリティを設定します。

関連項目:

Oracle WebLogic Serverロールおよびポリシーによるリソースの保護

• アプリケーション・リソース

• WebアプリケーションおよびEJBリソースの保護のオプション

Oracle WebLogic Server管理コンソール・オンライン・ヘルプ:

• ロールとポリシーを使用したリソースの保護

Oracle WebLogic Server WebLogic Webサービスの保護:

• Webサービス・セキュリティの概要

WebLogic Securityサービスを使用したアプリケーションの開発:

• Webアプリケーションの保護。特に、Webアプリケーションでの宣言セキュリティの使用に関する項と関連性があります

• Enterprise JavaBeans (EJB)の保護

• Javaセキュリティを使用したWebLogicリソースの保護

監査対応アプリケーションのデプロイ

監査対応コンポーネントとは、Oracle Fusion Middleware監査フレームワークと統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントのことです。

このフレームワークを使用するには、デプロイ時にアプリケーションを登録する必要があります。

登録

アプリケーションEARファイルにパッケージ化されたOPSSデプロイメント・ディスクリプタ・ファイルで監査登録パラメータを構成します。ファイルは、アプリケーションのデプロイ時に監査登録によって自動的に処理されます。

パッケージ要件

次の構成ファイルは、アプリケーションEARファイルにパッケージ化します。

• アプリケーションの監査可能イベントを記述するイベント定義ファイル

• ローカライズ可能な要素が含まれる翻訳ファイル

関連項目:

監査データの移行

監査定義ファイルの作成

監査サービスへのアプリケーションの登録

Oracle Fusion Middleware監査フレームワークの概要

テスト環境から本番環境への移行

次の推奨事項は、Oracle ADFアプリケーション、サービス指向アーキテクチャ(SOA)アプリケーション、Oracle WebCenterアプリケーションなどのJava Authorization and Authentication Services (JAAS)認可を使用するJava EEアプリケーションに当てはまりますが、標準認可を使用するJava EEアプリケーションには当てはまりません。

アプリケーションをデプロイするための推奨ツールはFusion Middleware Controlであるため、ユーザーは、LDAPリポジトリでスキーマをシードするパーミッションなど、適切なパーミッションを持っている必要があります。

本番環境ではファイル・セキュリティ・ストアは推奨されません。

本番環境への移行では、次を実行します。

• アイデンティティの移行

• ポリシーおよび資格証明の移行

• 監査データの移行

• 「migrateSecurityStoreを使用したキーおよび証明書の移行」

アイデンティティの移行

テスト環境での認証プロバイダの構成は、本番環境で複製する必要があります。この場合のタスクとして、次のものが考えられます。

• WebLogic Server管理コンソールを使用した認証プロバイダの構成とユーザーおよびグループのプロビジョニング。

• テスト環境で使用される特定のプロバイダ構成の本番環境での設定。

migrateSecurityStoreを使用したアイデンティティの移行

たとえば、ファイル・アイデンティティ・ストアを使用するテスト環境からLDAPアイデンティティ・ストアを使用する本番環境に移行する場合、migrateSecurityStore WLSTコマンドを使用してソース・リポジトリからターゲット・リポジトリにアイデンティティ・データを移行します。

このコマンドは実行中のサーバーに接続しなくても動作します。configFile引数に渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するだけです。

アイデンティティを移行するには、次のいずれかを使用します。

migrateSecurityStore -type idStore
                     -configFile jpsConfigFileLocation
                     -src srcJpsContext
                     -dst dstJpsContext
                     [-dstLdifFile LdifFileLocation]
                     [-overwrite trueOrfalse]

migrateSecurityStore(type="idStore", 
                     configFile="jpsConfigFileLocation", 
                     src="srcJpsContext", 
                     dst="dstJpsContext", 
                     [dstLdifFile="LdifFileLocation"]
                     [,overwrite="trueOrfalse"])

説明:

• configFileでは、jps-config.xml構成ファイルの相対パスまたは絶対パスを指定します。

• srcでは、configFile引数に渡す構成ファイルで、ソース・ストアを指定しているコンテキストの名前を指定します。組込みLDAPサーバーをソース・ストアにすることはできません。

• dstでは、configFile引数に渡す構成ファイルで、ターゲット・ストアを指定している別のコンテキストの名前を指定します。ターゲット・ストアはLDAPである必要があります。サポートされているタイプのリストは、「アイデンティティ・ストア・タイプとWebLogic Server認証プロバイダ」を参照してください。

• dstLdifFileでは、作成したLDAPデータ交換形式(LDIF)ファイルの相対パスまたは絶対パスを指定します。ターゲット・ストアがLDAPである場合にのみ適用されます。LDIFファイルはLDAPサーバーにはインポートされず、手動による編集が必要であることに注意してください。

• overwriteでは、ターゲット・ストア内のデータを上書きするかどうかを指定します。ターゲット・データを上書きする場合はtrueに設定します。ターゲット・データを上書きしない場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

srcおよびdstに渡すコンテキストは、構成ファイルで定義し、名前が一意である必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

生成されたLDIFファイルでのパスワードはすべて文字列weblogicに設定され、ターゲットがLDAPの場合は文字列changeに設定されます。LDIFファイルをターゲットLDAPストアにインポートする前に、これらのパスワードを実際のパスワードに変更します。

ポリシーおよび資格証明の移行

本番環境では、セキュリティ・ストアをLDAPストアまたはDBストアに再関連付けすることをお薦めします。

この項では、アプリケーションのデプロイ時にポリシーおよび資格証明を移行する方法について説明します。デプロイ後のセキュリティ・データの移行の詳細は、「migrateSecurityStoreを使用したポリシーの移行」および「migrateSecurityStoreを使用した資格証明の移行」を参照してください。

アプリケーションのホット・デプロイを行う場合、セキュリティ・ストアにそのアプリケーションと同じ名前のストライプが含まれていない場合にかぎり、jazn-data.xmlファイルのデータのセキュリティ・ストアへの移行が実行されます。特に、アプリケーションのホット・デプロイを再実行する場合、jazn-data.xmlファイルに加えられた変更はセキュリティ・ストアに移行されません。

WebLogic Serverにデプロイしたすべてのアプリケーションについて、(アプリケーション移行に関する特定の設定に関係なく)ポリシーおよび資格証明の移行を無効にするには、システム・プロパティjps.deployment.handler.disabledをtrueに設定します。

移行時にGUIDを保持するには、jps.approle.preserveguidパラメータを設定します。

アプリケーションをテスト環境から本番環境に移行する際、次の点を把握していることがきわめて重要です。

アプリケーションEARファイルにパックしたポリシーまたは資格証明がテスト環境で変更されているかどうか

これを踏まえて、アプリケーションを本番環境にデプロイするには、次の手順を実行します。

1. Fusion Middleware Controlで次のオプションを使用して、アプリケーションEARファイルを本番環境にデプロイします。

   • ポリシー(アプリケーションまたはシステム)がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション・ポリシー移行」領域で「無視」を選択して、デプロイ時にポリシーを移行するオプションを無効にします。それ以外の場合は、「追加」を選択します。

     テスト環境でアプリケーション・ロールのマッピングが変更されている場合でも、「追加」を選択し、同時に「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」を選択できます。この組合せを選択した場合、アプリケーション・ポリシーは移行されますが、テスト用のエンタープライズ・グループへのマッピングは無視されます。後で、アプリケーション・ロールを本番用のエンタープライズ・グループに再マップする必要があります。

   • 資格証明がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション資格証明移行」領域で「無視」オプションを選択して、デプロイ時に資格証明を移行するオプションを無効にします。それ以外の場合は、「追加」を選択します。

2. migrateSecurityStoreコマンドを使用して、変更済のデータを移行します。

   • アプリケーション・ポリシーの移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPにアプリケーション・ポリシーおよびシステム・ポリシーを移行します。手順の詳細は、「migrateSecurityStoreを使用したポリシーの移行」の例を参照してください。

   • アプリケーション資格証明の移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPに資格証明を移行します。手順の詳細は、「migrateSecurityStoreを使用した資格証明の移行」の例を参照してください。

3. 必要に応じ、Fusion Middleware Controlを使用してアプリケーション・ロールを本番用のエンタープライズ・グループにマップします。
4. Fusion Middleware Controlを使用して、本番環境の管理資格証明が有効であること、特にテスト用のパスワードと本番用のパスワードを確認します。必要な場合は、本番用のデータを適宜変更します。

migrateSecurityStoreを使用したポリシーの移行

デフォルトでは、migrateSecurityStoreコマンドによってGUIDが再作成されるため、大量のポリシーを移行するのに長時間を要することがあります。したがって、テスト環境から本番環境への移行時には、一括操作を使用する代替手順によるポリシーおよび資格証明の移行を検討してください。セキュリティ・ストアのバックアップの詳細は、「LDAPセキュリティ・ストアのバックアップとリカバリ」を参照してください。

migrateSecurityStoreを使用してポリシーを移行するには、ソースおよびターゲットが指定された構成ファイルをアセンブルします。

次に示すt2p-policies.xmlという構成ファイルの完全な例は、LDAP、データベースおよびファイルの各リポジトリ内のポリシー・ソースの指定と、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 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 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 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 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>

 <!-- target LDAP policy store instance -->
 <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. OID with OVD, if your target LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your target 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>
 
<!-- target DB policy store instance -->
 <serviceInstance provider="db.policystore.provider" name="policystore.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values
 according to your target 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 target 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 target LDAPs or DBs-->
 <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.credstore">
  <description>Replace location with the full path of the directory where the cwallet.sso file is located; typically found in targetDomain/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="LDAPtargetContext">
 <serviceInstanceRef ref="policystore.ldap.target"/>
 </jpsContext>
 
<jpsContext name="DBtargetContext">
 <serviceInstanceRef ref="policystore.db.target"/>
 </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というコンテキストがファイルに含まれていることに注意してください。さらに、例のマップ名とキー名の各ペアに対して、次のようにaddBootStrapCredential WLSTコマンドを使用して対応するブートストラップ資格証明を指定する必要があります。

wls:/offline> addBootStrapCredential(jpsConfigFile='jps-config.xml',
 map='myMapName', key='myKeyName', username='UserName',
 password='Password')

UserNameおよびPasswordには、ターゲット・データベースにアクセスするユーザー・アカウントの名前とパスワードを指定します。

migrateSecurityStoreを使用したポリシーの移行の例

migrateSecurityStoreの使用方法を示す後述の例は、次の点を前提としています。

• コマンドが実行されるターゲット・システムのディレクトリにt2p-policies.xmlファイルが格納されています。

• テスト環境と本番環境で、LDAPまたはDBシステム・ポリシーのディレクトリ構造が同じです。異なる場合は、本番環境のシステム・ポリシー・ディレクトリを、テスト環境の対応する構造に合せて手動で再構築してからコマンドを使用します。

テスト用(ソース)のLDAPストアから本番用(ターゲット)のLDAPストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="policyStore",
                      configFile="t2p-policies.xml",
                      src="LDAPsourceContext",
                      dst="LDAPtargetContext")

テスト用(ソース)のファイル・ストアから本番用(ターゲット)のLDAPストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="policyStore",
                      configFile="t2p-policies.xml",
                      src="XMLsourceContext",
                      dst="LDAPtargetContext")

テスト用(ソース)のDBストアから本番用(ターゲット)のDBストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="policyStore",
                      configFile="t2p-policies.xml",
                      src="DBsourceContext",
                      dst="DBtargetContext")

migrateSecurityStoreを使用した資格証明の移行

migrateSecurityStoreコマンドによってGUIDが再作成されるため、大量の資格証明を移行するのに長時間を要することがあります。したがって、テスト環境から本番環境への移行時には、一括操作を使用する代替手順によるポリシーおよび資格証明の移行を検討してください。ストアのバックアップの詳細は、「LDAPセキュリティ・ストアのバックアップとリカバリ」を参照してください。

migrateSecurityStoreを使用して資格証明を移行するには、ソースおよびターゲットが指定された構成ファイルをアセンブルします。

次に示すt2p-credentials.xmlという構成ファイルの完全な例は、LDAP、DBおよびファイルの各リポジトリ内の資格証明ソースの指定と、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 credential provider</description>
 </serviceProvider>
 
 <serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE">
 <description>LDAP credential provider</description>
 </serviceProvider>

<serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider" name="db.credentialstore.provider" type="CREDENTIAL_STORE">
 <description>DB credential provider</description>
 </serviceProvider>

</serviceProviders>
 
<serviceInstances>
 <!-- Source file 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 source credential store cwallet.sso is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
 </serviceInstance>
 
<!-- Source LDAP 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 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>

 <!-- target LDAP credential store instance -->
 <serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your target 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>
 
<!-- target DB credential store instance -->
 <serviceInstance provider="db.credentialstore.provider" name="credential.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your target 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 target 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 target 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 targetDomain/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="LDAPtargetContext">
 <serviceInstanceRef ref="credential.ldap.target"/>
 </jpsContext>
 
<jpsContext name="DBtargetContext">
 <serviceInstanceRef ref="credential.db.target"/>
 </jpsContext>

 <!-- Do not change the name of the next context -->
 <jpsContext name="bootstrap_credstore_context">
 <serviceInstanceRef ref="bootstrap.credstore"/>
 </jpsContext>
 </jpsContexts>
</jpsConfig>

このシナリオのコマンド構文は、migrateSecurityStoreを使用したドメイン間での1つの資格証明マップの移行を参照してください。

LDAPまたはDBのストアが移行対象となっているため、cwallet.ssoブートストラップ資格証明ファイルが格納されているディレクトリを指定するbootstrap_credstore_contextというコンテキストがファイルに含まれていることに注意してください。

migrateSecurityStoreを使用した資格証明の移行の例

次に示すmigrateSecurityStoreの使用例では、コマンドが実行されるターゲット・システムのディレクトリにt2p-credentials.xmlファイルが格納されていることを前提とします。

テスト用(ソース)のLDAPストアから本番用(ターゲット)のLDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="credStore",
                      configFile="t2p-credentials.xml",
                      src="LDAPsourceContext",
                      dst="LDAPtargetContext")

テスト用(ソース)のファイル・ストアから本番用(ターゲット)のLDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="credStore",
                      configFile="t2p-credentials.xml",
                      src="FileSourceContext",
                      dst="LDAPtargetContext")

テスト用(ソース)のDBストアから本番用(ターゲット)のDBストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="credStore",
                      configFile="t2p-credentials.xml",
                      src="DBSourceContext",
                      dst="DBtargetContext")

監査データの移行

監査データは、コンポーネント・イベント定義、属性表マッピングおよび監査ポリシーで構成されており、この情報は監査ストアにあります。

次の構文でmigrateSecurityStore WLSTコマンドを使用し、ソース・リポジトリとターゲット・リポジトリ間で監査データを移行します。

migrateSecurityStore(type="auditStore",
                     configFile="jps_config_file_location",
                     src="sourceContext",
                     dst="targetContext"
                     [,overWrite="{true|false}"])

説明:

• configFileでは、構成ファイルの絶対パスまたは相対パスによる場所を指定します。この構成ファイルは移行用にのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのコンテキストが含まれます。

• srcでは、configFile引数に渡す構成ファイル内のコンテキストの名前を指定します。これはソース・データ・ストアです。

• dstでは、configFile引数に渡す構成ファイル内の別のコンテキストの名前を指定します。これはターゲット・データ・ストアです。

• overWriteでは、ターゲット・ストア内のデータを上書きするかどうかを指定します。常にデータを上書きする場合はtrueに設定します。特定の条件を満す場合を除いてデータを上書きしない場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。次の点に注意してください:

  • システム定義はフラグの値にかかわらず上書きされません。

  • overwriteがtrueの場合、ターゲット・ストアのコンポーネント定義はソース・ストアの定義で置き換えられます。

  • overwriteがfalseの場合、ソース・ストアおよびターゲット・ストアのコンポーネント定義のバージョンが比較されます。メジャー・バージョンが同じで、ソース・コンポーネント定義のマイナー・バージョンの方が高い場合、ターゲット・ストアのコンポーネント定義はソース・ストアの定義で置き換えられます。そうでない場合、上書きはスキップされます。

migrateSecurityStoreを使用したキーおよび証明書の移行

キーおよび証明書は、次の2つの異なるシナリオで移行します。

• ソースおよびターゲットのキーストアが同じドメインにある場合(ソースおよびターゲットのキーストアで同じ暗号化キーが使用される場合)。

• ソースおよびターゲットのキーストアが異なるドメインにある場合(ソースおよびターゲットのキーストアで異なる暗号化キーが使用される場合)。

次の各項では、これらのシナリオでのキーの移行について説明します。

• 同じドメイン内でのキーおよび証明書の移行

• 異なるドメイン間でのキーおよび証明書の移行

同じドメイン内でのキーおよび証明書の移行

両方のストアが同じドメイン内にある場合に、キーおよび証明書をmigrateSecurityStoreを使用して移行するには、構成ファイルを作成してソースおよびターゲットのサービス・インスタンスを指定し、migrateSecurityStoreを使用します。キーストアが同じドメイン内にある場合、ソースおよびターゲットのコンテキストを指定するのに1つの構成ファイルで十分です。

次の例では、LDAP、DBおよびファイルのストア内のキーストア・ソースと、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 credential provider</description>
 </serviceProvider>
 
<!-- provider for file, LDAP, and DB keystores -->
<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 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 source keystore keystores.xml is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
 </serviceInstance>
 
<!-- Source LDAP keystore 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 keystore 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>

<!-- target LDAP keystore instance -->
 <serviceInstance provider="keystore.provider" name="keystore.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your target 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>

<!-- target DB keystore instance -->
 <serviceInstance provider="keystore.provider" name="keystore.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your target 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 target 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 target 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 targetDomain/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="LDAPtargetContext">
 <serviceInstanceRef ref="keystore.ldap.target"/>
 </jpsContext>
 
<jpsContext name="DBtargetContext">
 <serviceInstanceRef ref="keystore.db.target"/>
 </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コンテキストがファイルに含まれていることに注意してください。

同じドメイン内でのキーおよび証明書の移行の例

次に示す例では、コマンドが実行されるターゲット・システムのディレクトリにt2p-keys.xmlファイルが格納されていることを前提とします。

テスト用(ソース)のLDAPストアから本番用(ターゲット)のLDAPストアにキーおよび証明書をすべて移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="keyStore",
                      configFile="t2p-keys.xml",
                      src="LDAPsourceContext",
                      dst="LDAPtargetContext")

テスト用(ソース)のファイル・ストアから本番用(ターゲット)のLDAPストアにキーおよび証明書をすべて移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="keyStore",
                      configFile="t2p-keys.xml",
                      src="FileSourceContext",
                      dst="LDAPtargetContext")

テスト用(ソース)のデータベース・ストアから本番用(ターゲット)のデータベース・ストアに、特定のアプリケーション・ストライプに対するキーおよび証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="stripeKeyStore",
                      configFile="t2p-keys.xml",
                      src="DBSourceContext",
                      dst="DBtargetContext", 
                      srcStripe="application1", 
                      dstStripe="application2")

異なるドメイン間でのキーおよび証明書の移行

ソースおよびターゲットのキーストアが異なるドメインにある場合にキーストア・データを移行するには、キーストアの暗号化に使用する暗号化キーが異なるため、2つの異なる構成ファイルが必要です。したがって、ブートストラップ資格証明ストアは異なる必要があります。

migrateSecurityStore WLSTコマンドを使用する場合は、次に留意してください。

• 構成ファイル内のソース・キーストアのコンテキストをsrcConfigFileパラメータに指定します。

• 構成ファイル内のターゲット・キーストアのコンテキストを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")