この章では、Oracle Access Manager 11gのデータをテスト環境から本番環境へ移行する方法について説明します。この方法は、アップグレードのテストおよびロールアウトにも使用できます
この章の内容は次のとおりです。
関連項目: Oracle Access Manager 10gの新しい(または既存の)本番環境への移行の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従い、ターゲット・コンポーネントをインストールおよび構成します
比較的小さな制限された環境でアプリケーションを開発およびテストしてから、最終的により大きな共有環境にテスト・アプリケーション(およびオプションでテスト・データ)をロールアウトするのがかなり一般的です。この章の情報を使用して、Oracle Access Manager 11gのデータをテスト・デプロイメント(ソース)から本番デプロイメント(ターゲット)へ移行します。この方法は、アップグレードのテストおよびロールアウトにも使用できます
表A-1で、顧客の企業内のデプロイメント・タイプについて説明します。デプロイメント・タイプの名前は企業によって異なる可能性があります。
表A-1 デプロイメント・タイプ
デプロイメント・タイプ | 説明 |
---|---|
開発デプロイメント |
理想的にはサンドボックスタイプの設定で、開発全体への依存は最小限 |
QAデプロイメント |
通常、テスト用に使用される、比較的小さな共有されたデプロイ |
本番前デプロイメント |
通常、より幅広い対象者でのテストに使用される、共有されたデプロイメント |
本番デプロイメント |
日常的に企業内で完全に共有および使用可能 |
各デプロイメントで、OAM 11gポリシー・データがデータベースに格納されるのに対し、OAM 11g構成データはファイルに格納されます。
ポリシー側で、各アプリケーション・ドメインは次の共有コンポーネントを使用して構成されます。
認証モジュール
認証スキーム(1つの認証モジュールを含む)
ホスト識別子
リソース
システム構成側では、保護する必要のあるリソースまたはパートナ・アプリケーションはエージェントに置かれます。エージェントとはOAMエージェント(WebGateまたはAccessGate)またはOSSOエージェントです。各エージェントはホストされたリソースを保護するOAM 11gに登録される必要があります。エージェントの登録は次のことを行います。
エージェントとその特有の構成パラメータの定義
指定されたリソースのアプリケーション・ドメインの作成
パートナ・アプリケーションのデフォルトの認証スキームでの認証ポリシーの作成
指定されたリソースの認証ポリシーの作成
パートナ・アプリケーションの対象鍵の生成
テスト(ソース)環境から本番(ターゲット)環境へのポリシーおよびパートナ情報の移行は、OAMサーバーのAdminServerにMBeanを登録することで行われます。WLSTコマンドでパートナおよびポリシー情報をソース・サーバーからフェッチし、それを本番サーバーに適用します。
次の概要で、OAM 11gポリシーおよびパートナ情報をテスト(ソース)環境から本番(ターゲット)環境に移行する必要のあるタスクの一般的な範囲を示します。
タスクの概要: OAM 11gのテストから本番への移行
「OAM 11gのテストから本番への移行の計画」の説明に従い、計画アクティビティを実行します。
「OAM 11gのテストから本番への移行」の説明に従い、ユーザーおよびグループ、アイデンティティおよびポリシー・ストア、資格証明などのデータをソースからエクスポートし、ターゲットにインポートします。
ターゲット・システムのみでソース・データを再利用するために、ソース・データをターゲットにインポートした後で、ターゲット・デプロイメント内でエージェントを再登録できます。
ホスト名やポートなどの、新しい環境に特有の情報があれば変更します。
アプリケーションをデプロイします。
この項では、OAM 11g用のデータ移行のアプローチ、方法およびツールの概要を説明します。
Oracle Access ManagerおよびOracle Identity ManagerはOracle Fusion Middleware 11gのコンポーネントです。Oracle Identity Managementスタックのすべての既存のアクセス・テクノロジは、Oracle Access Manager 11gに集約されています。アイデンティティ管理環境のすべてをテスト・ソースから本番ターゲットに移動するのに必要なタスクの範囲の違いを、表A-2に示します。
表A-2 データの新しいターゲット環境への転送と既存のターゲット環境への転送の違い
新しいターゲット環境 | 既存のターゲット環境 |
---|---|
この例では、テスト環境の既存のアイデンティティ管理コンポーネントを、まだ存在しない新しい環境に移行します。 これには、次のタスクが必要です。タスク8がこの章の主題です。その他のすべてのタスクは、『Oracle Fusion Middleware管理者ガイドを参照してください。 |
この例では、ソースのセキュリティ関連の構成を保持しながら、1つまたは複数のアプリケーションをソースから既存の環境のターゲットに移動します。 これには、アプリケーション特有のデータおよび増分変更をソースからターゲットに移行することが必要です。タスク2がこの章の主題です。その他のすべてのタスクは、『Oracle Fusion Middleware管理者ガイドを参照してください。 |
|
|
Oracle Access Manager 11gをテストから本番へ移動する場合、次で説明するいずれかの方法を使用できます。
表A-3で完全レプリケーションを説明します。手動および自動化されたタスクを実行することで、OAMテスト・ソース設定をOAM本番ターゲットにレプリケートできます。
表A-3 完全レプリケーション
要件 | 手動および自動化されたタスク | 不要または処理済 |
---|---|---|
|
次のWLSTコマンドが使用されます。
管理者は次のことも行う必要があります。
|
|
表A-4でゴールデン・テンプレート処理を説明します。手動および自動化されたタスクを実行することで、ソースと同じトポロジのターゲットOAMサーバーを作成できます。
表A-4 ゴールデン・テンプレート
要件 | 手動および自動化されたタスク | 不要または処理済 |
---|---|---|
|
管理者は次のことも手動で行う必要があります。
|
ユーザー構成内の変更は、別個の手動による手順です。 |
WLSTコマンドは既存のOAMテスト設定をクローニングして、次を実行します。
|
||
ソースWebGateが、ターゲット(本番)環境に含まれないプライマリ/セカンダリOAMサーバー・ホストおよびOAPポートのリストで構成されている場合、移行後、空のフィールドまたはソース・プライマリまたはセカンダリ・サーバーのサブネットがターゲット環境にリストされる可能性があります。 |
上記のWLSTコマンドの実行後、管理者はターゲット(本番)エージェント登録ページを編集し、実際のホストおよびポートと一致させる必要もあります。 |
表A-5で要件および増分転送(差分レプリケーションとも呼ばれる)の処理について説明します。ソースのすべての増分変更はターゲットに転送されます。選択的な転送は必要ありません。
表A-5 差分レプリケーション
要件 | タスク | 不要または処理済 |
---|---|---|
ソースOAMサーバーに"truth"が含まれています。ソースとターゲット間の競合はソースに基づき解決されています。 |
管理者はWLSTコマンドを"MigrateAll"フラグを"false"に設定して実行し、変更のみをソースからターゲット・システムへ移動します。 |
変更されていないポリシー構成は処理されません。 |
表A-6に要件とタスクの概要を示します。手動および自動化されたタスクを実行することで、ソース・クライアント・アプリケーションをターゲット環境に再度関連付けることができます。
表A-6 アプリケーションの再関連付け
要件 | 手動および自動化されたタスク | 不要またはプロセス |
---|---|---|
パートナおよびクライアントをソース環境からターゲットへ再関連付けします。 |
管理者はWLSTコマンドを実行して、次のことを行います。
|
|
管理者はリモート登録ツールを使用して次のことを行います。
|
新しいターゲットへの移行または既存のターゲットへの移行のいずれでも、OAM 11g AdminServerのMBeanを使用するWLSTコマンドが提供され、それにより管理者は次のことを行うことができます。
必要な場合、ターゲット・ユーザー・アイデンティティ・ストアをソース・ユーザー・アイデンティティ・ストアと一致するように構成します。
アプリケーション・ドメインおよびポリシー・データ(すべてのまたは選択したドメインおよびポリシーのみ)をレプリケートおよび移動します。
ソースとターゲット・システム間のIDの競合を解決する方法を記述した競合解決プロファイルを提供します。
エクスポートは、アプリケーション・ドメインおよびパートナ情報を一時ダンプ・ファイルにレプリケートしてエクスポートします。この機密情報を保護するために、ダンプ・ファイルを使用してキーストアが生成されます。キーストア内のキーを使用してダンプ・ファイルを暗号化します。
表A-7に、エクスポートするパートナをホストするテスト・ソースOAMサーバー上で実行する、エクスポート・モード・コマンドの情報を示します。
表A-7 エクスポート・コマンド
コマンド | 説明 | 例 |
---|---|---|
exportPartners() |
パートナのエクスポートにより、すべてのパートナ情報を含むオブジェクトが、各パートナのキーとともに作成されます。 このコマンドはパラメータとして一時oam-partnersファイルへのパスを受け取ります。 |
exportPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>) |
exportPolicy- |
アプリケーション・ドメインおよびポリシー・データをソースからエクスポートします。OAMアプリケーション・ドメインはすべての依存関係とともにエクスポートされます。 このコマンドはパラメータとして一時oam-policyファイルへのパスを受け取ります。 |
exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >') |
インポートにより、キーストア内のキーを使用して生成されたダンプ・ファイルの暗号解除が行われ、ダンプ・ファイルの内容がターゲットOAMサーバーにインポートされます。表A-8の説明に従い、パートナー、ポリシーまたはポリシーの差異をインポートできます。インポート・コマンドはターゲットOAMサーバーで実行されます。
表A-8 インポート・コマンド
コマンド | 説明 | 例 |
---|---|---|
importPartners() |
キーストア内のキーを使用してパートナ・データを暗号解除してインポートします。 このコマンドはパラメータとしてエクスポート操作中に作成された一時oam-partnersファイルへのパスを入力として受け取ります。 |
importPartners (pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>') |
importPolicy- |
アプリケーション・ドメインおよびポリシー・データを暗号解除してインポートします。 注意: このコマンドはターゲット上のすべてのポリシー・データを上書きします。 このコマンドはエクスポート操作中に作成された一時oam-policyファイルへのパスを入力として受け取ります。 |
importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >') |
importPolicyDelta- |
ターゲット上の変更されていないポリシー・データを上書きすることなく、ソースからターゲットOAMサーバーへの変更のみを暗号解除します。 注意: このコマンドは変更されたポリシー・データのみをターゲットに書き込みます。 このコマンドはエクスポート操作中に作成された一時oam-policyファイルへのパスを入力として受け取ります。 |
importPolicyDelta(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >' |
図A-1に、ソースとターゲット・システム間に発生する処理を示します。
データの移行中、ソース・システムが唯一の真のソースであると見なされます。ソースとターゲット間で検出された競合は処理中に解決される必要があります。競合の解決テンプレートの例をここに示し、表A-9で説明します。
<Conflict-Resolution> <Authentication-Modules value="Use Existing/Error"/> <Authentication-Schemes value="Reuse/Replace/Create New/Error"/> <Host-Identifiers value="Add to Existing/Create New"/> <Policy value="Reuse/Replace/Create New/Error"/> <Application-Domains value="Reuse/Replace/CreateNew/Error"/ > <Conflict-Resolution>/
表A-9 競合の解決
要素 | 説明 |
---|---|
認証モジュール Authentication-Modules value="Use Existing/Error"/> |
認証モジュールは各OAMシステムに対し定義されます。これらのモジュールはシステム構成中に構成されます。そのため、認証モジュールが本番システムにない場合、移行では認証モジュールは作成されません。本番システム内の認証モジュールがテスト・システムと一致しない場合、管理者は既存の認証モジュールを選択するか、または例外をスローして移行プロセスを終了できます。管理者はこの選択を競合解決プロファイルに記録します。 |
認証スキーム <Authentication-Schemes value="Reuse/Replace/Create New/Error"/> |
同じIDの認証スキームがテストおよび本番システムに存在する場合、移行前に競合を解決する必要があります。認証スキームには、名前、認証レベル、チャレンジ方法および認証モジュールの属性があります。これらの属性すべてを使用して、テストおよび本番システムでの認証スキームを一致させます。これらの属性すべてが一致する場合、移行プロセスは既存のスキームを使用します。しかし、これらの属性で一致しないものがある場合、管理者は新しい一意のIDで新しい認証スキームを作成することを選択できます。この選択は解決プロファイルに記録されます。 |
ホスト識別子 Host-Identifiers value="Add to Existing/Create New"/> |
ホストは、ホスト名とドメイン名、ドメイン名なしのホスト名とIPアドレス、というように、複数の方法で指定できます。ホスト識別子はこれらのアドレス方法のすべてをグループ化し、これらのアドレス方法と一致するリクエストがOAMサーバーにより保護されるようにします。 たとえば、次に示す、ソース・システム(唯一の真のソース)とターゲット・システム間の競合のいずれかのタイプを解決する必要があるとします。
ホスト識別子は、アプリケーション・ドメインのリソースの一部として使用されます。アプリケーション・ドメインをテストから本番システムにエクスポートする間に、ホスト識別子の競合は解決される必要があります。ホスト識別子とそのホスト識別子内のすべてのホスト名がテストおよび本番システムで完全に一致する場合、アプリケーション・ドメインの移行は継続します。しかし、ホスト識別子とホスト名が一致しない場合、競合が解決される必要があります。ホスト識別子が一致しない状況を次に示します。 同じ名前のホスト識別子に、テストおよび本番システムで完全に異なるホスト名のセットが含まれる テスト・システムで同じ名前のホスト識別子に、本番システムのホスト名のサブセットが含まれる 本番システムで同じ名前のホスト識別子に、テスト・システムのホスト名のサブセットが含まれる 同じホスト名のホスト識別子に、異なる名前が含まれる |
OAM 11gアプリケーション・ドメインを移行する前に、移行する各アプリケーション・ドメインに対して依存関係を構築する必要があります。
依存関係は図A-2に示すように表すことができます。
図A-2に示す依存関係の例では、アプリケーション・ドメインが3つの認証ポリシーと2つのリソースから構成されています。各認証ポリシーは認証スキームで構成され、各認証スキームには認証モジュールが構成されています。このサンプルのアプリケーション・ドメインは2つのリソース(各リソースはホスト識別子およびリソースURLとして定義されている)に適用されます。
アプリケーション・ドメインのデータを移行するには、共有コンポーネント(モジュール、スキームおよびホスト識別子)を最初に移行する必要があります(まだ移行されていない場合)。共有コンポーネントのデータ移行に続いて、アプリケーション・ドメイン・データを移行します。
計画と準備は、データ移行戦略の成功の主要なコンポーネントです。この項では、移行を成功させるために、作成する必要のあるインベントリ項目と計画の考慮点について説明します。
Oracle Access Manager構成データをソースからターゲットに転送するときに、次に示す、2つの環境間の相違のタイプに必ず注意してください。
OAMサーバー・インスタンスの名前および実装詳細
エージェントが指すOAMサーバーへの変更を含む、OAMエージェント(WebGatesおよびAccessGates)の名前および実装詳細
エージェントが指すOAMサーバーへの変更を含む、OSSOエージェント(mod_osso)の名前および実装詳細
ホスト識別子の定義
チャレンジ・リダイレクト・パラメータを含む、認証スキーマの定義
認証ポリシー、制約、レスポンスおよびリソースの定義
認証および認可ポリシーに定義されたすべてのリダイレクトURLを含む、アプリケーション・ドメインの定義
転送アクティビティを開始する前に、既存のOracle Access Manager 11g Release 1(11.1.1)デプロイメントのインベントリを取得することをお薦めします。既存のインストール・レコードから詳細を収集、またはデプロイメントから直接新しい情報を収集できます。
転送前にデータの正確性を確認するために、ソース・デプロイメントにおける構成を評価する特定のテストを作成することをお薦めします。
転送後、ターゲット・デプロイメントで同じテストを使用して、すべてが予想通りに動作することを確認できます。
すべての変更はOAM管理コンソールに反映され、クラスタの各OAMサーバーに自動的に伝播されます。
1つのOAMサーバーと1つのOAM管理コンソールが異なるコンピュータで実行されている場合、変更は管理された実行時OAMサーバーに伝播されます。
移動を開始する前に、特定の転送期間をスケジューリングし、他の管理者に、その担当するデプロイメントでの計画されたアクティビティについて通知することを強くお薦めします。
転送前にデータをバックアップし、必要な場合は転送後にバックアップをリストアすることをお薦めします。
この項は必要性に基づき次のように分類されます。
必要に応じて次の手順を使用して、パートナおよびポリシー・データをテスト・ソース環境からエクスポートします。
前提条件
詳細は、次の項を参照してください。
Oracle Access Manager 10gの新しい(または既存の)本番環境への移行の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください
データをテスト・ソースからエクスポートする手順
パートナ・データのエクスポート: OAM 11gパートナをホストしているソースOAMサーバーで、固有の一時OAMパートナ・ファイルへのパスを使用して次のt2pClientコマンドを実行します。例:
exportPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>>')
ポリシー・データのエクスポート: OAM 11gポリシー・データをホストしているソースOAMサーバーで、固有の一時OAMポリシー・ファイルへのパスを使用して次のt2pClientコマンドを実行します。例:
exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')
パートナおよびポリシー・データをホストしている各ソースOAMサーバーで繰り返します。
必要に応じて次の手順を使用して、パートナおよびポリシー・データをテスト・ソース環境からインポートします。
前提条件
データを本番ターゲットにインポートする手順
パートナ・データのインポート: ターゲットOAMサーバーで、一時ソース・パートナ・ファイルへのパスを使用して次のt2pClientコマンドを実行します。例:
importPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>>')
全ポリシー・データのインポート: ターゲットOAMサーバーで、一時ソース・ポリシー・ファイルへのパスを使用して次のt2pClientコマンドを実行します。例:
importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')
ポリシーの差分のみのインポート: ターゲットOAMサーバーで、一時ソース・ポリシー・ファイルへのパスを使用して次のt2pClientコマンドを実行します。例:
importPolicyDelta(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')
パートナおよびポリシー・データをホストしている各ソースOAMサーバーで繰り返します。