Oracle® Fusion Middleware

Oracle Identity and Access Management移行ガイド

11gリリース2 (11.1.2.2.0)

E53415-02(原本部品番号:E49917-04)

2014年9月

このドキュメントは、Oracle Fusion Middlewareの管理者を対象に、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)に移行する方法について説明しています。

Oracle Fusion Middleware Oracle Identity and Access Management移行ガイド, 11gリリース2 (11.1.2.2.0)

E53415-02

Copyright © 2014, Oracle and/or its affiliates.All rights reserved.

原本著者: Shynitha K S

原本協力者: Allison Sparshott, Ankit Mittal, Arun Singla, Aruna Vempaty, Ashwini Singhvi, Ballaji Sahoo, Bhavik Sankesara, Brad Donnison, Bruce Xie, Charles Wesley, Deepak Ramakrishnan, Derick Leo, Gaurav Johar, Gururaj B S, Kavita Tippanna, Kishor Negi, Kumar Dhanagopal, Lixin Zheng, Lokesh Gupta, Madhu Martin, Mark Karlstrand, Mark Wilcox, Mrudul Uchil, Nagasravani Akula, Neelanand Sharma, Niranjan Ananthapadmanabha, Pallavi Rao, Peter Laquerre, Raminder Deep Kaler, Ramya Subramanya, Ravi Thirumalasetty, Rubis Chowallur, Sandeep Dongare, Sanjeev Sharma, Semyon Shulman, Sharadchandra Chavali, Sitaraman Swaminathan, Sree Chitturi, Srinivas Nagandla, Stephen Mathew, Steven Frehe, Stuart Duggan, Svetlana Kolomeyskaya, Sylaja Kannan, Tushar Wagh, Umesh Waghode, Vadim Lander, Vishal Mishra, Venu Shastri, William Cai, Wortimla Rs

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

第I部 Oracle Identity and Access Managementの理解

1 Oracle Identity and Access Management移行および共存の概要

- 1.1 Oracle Identity and Access Managementの概要

- 1.2 移行および共存のシナリオ

- 1.3 アップグレード・シナリオ

- 1.4 移行および共存がサポートされている開始ポイント

- 1.4.1 Oracle Access Manager 10gの移行がサポートされている開始ポイント

- 1.4.2 Oracle Adaptive Access Manager 10gの移行がサポートされている開始ポイント

- 1.4.3 Oracle Single Sign-On 10gの移行がサポートされている開始ポイント

- 1.4.4 Sun OpenSSO Enterpriseの移行がサポートされている開始ポイント

- 1.4.5 Sun Java System Access Managerの移行がサポートされている開始ポイント

- 1.4.6 Oracle Identity Analyticsの移行がサポートされている開始ポイント

- 1.4.7 Oracle Access Manager 10gとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

- 1.4.8 Sun OpenSSO EnterpriseとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

- 1.4.9 Sun Java System Access ManagerとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

- 1.5 ドキュメント・ロードマップ

第II部 Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)への移行

2 Oracle Access Manager 10g環境の移行

- 2.1 移行の概要

- 2.1.1 移行のモード

- 2.1.1.1 完全移行

- 2.1.1.2 増分移行

- 2.1.1.3 デルタ移行

- 2.1.2 移行のサマリー

- 2.2 トポロジの比較

- 2.3 移行ロードマップ

- 2.4 移行の前提条件

- 2.5 Oracle Identity and Access Management 11.1.2.2.0のインストール

- 2.6 Oracle Access Management Access Manager 11.1.2.2.0の構成

- 2.7 Access Manager 11.1.2.2.0サーバー用のトランスポート・セキュリティ・モードの構成

- 2.7.1 Access Manager 11.1.2.2.0サーバーのセキュリティ・モードの決定

- 2.7.2 Access Manager 11.1.2.2.0サーバー用のCertモード通信の構成

- 2.7.3 Access Manager 11.1.2.2.0サーバー用のSimpleモード通信の構成

- 2.8 管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーの起動

- 2.9 プロパティ・ファイルの作成

- 2.10 評価レポートの生成

- 2.11 管理サーバーの再起動

- 2.12 増分移行のための追加手順

- 2.13 Access Manager 11.1.2.2.0へのOracle Access Manager 10gのアーティファクトの移行

- 2.14 Access Manager 11.1.2.2.0使用時の10g WebGateの集中ログアウトの構成

- 2.15 Access Manager 11.1.2.2.0サーバーとWebGateの関連付け

- 2.16 移行の確認

- 2.17 トラブルシューティング

- 2.17.1 移行データの損失を防ぐためにログ・ファイルのサイズを増やす

- 2.17.2 WebLogic Serverのヒープ・サイズを増やす

- 2.17.3 Oracle Access Managerの移行時にLDAPページング機能が動作しない場合がある

3 Oracle Adaptive Access Manager 10g環境の移行

- 3.1 移行の概要

- 3.2 トポロジの比較

- 3.3 移行ロードマップ

- 3.4 移行の前提条件

- 3.5 Oracle Identity and Access Management 11.1.2.2.0のインストール

- 3.6 Oracle Platform Security Servicesスキーマの作成

- 3.7 OAAM 10gスキーマのアップグレード

- 3.8 新規または既存Oracle WebLogicドメインでのOAAM 11.1.2.2.0の構成

- 3.9 データベース・セキュリティ・ストアの構成

- 3.10 ノード・マネージャの構成

- 3.11 WebLogic管理サーバーの起動

- 3.12 OAAM管理対象サーバーの停止

- 3.13 アップグレード・アシスタントを使用したOAAM中間層のアップグレード

- 3.14 OAAM管理対象サーバーの起動

- 3.15 移行の確認

4 Oracle Single Sign-On 10g環境の移行

- 4.1 移行の概要

- 4.2 移行のサマリー

- 4.3 トポロジの比較

- 4.4 移行シナリオ

- 4.4.1 Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要

- 4.4.2 Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要、ただしOracle Single Sign-On Adminは不要

- 4.4.3 Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesは不要

- 4.5 移行ロードマップ

- 4.6 移行の前提条件

- 4.7 Access Manager 11.1.2.2.0トポロジの理解

- 4.8 オプション: Oracle Databaseのアップグレード

- 4.9 リポジトリ作成ユーティリティを使用したスキーマの作成

- 4.10 Access Manager 11.1.2.2.0中間層のインストールおよび構成

- 4.10.1 Oracle Single Sign-On 10gのホスト名とポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成

- 4.10.2 新しいホスト名またはポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成

- 4.11 アップグレード・アシスタントを使用したAccess Manager 11.1.2.2.0中間層のアップグレード

- 4.12 移行後タスクの実行

- 4.12.1 Oracle HTTP Serverポートが変更された場合のAccess Manager 11.1.2.2.0サーバーを使用したOracle Portal 10gの構成

- 4.12.2 ロールを調整するためのOracle Access Management 11.1.2.2.0管理コンソールの構成

- 4.12.3 osso.confファイルのコピー

- 4.12.4 Access Manager 11.1.2.2.0でのOracle Business Intelligence Discoverer 11gの構成

- 4.12.5 保護されるDASリソースの認証ポリシーでのヘッダーの設定

- 4.12.6 デフォルトの認証スキームの設定

- 4.12.7 Access Manager 11.1.2.2.0のデフォルト・ストアおよびシステム・ストアとしての移行アイデンティティ・ストアの設定

- 4.12.8 SSLサーバー認証モードで構成されたOracle Internet Directoryの追加手順

- 4.12.9 移行後の追加のAccess Managerタスク

- 4.12.10 Oracle Single Sign-On 10gの停止

- 4.13 移行の確認

5 Sun OpenSSO Enterprise 8.0環境の移行

- 5.1 移行の概要

- 5.2 移行のモード

- 5.2.1 完全移行

- 5.2.2 増分移行

- 5.2.3 デルタ移行

- 5.3 移行のサマリー

- 5.3.1 エージェントの移行のサマリー

- 5.3.2 ポリシーの移行のサマリー

- 5.3.3 ユーザー・ストアの移行のサマリー

- 5.3.4 認証ストアの移行のサマリー

- 5.4 トポロジの比較

- 5.5 移行ロードマップ

- 5.6 移行の前提条件

- 5.7 Oracle Identity and Access Management 11.1.2.2.0のインストール

- 5.8 Oracle Access Management Access Manager 11.1.2.2.0の構成

- 5.9 評価レポートの生成

- 5.9.1 評価ツールの入手

- 5.9.2 LDAP接続の詳細の指定

- 5.9.3 OpenSSOエージェント評価ツールの実行

- 5.9.4 評価レポートの分析

- 5.10 WebLogic管理サーバーの起動

- 5.11 増分移行のための追加手順

- 5.12 プロパティ・ファイルの作成

- 5.13 OpenSSO Enterprise 8.0のアーティファクトのAccess Manager 11.1.2.2.0への移行

- 5.14 移行後タスクの実行

- 5.15 移行の確認

6 Sun Java System Access Manager 7.1環境の移行

- 6.1 移行の概要

- 6.2 移行のモード

- 6.2.1 完全移行

- 6.2.2 増分移行

- 6.2.3 デルタ移行

- 6.3 移行のサマリー

- 6.3.1 エージェントの移行のサマリー

- 6.3.2 ポリシーの移行のサマリー

- 6.3.3 ユーザー・ストアの移行のサマリー

- 6.3.4 認証ストアの移行のサマリー

- 6.4 トポロジの比較

- 6.5 移行ロードマップ

- 6.6 移行の前提条件

- 6.7 Oracle Identity and Access Management 11.1.2.2.0のインストール

- 6.8 Oracle Access Manager 11.1.2.2.0の構成

- 6.9 評価レポートの生成

- 6.9.1 ツールの入手

- 6.9.2 LDAP接続の詳細の指定

- 6.9.3 2.2エージェントのエージェント・プロファイルの更新

- 6.9.4 OpenSSOエージェント評価ツールの実行

- 6.9.5 評価レポートの分析

- 6.10 WebLogic管理サーバーの起動

- 6.11 増分移行のための追加手順

- 6.12 プロパティ・ファイルの作成

- 6.13 Sun Java System Access Manager 7.1のアーティファクトのOAM 11.1.2.2.0への移行

- 6.14 移行後タスクの実行

- 6.15 移行の確認

7 Oracle Identity AnalyticsからOracle Identity Managerへの完了した証明の移行

- 7.1 移行の概要

- 7.2 移行ロードマップ

- 7.3 移行の前提条件

- 7.4 移行ツールの入手

- 7.5 Oracle Identity Analyticsインストールからのjarファイルのコピー

- 7.6 データベース接続の詳細の指定

- 7.7 クローズした証明の移行

- 7.8 移行の確認

第III部 共存シナリオ

8 Oracle Access Manager 10gとOracle Access Management Access Manager 11.1.2.2.0の共存

- 8.1 共存の概要

- 8.2 共存の機能

- 8.2.1資格証明コレクションについて

- 8.3 共存のトポロジ

- 8.3.1 10g WebGateおよびOracle Access Manager 10gで保護されているリソースへのアクセスおよび10g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス

- 8.3.2 11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセスおよび10g WebGateおよびAccess Manager 10gで保護されているリソースへのアクセス

- 8.3.3 10g WebGateおよびAccess Manager 10gで保護されているリソースへのアクセスおよび11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス

- 8.3.4 10g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセスおよび11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス

- 8.4 タスク・ロードマップ

- 8.5 共存の前提条件

- 8.5.1 Access Manager 11.1.2.2.0でのユーザー・アイデンティティ・ストアの構成

- 8.6 オプション: Oracle HTTP Server 11g (OHS-1)のインストールと構成

- 8.7 オプション: WebGate 11g-1のインストールと構成

- 8.8 オプション: WebGate 10gのインストールと構成

- 8.9 Access Manager 11.1.2.2.0サーバーの共存モードの有効化

- 8.10 ログアウト設定の構成

- 8.11 構成の確認

- 8.12 共存の機能の無効化

- 8.13 既知の問題

9 Sun OpenSSO Enterprise 8.0とOracle Access Management Access Manager 11.1.2.2.0の共存

- 9.1 共存の概要

- 9.2 共存のトポロジ

- 9.3 タスク・ロードマップ

- 9.4 共存の前提条件

- 9.5 Agent-2を使用したAccess Manager 11.1.2.2.0サーバーのエンドポイントURLの保護

- 9.5.1 OpenSSO Enterprise 8.0サーバーでのAccess Manager 11.1.2.2.0のAgent-2プロファイルの作成

- 9.5.2 Agent-2(ポリシー・エージェント3.0)のインストール

- 9.5.3 エージェント・フィルタ構成を含めるWebアプリケーションの更新

- 9.5.4 OpenSSO Enterprise 8.0サーバーでのAccess Manager 11.1.2.2.0の認証ポリシーの作成

- 9.6 Access Manager 11.1.2.2.0のデータ・ソースの構成

- 9.7 Access Manager 11.1.2.2.0でのLDAPNoPasswordAuthModuleの更新

- 9.8 Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成

- 9.9 Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成

- 9.10 Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更

- 9.11 OpenSSO Enterprise 8.0サーバーでのAgent-2のプロファイルの更新

- 9.12 ログアウト設定の構成

- 9.12.1 OpenSSO Enterprise 8.0サーバーからログアウトを開始する設定

- 9.12.2 Access Manager 11.1.2.2.0サーバーからログアウトを開始する設定

- 9.13 構成の確認

10 Sun Java System Access Manager 7.1とOracle Access Management Access Manager 11.1.2.2.0の共存

- 10.1 共存の概要

- 10.2 共存のトポロジ

- 10.3 タスク・ロードマップ

- 10.4 共存の前提条件

- 10.5 Agent-2によるAccess Manager 11gサーバーのエンドポイントURLの保護

- 10.5.1 Sun Java System Access Manager 7.1サーバーでのAccess ManagerのAgent-2プロファイルの作成

- 10.5.2 Agent-2(ポリシー・エージェント2.2)のインストール

- 10.5.3 エージェント・フィルタ構成を含めるWebアプリケーションの更新

- 10.5.4 Sun Java System Access Manager 7.1サーバーでのAccess Managerのポリシーの作成

- 10.6 Access Manager 11.1.2.2.0のデータ・ソースの構成

- 10.7 Access Manager 11gでのLDAPNoPasswordAuthModuleの更新

- 10.8 Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成

- 10.9 Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成

- 10.10 Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更

- 10.11 Sun Java System Access Manager 7.1サーバーでのAgent-2のプロファイルの更新

- 10.12 ログアウト設定の構成

- 10.12.1 Sun Java System Access Manager 7.1サーバーからログアウトを開始する設定

- 10.12.2 Access Manager 11gサーバーからログアウトを開始する設定

- 10.13 構成の確認

A 一般的な移行タスク

- A.1 サーバーの停止

- A.1.1 管理対象サーバーの停止

- A.1.2 WebLogic管理サーバーの停止

- A.2 サーバーの起動

- A.2.1 WebLogic管理サーバーの起動

- A.2.2 管理対象サーバーの起動

はじめに

このドキュメントでは、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)コンポーネントに移行する方法について説明します。

対象読者

このドキュメントは、既存のアイデンティティ管理環境をOracle Identity and Access Management 11gリリース2 (11.1.2.2.0)に移行する管理者を対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)のドキュメント・ライブラリに含まれる次のドキュメントを参照してください。

- Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド

- Oracle Fusion Middleware Oracle Identity and Access Managementアップグレード・ガイド

- Oracle Fusion Middleware Oracle Identity Manager管理者ガイド

- Oracle Fusion Middleware Oracle Access Management管理者ガイド

- Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド

- Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド

- Oracle Fusion Middleware Oracle Identity Navigator管理者ガイド

- Oracle Fusion Middleware高可用性ガイド

- Oracle Fusion Middlewareリリース・ノート

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部

Oracle Identity and Access Managementの理解

次の章で構成されています。

- 第1章「Oracle Identity and Access Managementの移行および共存の概要」

1 Oracle Identity and Access Management移行および共存の概要

この章では、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)製品およびドキュメント・ロードマップの概要について説明します。また、11.1.2.1.0でサポートされている移行および共存のシナリオについても説明します。

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

- 第1.1項「Oracle Identity and Access Managementの概要」

- 第1.2項「移行および共存のシナリオ」

- 第1.3項「アップグレード・シナリオ」

- 第1.4項「移行および共存がサポートされている開始ポイント」

- 第1.5項「ドキュメント・ロードマップ」

1.1 Oracle Identity and Access Managementの概要

Oracle Identity and Access Managementコンポーネントでは、ファイアウォール内外のすべてのエンタープライズ・リソース間でユーザー・アイデンティティのエンドツーエンド・ライフサイクルを企業で管理できます。Oracle Identity and Access Managementを使用すると、アプリケーションのデプロイ所要時間の短縮、最も下位のレベルでの企業リソースに対する保護の適用、隠れたアクセス権限の自動削除などが可能になります。

Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)には、次の製品が含まれます。

- Oracle Access Managementには次のコンポーネントが含まれます。

- Oracle Access Management Access Manager

- Oracle Access Management Identity Federation

- Oracle Access Management Mobile and Social

- Oracle Access Management Security Token Service

- Oracle Adaptive Access Manager

- Oracle Identity Manager

- Oracle Entitlements Server

- Oracle Privileged Account Manager

- Oracle Identity Navigator

1.2 移行および共存のシナリオ

「移行」という用語は、次の製品をOracle Identity and Access Management 11gリリース2 (11.1.2.2.0)に移行するシナリオで、10gバージョンのOracle Identity and Access ManagementコンポーネントまたはSun製品をOracle Identity and Access Management 11.1.2.2.0に移行することを指します。この移行シナリオでは、新しい11gリリース2 (11.1.2.2.0)をOracleホーム(IAM_HOMEまたはORACLE_HOME)にインストールし、以前のインストールの構成データを新しい11gリリース2 (11.1.2.2.0)のOracleホームに移行する必要があります。

- Oracle Access Manager 10g

- Oracle Adaptive Access Manager 10g

- Oracle Single Sign-On 10g

- Sun OpenSSO Enterprise 8.0

- Sun Java System Access Manager 7.1

- Oracle Identity Analytics

移行中は、新旧両方のデプロイメントを一緒に実装できるため、いくつかのアプリケーションは古いサーバーで保護し、その他は新しいサーバーで保護できます。この共存モードによって、異なるサーバーから保護されるアプリケーション間を移動する際に、シームレスなシングル・サインオン環境を利用できます。

たとえば、Sun OpenSSO Enterprise 8.0サーバーおよびOracle Access Management Access Manager 11.1.2.2.0 サーバーは共存および連携が可能なため、Sun OpenSSO Enterprise 8.0サーバーおよびOracle Access Management Access Manager 11.1.2.2.0 サーバーによって保護されるアプリケーション間を移動する際にシームレスなシングル・サインオン環境を利用できます。

11gリリース2 (11.1.2.2.0)でサポートされる共存シナリオは次のとおりです。

- Oracle Access Manager 10gおよびOracle Access Management Access Manager 11.1.2.2.0の共存

- Sun OpenSSO Enterprise 8.0とOracle Access Management Access Manager 11.1.2.2.0の共存

- Sun Java System Access Manager 7.1とOracle Access Management Access Manager 11.1.2.2.0の共存

注意:

このガイドでは、この項で説明されているすべての移行および共存シナリオの手順について説明します。

1.3 アップグレード・シナリオ

「アップグレード」という用語は、既存のOracle Identity and Access Management 11gリリース1および11gリリース2コンポーネントからOracle Identity and Access Management 11gリリース2 (11.1.2.2.0)へのアップグレードを表しています。次のアップグレード・シナリオでは、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)インストーラを使用して、既存のOracle Home (IAM_HOME)からOracle Identity and Access Management 11gリリース2 (11.1.2.2.0)へのアップグレードを行います。

次のOracle Identity and Access ManagementコンポーネントをOracle Identity and Access Managementの11.1.2.2.0にアップグレードできます。

- Oracle Identity and Access Management 11gリリース2 (11.1.2.1.0)コンポーネント

- Oracle Access Manager 11.1.2.1.0

- Oracle Adaptive Access Manager 11.1.2.1.0

- Oracle Identity Manager 11.1.2.1.0

- Oracle Entitlements Server 11.1.2.1.0

- Oracle Privileged Account Manager 11.1.2.1.0

- Oracle Identity Navigator 11.1.2.1.0

- Oracle Identity and Access Management 11gリリース2 (11.1.2)コンポーネント

- Oracle Access Manager 11.1.2

- Oracle Adaptive Access Manager 11.1.2

- Oracle Identity Manager 11.1.2

- Oracle Entitlements Server 11.1.2

- Oracle Privileged Account Manager 11.1.2

- Oracle Identity Navigator 11.1.2

- Oracle Identity and Access Management 11gリリース1 (11.1.1.7.0)コンポーネント

- Oracle Access Manager 11.1.1.7.0

- Oracle Adaptive Access Manager 11.1.1.7.0

- Oracle Identity Manager 11.1.1.7.0

- Oracle Identity Navigator 11.1.1.7.0

- Oracle Identity and Access Management 11gリリース1 (11.1.1.5.0)コンポーネント

- Oracle Access Manager 11.1.1.5.0

- Oracle Adaptive Access Manager 11.1.1.5.0

- Oracle Identity Manager 11.1.1.5.0

- Oracle Entitlements Server 11.1.1.5.0

- Oracle Identity Navigator 11.1.1.5.0

- Oracle Identity Manager 9.1.x.x

注意:

このガイドでは、第1.2項「移行と共存のシナリオ」に記載の移行と共存のシナリオについてのみ説明しています。

アップグレードのシナリオは、Oracle Fusion Middleware Oracle Identity and Access Managementアップグレード・ガイドで説明されています。

1.4 移行および共存がサポートされている開始ポイント

この項では、Oracle Identity and Access Managementの移行と共存がサポートされている開始ポイントについて説明します。

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

- Oracle Access Manager 10gの移行がサポートされている開始ポイント

- Oracle Single Sign-On 10gの移行がサポートされている開始ポイント

- Sun OpenSSO Enterpriseの移行がサポートされている開始ポイント

- Sun Java System Access Managerの移行がサポートされている開始ポイント

- Oracle Identity Analyticsの移行がサポートされている開始ポイント

- Oracle Access Manager 10gとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

- Sun OpenSSO EnterpriseとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

- Sun Java System Access ManagerとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

1.4.1 Oracle Access Manager 10gの移行がサポートされている開始ポイント

表1-1は、移行がサポートされているOracle Access Manager 10gのリリースを示しています。

表1-1 移行がサポートされているOracle Access Manager 10gのリリース

リリース

説明

Oracle Access Manager 10g (10.1.4.3)

このバージョンのOracle Access Managerでは、移行がサポートされています。

1.4.2 Oracle Adaptive Access Manager 10gの移行がサポートされている開始ポイント

表1-1は、移行がサポートされているOracle Adaptive Access Manager 10gのリリースを示しています。

表1-2 移行がサポートされているOracle Adaptive Access Manager 10gのリリース

リリース

説明

Oracle Adaptive Access Manager 10g (10.1.4.5.0)

このバージョンのOracle Adaptive Access Managerでは、移行がサポートされています。

1.4.3 Oracle Single Sign-On 10gの移行がサポートされている開始ポイント

表1-3は、移行がサポートされているOracle Single Sign-On 10gのリリースを示しています。

表1-3 移行がサポートされているOracle Single Sign-On 10gのリリース

リリース

説明

Oracle Single Sign-On 10g (10.1.2)および10g (10.1.4)

このバージョンのOracle Single Sign-Onは、Oracle Application Server 10gリリース2 (10.1.2.3)および10g (10.1.4)の一部として使用可能でした。

1.4.4 Sun OpenSSO Enterpriseの移行がサポートされている開始ポイント

表1-4は、移行がサポートされているSun OpenSSO Enterpriseのリリースを示しています。

表1-4 移行がサポートされているSun OpenSSO Enterpriseのリリース

リリース

説明

Sun OpenSSO Enterprise 8.0 Update 2

このバージョンのSun OpenSSO Enterpriseでは、移行がサポートされています。

1.4.5 Sun Java System Access Managerの移行がサポートされている開始ポイント

表1-5は、移行がサポートされているSun Java System Access Managerのリリースを示しています。

表1-5 移行がサポートされているSun Java System Access Managerのリリース

リリース

説明

Sun Java System Access Manager 7.1またはSun Java System Access Manager 7.1 Patch 6

Sun Java System Access Managerのこれらのバージョンでは、移行がサポートされています。

1.4.6 Oracle Identity Analyticsの移行がサポートされている開始ポイント

表1-6は、移行がサポートされているOracle Identity Analyticsのリリースを示しています。

表1-6 移行がサポートされているOracle Identity Analyticsのリリース

リリース

説明

Oracle Identity Analytics 11gリリース1 (11.1.1.5.0)

このバージョンのOracle Identity Analyticsは移行がサポートされています。

1.4.7 Oracle Access Manager 10gとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

表1-7は、Oracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)との共存がサポートされているOracle Access Manager 10gのリリースを示しています。

表1-7 共存がサポートされているOracle Access Manager 10gのリリース

リリース

説明

Oracle Access Manager 10g (10.1.4.3)

任意のバンドル・パッチが適用されたこのバージョンでは共存がサポートされており、Oracle Access Manager 10gとOracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)の両方のデプロイメントを共存させることができます。

1.4.8 Sun OpenSSO EnterpriseとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

表1-8は、Oracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)との共存がサポートされているSun OpenSSO Enterpriseのリリースを示しています。

表1-8 共存がサポートされているSun OpenSSO Enterpriseのリリース

リリース

説明

Sun OpenSSO Enterprise 8.0 Update 2

このバージョンのSun OpenSSO Enterpriseでは共存がサポートされており、Sun OpenSSO EnterpriseとOracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)の両方のデプロイメントを共存させることができます。

1.4.9 Sun Java System Access ManagerとOracle Access Management Access Manager 11.1.2.2.0の共存がサポートされている開始ポイント

表1-9は、Oracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)との共存がサポートされているSun Java System Access Managerのリリースを示しています。

表1-9 共存がサポートされているSun Java System Access Managerのリリース

リリース

説明

Sun Java System Access Manager 7.1 Patch 6

このバージョンのSun Java System Access Managerでは共存がサポートされており、Sun Java System Access ManagerとOracle Access Manager 11gの両方のデプロイメントを共存させることができます。

1.5 ドキュメント・ロードマップ

この項では、すべての移行および共存のシナリオのドキュメント・ロードマップについて説明します。

表1-10では、すべての移行および共存のシナリオを示し、各移行および共存の手順を説明しています。移行および共存のシナリオに従って、それぞれの章に移動し、その手順を実行します。

表1-10 Oracle Identity and Access Managementの移行および共存のドキュメント・ロードマップ

シナリオ

章

移行シナリオ

Oracle Access Manager 10gからOracle Access Management Access Manager 11.1.2.2.0への移行

第2章「Oracle Access Manager 10g環境の移行」

Oracle Adaptive Access Manager 10gからOracle Adaptive Access Manager 11.1.2.2.0への移行

第3章「Oracle Adaptive Access Manager 10g環境の移行」

Oracle Single Sign-On 10gからOracle Access Management Access Manager 11.1.2.2.0への移行

第4章「Oracle Single Sign-On 10g環境の移行」

Sun OpenSSO Enterprise 8.0からOracle Access Management Access Manager 11.1.2.2.0への移行

第5章「Sun OpenSSO Enterprise 8.0環境の移行」

Sun Java System Access Manager 7.1からOracle Access Management Access Manager 11.1.2.2.0への移行

第6章「Sun Java System Access Manager 7.1環境の移行」

Oracle Identity Analytics 11.1.1.5.0からOracle Identity Manager 11.1.2.2.0への移行

第7章「Oracle Identity AnalyticsからOracle Identity Managerへの完了した証明の移行」

共存シナリオ

Oracle Access Manager 10gおよびOracle Access Management Access Manager 11.1.2.2.0の共存

第8章「Oracle Access Manager 10gおよびOracle Access Management Access Manager 11.1.2.2.0の共存」

Sun OpenSSO Enterprise 8.0とOracle Access Management Access Manager 11.1.2.2.0の共存

第9章「Sun OpenSSO Enterprise 8.0およびOracle Access Management Access Manager 11.1.2.2.0の共存」

Sun Java System Access Manager 7.1とOracle Access Management Access Manager 11.1.2.2.0の共存

第10章「Sun Java System Access Manager 7.1およびOracle Access Management Access Manager 11.1.2.2.0の共存」

第II部

Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)への移行

次の章で構成されています。

- 第2章「Oracle Access Manager 10g環境の移行」

- 第3章「Oracle Adaptive Access Manager 10g環境の移行」

- 第4章「Oracle Single Sign-On 10g環境の移行」

- 第5章「Sun OpenSSO Enterprise 8.0環境の移行」

- 第6章「Sun Java System Access Manager 7.1環境の移行」

- 第7章「Oracle Identity AnalyticsからOracle Identity Managerへの完了した証明の移行」

2 Oracle Access Manager 10g環境の移行

この章では、Oracle Access Manager 10gをOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.2.0)に移行する方法について説明します。

この章には次の項が含まれます:

- 第2.1項「移行の概要」

- 第2.2項「トポロジの比較」

- 第2.3項「移行ロードマップ」

- 第2.4項「移行の前提条件」

- 第2.5項「Oracle Identity and Access Management11.1.2.2.0のインストール」

- 第2.6項「Oracle Access Management Access Manager 11.1.2.2.0の構成」

- 第2.7項「Access Manager 11.1.2.2.0サーバー用のトランスポート・セキュリティ・モードの構成」

- 第2.8項「管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーの起動」

- 第2.9項「プロパティ・ファイルの作成」

- 第2.10項「評価レポートの生成」

- 第2.11項「管理サーバーの再起動」

- 第2.12項「増分移行のための追加手順」

- 第2.13項「Access Manager 11.1.2.2.0へのOracle Access Manager 10gのアーティファクトの移行」

- 第2.14項「Access Manager 11.1.2.2.0使用時の10g WebGateの集中ログアウトの構成」

- 第2.15項「Access Manager 11.1.2.2.0サーバーとWebGateの関連付け」

- 第2.16項「移行の確認」

- 第2.17項「トラブルシューティング」

2.1 移行の概要

この章で説明する手順を使用して、Oracle Access Manager 10gの次のアーティファクトをAccess Manager 11.1.2.2.0に移行できます。

- ホスト識別子

- エージェント

- データ・ストア

- 認証スキーム

- リソース・タイプ

- ポリシー・ドメイン

この移行では、Access Manager 11gリリース2 (11.1.2.2.0)をインストールし、新しいOracleホーム(IAM_HOME)を作成して、Oracle Access Manager 10gインストールから新しいAccess Manager 11gリリース2 (11.1.2.2.0)のOracleホームにポリシー・データを移行する必要があります。

この項には次のトピックが含まれます:

- 移行のモード

- 移行のサマリー

2.1.1 移行のモード

この章で説明する手順を使用して、次の3つのモードで移行を実行できます。

- 完全移行

- 増分移行

- デルタ移行

2.1.1.1 完全移行

この移行モードでは、11.1.2.2.0と互換性のあるOracle Access Manager 10gのすべてのアーティファクトがAccess Manager 11.1.2.2.0に移行されます。完全移行を実行できるのは1回のみです。完全移行を実行した後でデルタ移行を実行することはできますが、完全移行後の増分移行はサポートされていません。

2.1.1.2 増分移行

増分移行は、Oracle Access Manager 10gの選択されたエージェント、ポリシー・ドメインとその関連アーティファクト(ホスト識別子など)、リソースのリソース・タイプ、および認証スキームがAccess Manager 11.1.2.2.0に移行される移行モードです。増分移行で、選択されたポリシー・ドメインを移行する際、移行ユーティリティにより、認証スキーム、ホスト識別子、リソース・タイプなどの依存アーティファクトの有無がチェックされ、まずそれらが移行されます。この移行の後、関連付けられているポリシー・ドメインの移行が行われます。

Access Manager 11.1.2.2.0環境に存在していないアーティファクトを移行できます。移行対象のアーティファクトがすでにAccess Manager 11.1.2.2.0環境に存在している場合、そのアーティファクトは無視され、移行されません。

増分移行は複数回実行できます。増分移行の後に完全移行を実行することも可能です。または、増分移行を複数回実行して、すべてのアーティファクトを移行できます。

増分移行の手順は、完全移行の手順と同じですが、加えて、「増分移行のための追加手順」で説明されている、増分移行で必要な追加手順を実行する必要があります。

2.1.1.3 デルタ移行

デルタ移行を実行できるのは、完全移行の後のみです。デルタ移行とは、完全移行後に10gのアーティファクトに対して行った変更(デルタ)を移行することです。

デルタ移行を実行すると、ポリシー・ドメインで行われた変更が、依存アーティファクトにおける対応する変更とともに移行されます。たとえば、完全移行後に、新しく作成されたホスト識別子を使用する新しいリソースを追加した場合、次のデルタ移行では、新しく作成されたホスト識別子が最初に移行され、その後、リソースが移行されます。

新しく追加されたリソース・タイプおよびエージェントは、デルタ移行の一環として移行されません。リソース・タイプを移行するには、いずれかのポリシー・ドメインと関連付ける必要があります。

デルタ移行では、「追加」または「変更」タイプの変更が移行されます。つまり、10gデプロイメントで新しいアーティファクトを追加した場合やアーティファクトを変更した場合(リソース・タイプおよびエージェントを除く)、デルタ移行を使用して、それらの変更を移行できます。デルタ移行では、「削除」は移行されません。つまり、10gデプロイメントでアーティファクトを削除した場合、デルタ移行を使用しても、11gデプロイメントで同じアーティファクトが削除されるわけではありません。移行ツールを使用すると、特定の変更を移行できない場合でも、Access Manager 11gで既存のデータの整合性を確保できます。

デルタ移行後に完全移行および増分移行を実行することはできません。ただし、デルタ移行は複数回実行できます。

注意:

Oracle Access Manager 10gからAccess Manager 11.1.2.2.0へのデルタ移行は、Oracle Access Manager 10gデプロイメントに行われた変更が使用可能かどうかによって決まります。Oracle Access Manager 10gでは、Sync Recordsを使用して、10gデプロイメントに行われた変更が追跡されます。Sync Recordsが作成されるのは、Oracle Access Manager 10gのポリシー・マネージャ・コンソールを使用してポリシー関連のアーティファクトを変更する際に、ポリシー管理Webページに表示される「キャッシュの更新」チェック・ボックスを選択した場合のみです。

2.1.2 移行のサマリー

表2-1は、Access Manager 11.1.2.2.0に移行可能なOracle Access Manager 10gのアーティファクトをまとめたものです。

表2-1 アーティファクトの互換性

アーティファクト

説明

ホスト識別子

- Oracle Access Manager 10gのすべてのホスト識別子は、Access Manager 11.1.2.2.0の対応するホスト識別子にマップされます。

- Oracle Access Manager 10gのホスト名のバリエーション(ポート値に数値以外の文字が含まれるもの)は、Access Manager 11.1.2.2.0に移行されません。数値以外のポート値は削除され、バリエーションのホスト部分は保持されます。

- Oracle Access Manager 10gの複数のホスト識別子で重複するバリエーションは無視されます。指定されたホストIDのすべてのバリエーションが重複している場合、すべてのバリエーションが削除され、そのホストIDの名前を持つ新しいバリエーションが追加されます。

- Oracle Access Manager 10gポリシー・データのリソースがホスト識別子に関連付けられていない場合、移行ツールによって、移行中にAccess Manager 11.1.2.2.0にOAM11G_GLOBAL_HOSTIDというホスト識別子が作成され、新しく作成されたホスト識別子を持つリソースと関連付けられます。これは、Access Manager 11.1.2.2.0にホスト識別子がないとリソースを作成できないためです。移行後、Oracle Access Manager 10gポリシー・データにホスト識別子がなかったすべてのリソースのホスト識別子に適切なホスト名を追加する必要があります。

エージェント

- 移行では、IIS偽装ユーザー名およびパスワードを除いて、Oracle Access Manager 10gエージェント・プロファイルのすべての属性がサポートされています。

- Oracle Access Manager 10gデプロイメントにOpen/Simple/Certトランスポート・セキュリティ・モードのWebGateが混在している場合、移行ユーティリティでは、そのトランスポート・セキュリティ・モードのWebGateの移行が試行されます。この場合、WebGateのセキュリティ・モードに応じてAccess Manager 11.1.2.2.0サーバーを構成する必要があります。詳細は、第2.7項「Access Manager 11.1.2.2.0サーバー用のトランスポート・セキュリティ・モードの構成」を参照してください。

- すべてのWebGateを同じモードで移行する場合は、プロパティ・ファイルでagent_mode_to_overrideプロパティを、必要なモードに応じてOPEN /SIMPLE /CERTに設定する必要があります。プロパティ・ファイルで指定されるプロパティの詳細は、表2-4を参照してください。

- 移行ユーティリティでは、ObAccessClient.xml、password.xml、certificatesなどのアーティファクトは生成されません。WebGateにはすでに、Oracle Access Manager 10gデプロイメントからのこれらのアーティファクトがあるためです。必要な場合は、Access Manager 11.1.2.2.0管理コンソールを使用してWebGateプロファイルを手動で更新することで、これらのアーティファクトを生成できます。

データ・ストア

- Oracle Access Manager 10gディレクトリ・プロファイルのディレクトリ・インスタンスの移行がサポートされています。ディレクトリ・インスタンスのすべての関連属性は移行され、Access Manager 11.1.2.2.0の対応するデータ・ストアにマップされます。ディレクトリ・プロファイルにセカンダリ・ディレクトリ・インスタンスがある場合、それは別のデータ・ストアとして移行されます。

- 移行プロセスの間、データ・ストアは起動しており実行中である必要があります。オフラインのデータ・ストアは無視されます。

認証スキーム

- Form、Basic、X509などの認証スキームの移行がサポートされています。

- カスタマイズされた認証フローを持つ認証スキームの移行もサポートされています。

- カスタムの認証チャレンジ・パラメータを持つ認証スキームは、カスタムのチャレンジ・パラメータなしで移行されます。移行後、対応するOracle Access Manager 10g認証スキームで使用されているのと同じ値を持つ移行済の認証スキームにおいてチャレンジ・パラメータを手動で追加または変更する必要があります。

- Oracle Access Manager 10gからの外部認証スキームは、Access Manager 11.1.2.2.0ではサポートされていません。そのため、外部認証スキームは、委任認証プロトコル(DAP)を使用して11.1.2.2.0に移行されます。移行されたスキームでは、移行後の手順がいくつか必要です。

- カスタム認証の移行はサポートされていません。カスタム・プラグインが含まれている認証スキームは、正しく移行されない場合があります。

- Oracle Access Manager 10gのAnonymousタイプのすべての認証スキームは、Access Manager 11.1.2.2.0の単一のNONE認証スキームに直接マップされます。

リソース・タイプ

- Oracle Access Manager 10gのリソース・タイプと、移行されたAccess Manager 11.1.2.2.0のリソース・タイプは、1対1でマッピングされます。

- HTTP、wl_authenという名前を持つリソース・タイプは、Access Manager 11.1.2.2.0でデフォルトで使用できるため、移行されません。

ポリシー・ドメイン

- Oracle Access Manager 10gのポリシー・ドメインは、Access Manager 11.1.2.2.0の別個のアプリケーション・ドメインにマップされます。

- URL接頭辞は、Access Manager 11.1.2.2.0に移行されます。すべての接頭辞に対して、追加リソース<urlprefix>/**が作成され、デフォルトの認証および認可ポリシーによって保護されます。内部ポリシーに、すべての操作が選択され、かつURLパターンがないURL接頭辞が含まれている場合、リソース<urlprefix>および<urlprefix>/**は、デフォルトの認証スキームから削除されます。リソースは、該当する特定の内部ポリシー用に構成されている認証スキームによって保護されます。そのようなリソースは、そのリソース・タイプで定義されている操作をすべて選択することで作成されます。

- デフォルトの認証ルールと認可条件式はそれぞれ、デフォルトの認証ポリシーと認可ポリシーに移行されます。

- 移行では、認可条件式に関連付けられている、成功/失敗のレスポンスおよびリダイレクトのみがサポートされています。未確定のレスポンスおよびリダイレクトは無視されます。認可ルールに関連付けられているレスポンスおよびリダイレクトは、Access Manager 11.1.2.2.0でそれらがサポートされていないため、移行の対象とは見なされません。認可ルールの場合、成功と失敗の両方のリダイレクトおよびレスポンスがAccess Manager 11.1.2.2.0に移行されます。ただし、ユーザー・インタフェースには、成功のレスポンスのみが表示されます。

- いずれの認可条件式の一部も形成していない認可ルールは、移行では無視されます。

- Oracle Access Manager 10gの内部ポリシーをAccess Manager 11.1.2.2.0に移行する場合、次のようなことが当てはまります。

- ポリシー・ドメインに関連付けられているデフォルトの認証ルールが使用されている場合、内部ポリシーで定義されているリソースは、移行後、デフォルトの認証ポリシーに関連付けられます。それ以外の場合、その認証ルールに対して新しい認証ポリシーが作成されます。

- ポリシー・ドメインに関連付けられているデフォルトの認可条件式が使用されている場合、内部ポリシーで定義されているリソースは、移行後、デフォルトの認可ポリシーに関連付けられます。それ以外の場合、その認可条件式に対して新しい認可ポリシーが作成されます。

- Oracle Access Manager 10gでは、条件式の一部である認可ルールに関連付けられているALLOWおよびDENY条件は、移行時に条件に変換されます。後で、移行された条件を使用して、移行された認可ポリシーのためのALLOWおよびDENYルールが作成されます。

- タイミング条件は、一時条件として移行され、Access Manager 11.1.2.2.0のALLOWおよびDENYルールの一部を形成します。

- 移行後、ALLOWルールのみが作成されます。このルールには、ALLOWおよびDENY条件を含む結合式があり、ALLOWまたはDENYの評価が導かれます。DENYルールは常に空になります。

2.2 トポロジの比較

図2-1は、Oracle Access Manager 10gとAccess Manager 11.1.2.2.0のトポロジを比較したものです。

図2-1 Oracle Access Manager 10gとAccess Manager 11.1.2.2.0のトポロジの比較

2.3 移行ロードマップ

表2-2は、Oracle Access Manager 10gからAccess Manager 11.1.2.2.0への移行手順を示しています。

表2-2 移行タスク

タスク番号

タスク

参照先

1

前提条件を満たします。

「移行の前提条件」を参照してください。

2

Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)をインストールします。

「Oracle Identity and Access Management 11.1.2.2.0のインストール」を参照してください。

3

Access Manager 11.1.2.2.0を構成します。

「Oracle Access Management Access Manager 11.1.2.2.0の構成」を参照してください。

4

移行後、WebGateがAccess Manager 11.1.2.2.0との通信を開始したときに、Access Manager 11.1.2.2.0サーバーがエージェントからの接続を受け入れるように、Access Manager 11.1.2.2.0サーバー・インスタンスとWebGateのセキュリティ・モードを構成します。

「Access Manager 11.1.2.2.0サーバー用のトランスポート・セキュリティ・モードの構成」を参照してください。

5

管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーを起動します。

「管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーの起動」を参照してください。

6

LDAP詳細および必要な情報を使用してプロパティ・ファイルを作成します。

「プロパティ・ファイルの作成」を参照してください。

7

評価レポートを生成し、どのエージェントとアーティファクトをAccess Manager 11.1.2.2.0に移行できるかを分析します。

Oracle Access Manager 10g環境を移行する前に、このタスクを複数回実行できます。

「評価レポートの生成」を参照してください。

8

Access Manager 11.1.2.2.0があるドメインの管理サーバーを再起動します。

「管理サーバーの再起動」を参照してください。

9

増分移行を実行する場合は、追加手順(入力ファイルの作成など)を実行します。

完全移行を実行する場合は、このタスクは無視してください。

「増分移行のための追加手順」を参照してください。

10

Oracle Access Manager 10gをAccess Manager 11.1.2.2.0に移行します。

「Access Manager 11.1.2.2.0へのOracle Access Manager 10gのアーティファクトの移行」を参照してください。

11

Access Manager 11.1.2.2.0で10g WebGateを使用する場合、Access Manager 11.1.2.2.0サーバーと連携するように10g WebGateの集中ログアウトを構成する必要があります。

「Access Manager 11.1.2.2.0使用時の10g WebGateの集中ログアウトの構成」を参照してください。

12

移行されたWebGateをOracle Access Management 11.1.2.2.0サーバーに関連付けます。

「Access Manager 11.1.2.2.0サーバーとWebGateの関連付け」を参照してください。

13

移行を確認します。

「移行の確認」を参照してください。

2.4 移行の前提条件

Oracle Access Manager 10gをAccess Manager 11.1.2.2.0に移行するには、次の前提条件を満たす必要があります。

1. システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

2. 使用しているOracle Access Manager 10gのバージョンで移行がサポートされていることを確認します。Oracle Access Manager 10gの移行がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。

3. Oracle Access Manager 10gデプロイメント内で構成されているすべてのユーザー・ストアが実行されていることを確認します。

2.5 Oracle Identity and Access Management 11.1.2.2.0のインストール

移行プロセスの一部として、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)をインストールする必要があります。Oracle Identity and Access Managementは、Oracle Access Management Access Manager 11.1.2.2.0を含むスイートです。これは、Oracle Access Manager 10gがインストールされているのと同じマシンにも異なるマシンにもインストールできます。

Oracle Identity and Access Management 11.1.2.2.0のインストールの詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドのOracle Identity and Access Management (11.1.2.2.0)のインストールに関する説明を参照してください。

2.6 Oracle Access Management Access Manager 11.1.2.2.0の構成

Oracle Identity and Access Management 11.1.2.2.0をインストールしたら、Access Manager 11.1.2.2.0を構成し、ドメインを作成する必要があります。

Access Manager 11.1.2.2.0の構成については、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドのOracle Access Managementの構成に関する項を参照してください。

2.7 Access Manager 11.1.2.2.0サーバー用のトランスポート・セキュリティ・モードの構成

移行後、移行されたWebGateがAccess Manager 11.1.2.2.0サーバーと通信できるように、Access Manager 11.1.2.2.0サーバーのセキュリティ・モードを構成する必要があります。セキュリティ・モードは次のとおりです。これらのセキュリティ・モードは、セキュリティ・レベルの低いものから高いものへという順番で示されています。

- Open

- Simple

- Cert

Openがセキュリティ・レベルの最も低いモードであり、Certがセキュリティ・レベルの最も高いモードです。Openは、デフォルトのセキュリティ・モードです。どのセキュリティ・モードでAccess Manager 11.1.2.2.0サーバーを構成する必要があるかは、移行対象のOracle Access Manager 10g WebGateのセキュリティ・モードによって異なります。

この項には次のトピックが含まれます:

- Access Manager 11.1.2.2.0サーバーのセキュリティ・モードの決定

- Access Manager 11.1.2.2.0サーバー用のCertモード通信の構成

- Access Manager 11.1.2.2.0サーバー用のSimpleモード通信の構成

2.7.1 Access Manager 11.1.2.2.0サーバーのセキュリティ・モードの決定

移行するすべてのWebGateが同じセキュリティ・モードである場合は、Access Manager 11.1.2.2.0サーバーをそのモードで構成する必要があります。移行されたWebGateに異なるセキュリティ・モードのWebGateが混在する場合は、Access Manager 11.1.2.2.0サーバーを、よりセキュリティ・レベルの低いモードで構成する必要があります。表2-3は、様々なユースケースとAccess Manager 11.1.2.2.0サーバーを構成する必要のあるセキュリティ・モードを示しています。

表2-3 Access Manager 11.1.2.2.0サーバーのセキュリティ・モードの選択

Oracle Access Manager 10g WebGateのトランスポート・セキュリティ・モード

Access Manager 11.1.2.2.0インスタンスで構成する必要のあるセキュリティ・モード

構成手順

一部またはすべてがOpen

Open

Openモードはデフォルトのモードです。追加手順は必要ありません。

すべてがCert

Cert

「Access Manager 11.1.2.2.0サーバー用のCertモード通信の構成」を参照してください。

すべてがSimple

Simple

「Access Manager 11.1.2.2.0サーバー用のSimpleモード通信の構成」を参照してください。

Open、SimpleおよびCertが混在

Open

Openモードはデフォルトのモードです。追加手順は必要ありません。

SimpleおよびCertが混在

Simple

「Access Manager 11.1.2.2.0サーバー用のSimpleモード通信の構成」を参照してください。

2.7.2 Access Manager 11.1.2.2.0サーバー用のCertモード通信の構成

Access Manager 11.1.2.2.0用にCertモード通信を構成するには、Oracle Fusion Middleware Oracle Access Management管理者ガイドのAccess Manager用のCertモード通信の構成に関する項の次の手順を実行します。

1. OAMサーバーとWebGate間の通信の保護の概要に関する項、およびCertモード暗号化とファイルに関する項を確認します。
このタスクで説明されているすべての手順を実行します。

2. OAMサーバー用の証明書リクエストおよび秘密鍵の生成に関する項
このタスクで説明されているすべての手順を実行します。

3. OAMキーストア別名およびパスワードの取得に関する項
このタスクで説明されているすべての手順を実行します。

4. 信頼できる、署名された証明書チェーンの、キーストアへのインポートの項
このタスクでは、WebGateのCertモード証明書の発行に使用される認証局(CA)証明書をインポートします。このCA証明書が、Access Manager 11.1.2.2.0サーバーが信頼済の証明書とは異なる場合は、このタスクの次の手順を実行します。そうでない場合は、これらのタスクは無視してください。

- aaa_chain.pem: テキスト・エディタを使用してaaa_chain.pemファイルを変更して、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除してからそのファイルを保存します。

- 次のコマンドと環境に応じた詳細を使用して、信頼された証明書チェーンをインポートします。

- 証明書を信頼するかどうか尋ねられたら、「yes」と入力します。

5. Access Manager設定への証明書詳細の追加に関する項
このタスクの、OAMサーバー登録ページを開き、「プロキシ」タブをクリックし、プロキシ・モードを「証明書」に変更して「適用」をクリックする手順は無視してください。

Access Manager 11.1.2.2.0サーバーのCertモード証明書で使用されているルート認証局(CA)が、WebGate側のaaa_chain.pemファイルにあるCA証明書と異なる場合は、aaa_chain.pemファイルを、サーバーのCertモード証明書の発行に使用されるルートCA証明書で更新する必要があります。これを行うには、次の手順を実行します。

1. Access Manager 11.1.2.2.0サーバー・インスタンス用のCertモード証明書の生成に使用された、PEM形式のCA証明書を取得します。

2. 任意のテキスト・エディタでこのCA証明書を開き、このファイルのコンテンツを、BEGIN、ENDマーカーを含めてコピーします。次に例を示します。
----BEGIN CERTIFICATE-----

...

CERTIFICATE

...

-----END CERTIFICATE-----

3. 任意のテキスト・エディタを使用してOHS_INSTANCE_HOME/config/OHS/ohs2/webgate/configにあるaaa_chain.pemファイルを開き、サーバーCA証明書ベースの64エンコードのコンテンツをaaa_chain.pemファイルの最後に貼り付けます。

4. ファイルを保存して閉じます。

2.7.3 Access Manager 11.1.2.2.0サーバー用のSimpleモード通信の構成

Access Manager 11.1.2.2.0サーバー用のSimpleモード通信を構成するには、次の手順を実行します。

1. 次のURLを使用して、Oracle Access Management 11.1.2.2.0管理コンソールにログインします。
http://<host>:<port>/oamconsole

ここで、<host>はAccess Manager 11.1.2.2.0が実行されているマシンであり、<port>はポート番号です。

2. 「システム構成」タブに移動します。

3. 「Access Manager」を開き、「Access Managerの設定」をダブルクリックします。

4. 「アクセス・プロトコル」セクションを開きます。

5. 「グローバル・パスフレーズ」を、Oracle Access Manager 10gデプロイメントで使用されているのと同じ値に設定します。

2.8 管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーの起動

Oracle Access Manager 10gをAccess Manager 11.1.2.2.0への移行を開始する前に、WebLogic管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーが起動しており実行中であることを確認します。管理サーバーおよび管理対象サーバーの起動の詳細は、付録A「サーバーの起動」を参照してください。

2.9 プロパティ・ファイルの作成

アクセス可能な任意の場所にプロパティ・ファイルを作成します。たとえば、oam_migration.propertiesファイルを作成します。

プロパティ・ファイルのコンテンツは、次のようなものです。

## Configuration store details
## If the configuration store is SSL enabled, the LDAP url should begin with 'ldaps'.
config_store_ldap_url=ldap://<Host Name>:<Port>/
config_store_ldap_base=<Configuration store ldap base>
config_store_principal=<Configuration store LDAP Principal>
config_store_password=<Configuration store OAM 10g encrypted password>
config_store_initial_context_factory=com.sun.jndi.ldap.LdapCtxFactory

## Policy store details
## If the policy store is SSL enabled, the LDAP url should begin with 'ldaps'.
policy_store_ldap_url=ldap://<Host Name>:<Port>/
policy_store_ldap_base=<Policy store ldap base>
policy_store_principal=<Policy store LDAP Principal>
policy_store_password=<Policy store OAM 10g encrypted password>
policy_store_initial_context_factory=com.sun.jndi.ldap.LdapCtxFactory

## This property indicates the path of trust store file which is a collective
## store of CA certs of all directory serves viz. policy store, config store,
## identity store.
ldap_trust_store=<path to ldap trust-store>

## This property is required if client authentication in directory
## server is enabled and it contains the path of file having client
## certificates
client_keystore=<path to ketstore file in jks format>

## If ldap_trust_store_password and client_keystore_password are left empty,
## then wlst commandline prompts for these passwords after migration utility
## is run.
ldap_trust_store_password=<plain text password of trust store file>
client_keystore_password=<plain text password of keystore file>

## migration_mode indicates what type of migration does the administrator intends
## to perform.
## 1. COMPLETE   : A full migration will be performed. Ideal for a new OAM 11g
##                 environment with a clean database.
## 2. INCREMENTAL: Incremental mode can be used to migrate selective artifacts
##                 from 10g enviroment. Incremental mode will be dictated by the
##                 include and exclude file properties. Incremental Migration
##                 cannot be performed after Complete Migration.
## 3. DELTA      : When the administrator intends to migrate the changes performed to the 10g artifacts
##                 then delta migration can be performed. This will include all the artifacts depending upon
##                 the GSN number.
## Defaults to COMPLETE if not specified.
migration_mode=COMPLETE

## The include filename property indicates the absolute filename that would
## contain the list of artifacts that the administration wishes to selectively
## migrate to the 11g environment in incremental mode. For migration modes other
## than incremental, this property will be directly ignored.
include_file=<include input filename>

## The exclude filename property indicates the absolute filename that would
## contain the list of artifacts that the administration wishes to selectively
## exclude from migrating to the 11g environment in incremental mode. For
## migration modes other than incremental, this property will be directly ignored.
## In incremental mode migration, if the administrator specifies both the include
## and exclude files then the include file wiil take precedence and exclude file
## will be ignored.
exclude_file=<exclude input filename>

## This flag denotes whether the preview file should be created or not. If true,
## then preview report will be created irrespective of the value of the
## evaluate_only flag. If set to false, then preview report will not be created.
## Defaults to TRUE if not specified.
preview_enabled=true

## Parameter to filter out preview report file based on the compatibility of an
## artifact. It can take values as COMPATIBLE, INCOMPATIBLE and ALL.
## If set to INCOMPATIBLE, it will include records with compatibility as
## INCOMPATIBLE,INCOMPATIBLE_WITH_LESS_FEATURES and IGNORE. If set to COMPATIBLE,
## it will include records with compatibility as COMPATIBLE. If set to ALL,
## it will include all types of record.
## Defaults to INCOMPATIBLE if not specified.
preview_level=ALL

## Indicates the absolute path and filename of the evaluation preview record file.
## If not specified, defaults to
## <MW_Home>/user_projects/domains/base_domain/MigrationPreviewFile.txt
evaluate_filename=<Preview report filename>

## Flag indicating whether the migration utility runs in evalute mode. If true,
## only preview records will be generated and actual migration to 11g environment
## will be skipped. If false, then actual migration will take place.
## Defaults to FALSE if not specified.
evaluate_only=false

## Parameter for indicating the threashold limit for the artifacts processed in
## memory. Can be used on machines with less memory. If not provided, then
## defaults to 5000. If the migration utility is being used in 'evaluate only'
## mode, this value will be ignored.
## If you feel that the memory will not prove to be insufficient for the amount
## of data that is being migrated, set the value to "MAX".
artifact_queue_limit=3000

## Parameter to provide mode of an agent while migration. It will migrate all the
## agents in the mode specified here. The values can be, OPEN, SIMPLE, CERT
## and RETAIN_EXISTING. Defualt value will be RETAIN_EXISTING. This value will
## migrate agent in its existing mode.
agent_mode_to_override=RETAIN_EXISTING

表2-4は、プロパティ・ファイル内の各プロパティに指定する必要のある値を示しています。

表2-4 プロパティ・ファイルの値

プロパティ

説明

config_store_ldap_url

Oracle Access Manager 10gデプロイメントで使用されている構成ストアのLDAPホストとポートを、ldap://<hostname>:<port>という形式で指定します。

構成ストアでSSLが有効化されている場合、LDAPのURLは'ldaps'で始まる必要があります。

config_store_ldap_base

Oracle Access Manager 10gデプロイメントの構成ストア用のLDAP検索ベースを指定します。これは、Oracle Access Manager 10gのインストール時に指定したのと同じ検索ベースです。この値を取得するには、次の手順を実行します。

1. Oracle Access Manager 10g管理コンソールにログインします。

2. 「システム構成」タブに移動します。

3. 左側のナビゲーション・ペインの「サーバー設定」をクリックします。

4. 「構成ベース」に表示されている値をチェックします。oblixの親ノードを使用します。
たとえば、コンソールに表示されている「構成ベース」の値がo=Oblix,dc=company,dc=usである場合、このプロパティconfiguration_store_ldap_baseの値は、dc=company,dc=usである必要があります。

config_store_principal

構成ストアの管理者のLDAP DNを指定します。

config_store_password

Oracle Access Manager 10gの構成LDAPストアの暗号化パスワードを指定します。暗号化パスワードを取得するには、次の手順を実行します。

1. 現在の作業ディレクトリから次の場所に移動します。
Access_Server_Installation Directory/oblix/config/ldap/

2. ConfigDB.xmlファイルからldapRootPasswdの値をコピーします。

3. プロパティ・ファイル内のconfig_store_passwordプロパティにこの値を使用します。

config_store_initial_context_factory

このプロパティの値は、com.sun.jndi.ldap.LdapCtxFactoryである必要があります。この値は修正しないでください。

policy_store_ldap_url

Oracle Access Manager 10gデプロイメントで使用されているポリシー・ストアのLDAPホストとポートを、ldap://<hostname>:<port>という形式で指定します。

ポリシー・ストアでSSLが有効化されている場合、LDAPのURLは'ldaps'で始まる必要があります。

policy_store_ldap_base

Oracle Access Manager 10gデプロイメントのポリシー・ストア用のLDAP検索ベースを指定します。これは、Oracle Access Manager 10gのインストール時に指定したのと同じ検索ベースです。この値を取得するには、次の手順を実行します。

1. Oracle Access Manager 10g管理コンソールにログインします。

2. 「システム構成」タブに移動します。

3. 左側のナビゲーション・ペインの「サーバー設定」をクリックします。

4. 「ポリシー・ベース」に表示されている値をチェックします。oblixの親ノードを使用します。
たとえば、コンソールに表示されている「ポリシー・ベース」の値がo=Oblix,dc=company,dc=usである場合、このプロパティpolicy_store_ldap_baseの値は、dc=company,dc=usである必要があります。

policy_store_principal

ポリシー・ストアの管理者のLDAP DNを指定します。

policy_store_password

Oracle Access Manager 10gのポリシーLDAPストアの暗号化パスワードを指定します。暗号化パスワードを取得するには、次の手順を実行します。

1. 現在の作業ディレクトリから次の場所に移動します。
Access_Server_Installation_Directory/oblix/config/ldap/

2. WebResrcDB.xmlファイルからldapRootPasswdの値をコピーします。

3. プロパティ・ファイル内のpolicy_store_passwordプロパティにこの値を使用します。

policy_store_initial_context_factory

このプロパティの値は、com.sun.jndi.ldap.LdapCtxFactoryである必要があります。この値は修正しないでください。

ldap_trust_store

jks形式のトラスト・ストア・ファイルへのパスを指定します。このファイルには、SSLが有効化されたすべてのディレクトリ・サーバーのCA証明書が格納されています。

client_keystore

jks形式のキーストア・ファイルへのパスを指定します。このファイルには、クライアント証明書が格納されています。このプロパティを指定する必要があるのは、クライアント認証が有効な場合のみです。それ以外の場合は、#を使用してこのプロパティをコメント・アウトします。

ldap_trust_store_password

プロパティldap_trust_storeで指定したトラスト・ストア・ファイルの、プレーン・テキストのパスワードを指定します。

このプロパティの値が空の場合、移行ユーティリティの実行時にWLSTのコマンド行でパスワードの入力を要求されます。

client_keystore_password

プロパティclient_keystoreで指定したキーストア・ファイルの、プレーン・テキストのパスワードを指定します。

このプロパティを指定する必要があるのは、client_keystoreプロパティにキーストア・ファイルのパスを指定した場合のみです。

このプロパティの値が空の場合、移行ユーティリティの実行時にWLSTのコマンド行でパスワードの入力を要求されます。

migration_mode

このプロパティは、実行する移行のモードを示します。次の値のいずれかを設定します。

- COMPLETE
完全移行を実行する場合は、この値を指定します。クリーン・データベースを持つ新しいAccess Manager 11.1.2.2.0環境には、この値が適しています。

- INCREMENTAL
増分移行を実行する場合は、この値を指定します。

増分モードは、プロパティ・ファイルで指定されているinclude_fileおよびexclude_fileプロパティによって決まります。

- DELTA
デルタ移行を実行する場合は、この値を指定します。

移行のモードの詳細は、「移行のモード」を参照してください。

include_file

増分移行を実行する場合、一部のアーティファクトをAccess Manager 11.1.2.2.0に移行するには、include_fileプロパティを使用する必要があります。

include_fileプロパティの値は、Access Manager 11.1.2.2.0に移行するアーティファクトのリストを含むファイルへの絶対パスである必要があります。包含ファイルの作成の詳細は、「増分移行のための追加手順」を参照してください。

include_fileプロパティを指定して増分移行を実行する場合は、exlcude_fileプロパティをコメント・アウトします。

増分移行の実行時に、include_fileとexclude_fileの両方のプロパティを指定した場合、include_fileプロパティがexclude_fileプロパティよりも優先され、exclude_fileプロパティは無視されます。

完全移行では、このプロパティは無視されます。

exclude_file

増分移行を実行する場合、一部のアーティファクトを移行から除外するには、exclude_fileプロパティを使用する必要があります。

exclude_fileプロパティの値は、移行から除外するアーティファクトのリストを含むファイルへの絶対パスである必要があります。除外ファイルの作成の詳細は、「増分移行のための追加手順」を参照してください。

exclude_fileプロパティを指定して増分移行を実行する場合は、inlcude_fileプロパティをコメント・アウトします。

増分移行の実行時に、include_fileとexclude_fileの両方のプロパティを指定した場合、include_fileプロパティがexclude_fileプロパティよりも優先され、exclude_fileプロパティは無視されます。

完全移行では、このプロパティは無視されます。

preview_enabled

このプロパティは、評価レポートを作成するかどうかを示します。このプロパティの値がtrueに設定されている場合は、evaluate_onlyプロパティの値に関係なく、評価レポートが生成されます。

preview_enabledプロパティの値がfalseに設定されている場合は、評価レポートは生成されません。

値を何も指定しないと、デフォルト値であるtrueが使用され、評価レポートが生成されます。

preview_level

このプロパティは、アーティファクトの互換性に基づいて評価レポートのデータをフィルタ処理します。このプロパティには、次のいずれかの値を指定できます。

- COMPATIBLE

- INCOMPATIBLE

- ALL

このプロパティの値がCOMPATIBLEに設定されている場合、評価レポートには、Access Manager 11.1.2.2.0で互換性のあるOracle Access Manager 10gのアーティファクトが含まれます。

このプロパティの値がINCOMPATIBLEに設定されている場合、評価レポートには、Access Manager 11.1.2.2.0で互換性のないOracle Access Manager 10gのアーティファクト、Access Manager 11.1.2.2.0で互換性はあるが機能が低下するアーティファクト、およびAccess Manager 11.1.2.2.0で無視されるアーティファクトが含まれます。

このプロパティの値がALLに設定されている場合、評価レポートには、Access Manager 11.1.2.2.0で互換性のあるOracle Access Manager 10gのアーティファクト、Access Manager 11.1.2.2.0で互換性のないアーティファクト、Access Manager 11.1.2.2.0で互換性はあるが機能が低下するアーティファクト、およびAccess Manager 11.1.2.2.0で無視されるアーティファクトが含まれます。

互換性のないアーティファクト、および互換性はあるが機能が低下するアーティファクトの詳細は、表2-6を参照してください。

evaluate_filename

生成する評価レポート・ファイルの絶対パスとファイル名を指定する必要があります。評価レポートのデフォルトのパスはMW_HOME/user_projects/domains/base_domain/MigrationPreviewFile.txt、デフォルトの名前はMigrationPreviewFile.txtです。

evaluate_only

このプロパティは、移行ユーティリティが評価モードで実行されるかどうかを示します。

このプロパティの値がtrueに設定されている場合、評価レポートが生成されるのみで、Oracle Access Manager 10gはAccess Manager 11.1.2.2.0に移行されません。

このプロパティの値がfalseに設定されている場合、評価レポートが生成され、Oracle Access Manager 10gがAccess Manager 11.1.2.2.0に移行されます。

このプロパティに値を何も指定しないと、デフォルト値であるfalseが使用されます。

artifact_queue_limit

このプロパティは、メモリーで処理されるアーティファクトのしきい値の制限を示します。移行プロセスでメモリーが少ないマシンを使用している場合は、このプロパティを指定できます。

移行されるデータの量が多く、かつメモリーが十分である場合は、このプロパティの値をMAXに設定します。

このプロパティのデフォルト値は5000です。移行ユーティリティが評価モードで実行される場合、このプロパティの値は無視されます。

agent_mode_to_override

このプロパティは、すべてのエージェントが移行されるモードを示します。このプロパティには、次のいずれかの値を指定できます。

- OPEN
すべてのエージェントをOPENモードで移行する場合は、この値を指定します。

- SIMPLE
すべてのエージェントをSIMPLEモードで移行する場合は、この値を指定します。

- CERT
すべてのエージェントをCERTモードで移行する場合は、この値を指定します。

- RETAIN_EXISTING
エージェントをその既存のモードで移行する場合は、この値を指定します。

デフォルト値はRETAIN_EXISTINGです。

注意:

config_store_passwordプロパティの値は暗号化する必要があります。10g_Installation_Directory/Access/oblix/config/ldap/ConfigDB.xmlファイルから暗号化されたパスワードを取得できます。

policy_store_passwordプロパティの値は暗号化する必要があります。10g_Installation_Directory/Access/oblix/config/ldap/WebResrcDB.xmlファイルから暗号化されたパスワードを取得できます。

2.10 評価レポートの生成

Oracle Access Manager 10gアーティファクトをAccess Manager 11.1.2.2.0に移行する前に、評価レポートを生成する必要があります。

評価レポートは、プロパティ・ファイルで該当するプロパティを設定することにより、移行ユーティリティの実行時に生成されるテキスト・ファイルです。評価レポートは、プロパティ・ファイルのevaluate_filenameプロパティで指定した場所に生成されます。

このレポートには、Oracle Access Manager 10gのすべてのアーティファクトに関する情報と、Access Manager 11.1.2.2.0でのそれらの互換性に関する情報が含まれます。

このレポートには、次の3つのデータ・セクションがあります。

1. レポートの分析方法に関する注意事項、およびアーティファクトの互換性に関するいくつかの一般的な情報。

2. Access Manager 11.1.2.2.0で互換性のあるアーティファクト、互換性のないアーティファクト、互換性はあるが機能が低下するアーティファクト、および無視されるアーティファクトの数。

3. Oracle Access Manager 10gのすべてのアーティファクトに関する詳細情報(表形式)。

表2-5は、Oracle Access Manager 10gのアーティファクトに関する情報が表示される表の列を示しています。

表2-5 評価レポートの内容

列番号

列

説明

1

ARTIFACT TYPE

この列には、Oracle Access Manager 10g内のアーティファクトのタイプが表示されます。アーティファクトのタイプは次のとおりです。

- DATA SOURCES

- AUTHENTICATION SCHEMES

- RESOURCE TYPES

- HOST IDs

- AGENTS

- POLICY DOMAINS

2

ARTIFACT

この列には、Oracle Access Manager 10gのすべてのアーティファクトの名前が表示されます。

ポリシー・ドメインの名前は、2つの部分に分かれています。最初の部分はポリシー・ドメインの名前を示し、2番目の部分はポリシー・ドメインのコンテンツを示します。

3

DETAILS

この列には、各アーティファクトに関する情報が表示されます。

- アーティファクト・タイプDATA SOURCESでは、名前、ホストおよびポートがここに示されます。

- アーティファクト・タイプAUTHENTICATION SCHEMESでは、各アーティファクトの説明が表示されます。

- アーティファクト・タイプRESOURCE TYPESでは、アーティファクトの詳細が表示されます(ある場合)。

- アーティファクト・タイプHOST IDsでは、各アーティファクトのホストとポートが表示されます。

- アーティファクト・タイプAGENTSでは、アーティファクトのモードが表示されます。

- アーティファクト・タイプPOLICY DOMAINSでは、ポリシー・ドメインの名前が表示されます。

4

COMPATIBILITY

この列には、Access Manager 11.1.2.2.0でのアーティファクトの互換性に関する情報(アーティファクトがAccess Manager 11.1.2.2.0と互換性があるかどうか)が表示されます。この列のすべてのアーティファクトの値は、次のいずれかです。

- COMPATIBLE: これは、アーティファクトがAccess Manager 11.1.2.2.0でサポートされており、移行ユーティリティでは追加のモデリングは何も実行されないことを示します。

- INCOMPATIBLE: これは、アーティファクトがAccess Manager 11.1.2.2.0でサポートされておらず、移行されないことを示します。

- COMPATIBLE_WITH_LESS_FEATURES: これは、アーティファクトがAccess Manager 11.1.2.2.0で互換性があるが、機能が低下することを示します。このアーティファクトを11.1.2.2.0にマップするために、移行ユーティリティにより一部のモデリングが実行されます。この互換性モードを持つアーティファクトはすべて移行されます。

- IGNORE: これは、アーティファクトがAccess Manager 11.1.2.2.0では有用でなく、したがって移行時に無視されることを示します。

5

MESSAGE

この列には、各アーティファクトの移行に関連するメッセージが表示されます。

6

ACTION REQUIRED

この列には、ユーザーによって要求されたアクションが表示されます(ある場合)。

注意:

評価レポートで生成されるデータのレベルは、プロパティ・ファイルのpreview_levelプロパティによって決まります。

Oracle Access Manager 10gのアーティファクトをAccess Manager 11.1.2.2.0に実際に移行する前に、評価レポートを複数回生成できます。

表2-6は、Access Manager 11.1.2.2.0で互換性のないOracle Access Manager 10gのアーティファクトのタイプ、および互換性はあるが機能が低下するアーティファクトのタイプを示しています。

表2-6 評価レポートのサマリー

アーティファクト

説明

INCOMPATIBLE

- 異種リソース・タイプのURL接頭辞を含むポリシー・ドメインは、Access Manager 11.1.2.2.0環境と互換性がありません。

- タイプHTTPに対する操作OTHERは、Access Manager 11.1.2.2.0と互換性がなく、移行されません。

- ポリシー・ドメインに関連付けられた委任管理権限は、移行の対象として見なされません。

- 255文字を超えるWebGateプロファイル名は移行されません。

- カスタムの認証プラグインを含む認証スキームは移行されません。

COMPATIBLE_WITH_LESS_FEATURES

- ポリシー・ドメインでIGNOREと識別されるリソースは、COMPATIBLE_WITH_LESS_FEATURESとしてマークされます。

- Access Manager 11.1.2.2.0では、問合せ文字列パターンと問合せの名前と値のペアのいずれかを指定できます。移行時、ポリシーに問合せ文字列と問合せの名前と値のペアの両方がある場合、問合せ文字列のみが移行されます。

- DAPなどの外部認証スキームはサポートされていません。

- ホスト名のバリエーションの形式が正しくない場合、またはポート値が数値でない場合は、ホスト識別子はCOMPATIBLE_WITH_LESS_FEATURESとしてマークされます。

- ホスト名のバリエーションが他のホスト識別子内に存在する場合、ホスト識別子から削除され、COMPATIBLE_WITH_LESS_FEATURESとしてマークされます。

- Oracle Access Manager 10gポリシー・ドメインの認可ルールの、時刻や「曜日」などのタイミング条件は、Access Manager 11.1.2.2.0に移行されます。「月」や「日付」などの、その他の条件は、Access Manager 11.1.2.2.0ではサポートされていないため、移行されません。

- 255文字を超える名前と1024文字を超える説明を持つアーティファクトは、移行されますが、機能が低下します。移行ユーティリティでは、255文字を超えるアーティファクト名は切り捨てられ、説明の先頭にこの切り捨てられた名前が追加されます。アーティファクトの説明が1024文字を超える場合、超えた文字は、移行時に失われます。

評価レポートを生成するには、次の手順を実行します。

1. 第2.9項「プロパティ・ファイルの作成」で作成したプロパティ・ファイルを次のように編集します。

1. migration_modeプロパティの値をCOMPLETEに設定します。

2. preview_enabledプロパティの値をtrueに設定します。

3. evaluate_onlyプロパティの値をtrueに設定します。

4. 評価レポート・ファイルの絶対パスをevaluate_filenameプロパティに設定したことを確認します。

5. プロパティ・ファイルを保存して閉じます。

2. 第2.13項「Access Manager 11.1.2.2.0へのOracle Access Manager 10gのアーティファクトの移行」の手順2から手順6を実行します。
これにより、作成したプロパティ・ファイルのevaluate_filenameプロパティで指定されている場所に評価レポートが作成されます。このレポートは、Microsoft Excelで開くこともできます。評価レポートに含まれるレコードは、プロパティ・ファイルのpreview_levelプロパティで設定された値に基づきます。

プロパティ・ファイルのevaluate_onlyプロパティがtrueに設定されているため、移行ユーティリティでは、評価レポートのみが生成され、Oracle Access Manager 10gのアーティファクトの移行は実行されません。

注意:

移行を開始する前に、評価レポートを分析し、Oracle Access Manager 10g環境に必要な変更を加えることができます。

評価レポートを生成し、Oracle Access Manager 10gのアーティファクトを移行する場合は、evaluate_onlyプロパティの値をfalseに設定し、第2.13項「Access Manager 11.1.2.2.0へのOracle Access Manager 10gのアーティファクトの移行」に記載されている手順を実行します。

注意:

評価レポートを生成すると、移行ユーティリティによって、評価レポートが生成される場所と同じ場所にIncludeFile.txtというテキスト・ファイルも生成されます。このファイルでは、増分移行を実行する際に移行するアーティファクトを指定できます。増分移行でのIncludeFile.txtの使用の詳細は、「増分移行のための追加手順」を参照してください。

2.11 管理サーバーの再起動

次の手順を実行して、Access Manager 11.1.2.2.0でドメインのWebLogic管理サーバーを再起動します。

1. WebLogic管理サーバーを停止します。

2. WebLogic管理サーバーを起動します。

管理サーバーの停止の詳細は、付録A「WebLogic管理サーバーの停止」を参照してください。

管理サーバーの起動の詳細は、付録A「WebLogic管理サーバーの起動」を参照してください。

2.12 増分移行のための追加手順

増分移行を実行する場合のみ、次の手順を実行します。

1. 移行プロセスで作成するプロパティ・ファイル(第2.9項「プロパティ・ファイルの作成」)でmigration_modeプロパティをINCREMENTALに設定します。

2. 評価レポートを生成すると(「評価レポートの生成」を参照)、評価レポートが生成される場所と同じ場所にIncludeFile.txtという入力ファイルが生成されます。このテキスト・ファイルには、Oracle Access Manager 10gデプロイメントのエージェントおよびアプリケーション・ドメインが格納されています。エージェントとアプリケーション・ドメインは、次の例のようにIncludeFile.txtにリストされます。

AGENT##ag_one_12752##ag_one_12752##N
AGENT##temp##temp##N
APPLICATION_DOMAIN##20120304T01055680323##my_domain##N
APPLICATION_DOMAIN##20120306T03491413638##Finance##N
APPLICATION_DOMAIN##20120306T04155393859##HR##N
APPLICATION_DOMAIN##20120319T0255014722##Domain With Resources Only##N
APPLICATION_DOMAIN##20120319T03241993733##Domain with Policy##N
APPLICATION_DOMAIN##20120319T03300047441##Domain with policy and authn rule##N
APPLICATION_DOMAIN##20120319T03324669347##domain with policy and authz rule##N

増分移行を実行するには、移行するアーティファクト(エージェントとアプリケーション・ドメイン)のリスト、または移行から除外するアーティファクト(エージェントとアプリケーション・ドメイン)のリストを指定する必要があります。そのため、次のいずれかのファイルを作成する必要があります。

- 包含ファイル: 移行するエージェントおよびアプリケーション・ドメインのリストが格納されたテキスト・ファイルです。移行するエージェントおよびアプリケーション・ドメインをYとしてマークして、自動生成されるIncludeFile.txtをincludeファイルとして使用することも、新しいincludeファイルを手動で作成することもできます。ただし、IncludeFile.txtを使用してincludeファイルを作成することをお薦めします。
IncludeFile.txtを使用してincludeファイルを作成するには、次の手順を実行します。

a. アクセス可能な任意の場所にIncludeFile.txtをコピーし、必要に応じて、名前をinclude.txtに変更します。

b. 移行するエージェントおよびアプリケーション・ドメインをYとしてマークします。Yは、アーティファクトが増分移行の対象として選択されることを示します。

c. プロパティ・ファイル(oam_migration.properties)のinclude_fileプロパティを、includeファイルへの絶対パスに設定します。

注意:

手動でincludeファイルを作成する場合は、移行するエージェントおよびアプリケーション・ドメインを、次の例に示されている形式で指定します。

AGENT##temp##temp##Y

APPLICATION_DOMAIN##20120304T01055680323##my_domain##Y

- 除外ファイル: 移行から除外するエージェントおよびアプリケーション・ドメインのリストが格納されたテキスト・ファイルです。移行から除外するエージェントおよびアプリケーション・ドメインをYとしてマークして、自動生成されるIncludeFile.txtをexcludeファイルとして使用することも、新しいexcludeファイルを手動で作成することもできます。ただし、IncludeFile.txtを使用してexcludeファイルを作成することをお薦めします。
IncludeFile.txtを使用してexcludeファイルを作成するには、次の手順を実行します。

a. アクセス可能な任意の場所にIncludeFile.txtをコピーし、必要に応じて、名前をexclude.txtに変更します。

b. 移行から除外するエージェントおよびアプリケーション・ドメインをYとしてマークします。Yは、アーティファクトが増分移行の対象として選択されないことを示します。

c. プロパティ・ファイル(oam_migration.properties)のexclude_fileプロパティを、excludeファイルへの絶対パスに設定します。

注意:

手動でexcludeファイルを作成する場合は、増分移行から除外するエージェントおよびアプリケーション・ドメインを、次の例に示されている形式で指定します。

AGENT##temp##temp##Y

APPLICATION_DOMAIN##20120304T01055680323##my_domain##Y

注意:

includeファイルとexcludeファイルの両方を作成し、プロパティ・ファイルで両方のファイルのパスを指定した場合、includeファイルが優先され、excludeファイルは無視されます。

プロパティ・ファイルでこれらの入力ファイルを何も指定しないと、移行は中断されます。

増分移行は複数回実行できます。

2.13 Access Manager 11.1.2.2.0へのOracle Access Manager 10gのアーティファクトの移行

Oracle Access Manager 10gをAccess Manager 11.1.2.2.0に移行する前に、(第2.10項「評価レポートの生成」の説明に従って)評価レポートを生成し、Access Manager 11.1.2.2.0で互換性のあるアーティファクトと互換性のないアーティファクトを分析することをお薦めします。

注意:

評価レポートの分析後、Oracle Access Manager 10gをAccess Manager 11.1.2.2.0に移行する場合は、この項の手順1から6を実行します。

増分移行を実行する場合は、プロパティ・ファイルでmigration_modeプロパティがINCREMENTALに設定されていることを確認してください。また、この項で説明する手順を実行する前に、第2.12項「増分移行のための追加手順」に記載されている追加手順を完了していることを確認してください。

完全移行を実行する場合は、プロパティ・ファイルでmigration_modeプロパティがCOMPLETEに設定されていることを確認してください。

完全移行または増分移行を実行するには、次の手順を実行します。

1. 「プロパティ・ファイルの作成」で作成したプロパティ・ファイルでevaluate_onlyプロパティの値をfalseに設定します。ファイルを保存して閉じます。

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME/common/binディレクトリに移動します。
cd IAM_HOME/common/bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
./wlst.sh

Windowsの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME\common\binディレクトリに移動します。
cd IAM_HOME\common\bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
wlst.cmd

3. 次のコマンドを実行して、WLSTをWebLogic Serverインスタンスに接続します。

connect('wls_admin_username','wls_admin_password','t3://hostname:port');

このコマンドでは、次のように指定します。

wls_admin_usernameは、WebLogic管理サーバーのユーザー名です。

wls_admin_passwordは、WebLogic管理サーバーのパスワードです。

hostnameは、WebLogic管理サーバーが実行されているホストです。

portは、WebLogic管理サーバーのポートです。

次に例を示します。

connect('weblogic','password','t3://localhost:7001');

4. 次のコマンドを実行します。

domainRuntime();

5. 次のコマンドを実行します。

setLogLevel(logger="oracle.oam",level="TRACE:32",persist="0",target="AdminServer");

6. 次のコマンドを実行して、Oracle Access Manager 10gのアーティファクトをAccess Manager 11.1.2.2.0に移行します。

oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="absolute_path_of_properties_file");

各項目は次のとおりです。

absolute_path_of_properties_fileは、「プロパティ・ファイルの作成」で作成したプロパティ・ファイルの絶対パスです。次に例を示します。

UNIXの場合: oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="abc/def/oam_migration.properties"

Windowsの場合: oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="abc\\def\\oam_migration.properties"

移行が完了すると、WLSTコンソールに、移行の結果を示すメッセージが表示されます。ログ・ファイルは次の場所に生成されます。

UNIXの場合: MW_HOME/user_projects/domains/base_domain/servers/AdminServer/logs/Adminserver-diagnostic*.log

Windowsの場合: MW_HOME\user_projects\domains/base_domain\servers\AdminServer\logs/Adminserver-diagnostic*.log

移行プロセスでなんらかのエラーが発生した場合は、ログ・ファイルを参照してください。

2.14 Access Manager 11.1.2.2.0使用時の10g WebGateの集中ログアウトの構成

Access Manager 11.1.2.2.0で10g WebGateを使用する場合、Oracle Access Manager 10gをAccess Manager 11.1.2.2.0に移行した後、Access Manager 11.1.2.2.0サーバーと連携するように10g WebGateの集中ログアウトの設定を構成する必要があります。

10g WebGateの集中ログアウトの構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の11g OAMサーバー使用時の10g WebGateの集中ログアウトの構成に関する項を参照してください。

注意:

Access Manager 11.1.2.2.0で10g WebGateを使用しない場合は、この手順をスキップしてください。

2.15 Access Manager 11.1.2.2.0サーバーとWebGateの関連付け

Oracle Access Manager 10gをAccess Manager 11.1.2.2.0に移行した後、移行されたすべてのWebGateをAccess Manager 11.1.2.2.0サーバーに関連付ける必要があります。これを行うには、次の手順を実行します。

1. Access Manager 11.1.2.2.0サーバー・インスタンスのホスト名とポートの詳細を使用して、Oracle Access Manager 10gアクセス・システム・コンソール上に新しいサーバー・プロファイルを作成します。それには、次の手順を実行します。

1. Oracle Access Manager 10gアクセス・システム・コンソールにログインします。

2. 「アクセス・システム構成」タブに移動します。

3. 左側のナビゲーション・ペインの「アクセス・サーバー構成」をクリックします。

4. 「追加」をクリックして、新しいサーバー・プロファイルを作成します。

5. 次の詳細を指定します。
名前: このサーバーの名前を指定します。

ホスト名: Access Manager 11.1.2.2.0サーバー・インスタンスが実行されているマシンのホスト名を指定します。

ポート: Access Manager 11.1.2.2.0サーバー・インスタンスのプロキシ・ポートを指定します。Access Manager 11.1.2.2.0のデフォルトのプロキシ・ポートは5575です。

トランスポート・セキュリティ: Access Manager 11.1.2.2.0サーバー・インスタンスと同じトランスポート・セキュリティ・モードを指定します。

他のパラメータについてはデフォルト値のままにします。

6. 「保存」をクリックします。

2. 関連付けの後でAccess Manager 11.1.2.2.0サーバーとの接続を確立できないWebGateのプロファイル内のWebGate (AccessGate)のMAX Connectionsパラメータの値を設定します。
Oracle Access Manager 10gのプライマリ・サーバーがすべて起動している場合、MAX Connectionsの値を、Oracle Access Manager 10gのすべてのプライマリ・サーバーへの接続数の合計と同じ数に設定します。

WebGateプロファイルの変更に関する詳細は、Oracle Access Managerアクセス管理ガイドリリース10g (10.1.4.3)のアクセス・ゲートの変更に関する項を参照してください。

3. 既存のOracle Access Manager 10gサーバーを保持することで、各WebGateを1つ以上のプライマリ・サーバーとしてAccess Manager 11.1.2.2.0サーバーに関連付けます。Access Manager 11.1.2.2.0サーバーへの接続数を1以上に設定します。
非アクティブな再構成期間の後、WebGateは、サーバーの新しいリストで更新されます。

4. オプション: 各WebGateで、webgate_installation_directory/oblix/lib/ObAccessClient.xmlにあるObAccessClient.xmlファイルが、プライマリ・サーバーのリスト内のAccess Manager 11.1.2.2.0サーバーのホストとポートで更新されることを確認します。これを行うには、ObAccessClient.xmlファイルを開き、プライマリ・サーバーのリストを探します。

5. 次のタスクのいずれかを実行して、WebGateをAccess Manager 11.1.2.2.0サーバーにポイントします。

- すべてのOracle Access Manager 10gサーバーを停止します。Oracle Access Manager 10gサーバーへの接続数が多い場合、WebGateがAccess Manager 11.1.2.2.0サーバーとの通信を開始するには数分かかります。WebGateをホストするWebサーバーを再起動すると、WebGateはただちに、Access Manager 11.1.2.2.0サーバーとの通信を開始します。

- MAX Connectionsパラメータの値を1つ増やして、WebGateがAccess Manager 11.1.2.2.0サーバーとの通信を確立できるようにします。WebGate上でのロードが大きいほど、Access Manager 11.1.2.2.0サーバーへの接続にかかる時間は短くなります。

WebGateは、Access Manager 11.1.2.2.0サーバーからの新しい構成情報を取得しますが、Access Manager 11.1.2サーバーのプライマリ・サーバーは1つのみです。そのため、WebGateは、Access Manager 11.1.2.2.0サーバーとのみ通信します。こうしておけば、サーバーは1つしかないので、MAX Connectionsの値を減らすことができます。

2.16 移行の確認

移行を確認するには、次の手順を実行します。

1. 移行が成功すると、WLSTコンソールに「移行が正常に完了しました。」というメッセージが表示されます。

2. 次のディレクトリに生成されているoam-config.xmlファイルで、アップグレードされたステータス、移行のタイプ、タイムスタンプなどの移行の詳細を確認します。
UNIXの場合:

MW_HOME/user_projects/domains/Domain_Name/config/fmwconfig/

Windowsの場合:

MW_HOME\user_projects\domains\Domain_Name\config\fmwconfig\

3. 次のURLを使用してOracle Access Managementコンソールにログインします。

http://host:port/oamconsole

このURLで、hostはAccess Manager 11.1.2.2.0が実行されているマシン、およびportはポート番号です。

Oracle Access Manager 10gのアーティファクトがAccess Manager 11.1.2.2.0に移行されたことを確認します。

注意:

これで、移行は完了です。Oracle Access Management Access Manager 11.1.2.2.0の管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。

2.17 トラブルシューティング

この項では、Oracle Access Manager 10gをAccess Manager 11.1.2.2.0に移行するときに発生する可能性のある一般的な問題の解決策について説明します。内容は次のとおりです。

- 移行データの損失を防ぐためにログ・ファイルのサイズを増やす

- WebLogic Serverのヒープ・サイズを増やす

- Oracle Access Managerの移行時にLDAPページング機能が動作しない場合がある

2.17.1 移行データの損失を防ぐためにログ・ファイルのサイズを増やす

ログ・ファイルのサイズが小さすぎると、ログ・ファイルのローテーション時に移行データが失われるおそれがあります。この問題を解決するには、次の手順を実行して、WebLogicコンソールでログ・ファイルのサイズを増やす必要があります。

1. 次のURLを使用してWebLogic管理コンソールにログインします。

http://host:port/console

このURLで、hostはWebLogic管理サーバーをホストするマシンのホスト名、およびportは管理サーバーのポート番号です。

2. 左側のナビゲーション・ペインの「ドメイン構造」で、それぞれのドメイン名の下の「環境」を開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページで、「構成」タブに移動し、管理サーバーの名前(たとえば、「AdminServer(admin」))をクリックします。

5. 「ロギング」タブに移動し、「一般」タブをクリックします。

6. 次のフィールドに適切な値を指定します。

1. ローテーション・ファイル・サイズ: ログ・ファイルのサイズをKB単位で指定します。指定できる最大値は65535 KBです。

2. 保存するファイル数: 保存する、ローテーションされたログ・ファイルの数を指定します。

7. 「保存」をクリックします。

2.17.2 WebLogic Serverのヒープ・サイズを増やす

Oracle Access Manager 10gのポリシー・データが(様々なポリシー関連アーティファクトの数という点で)大規模である場合、移行ツールで、処理のために大量のメモリーが必要になる可能性があります。WebLogic管理サーバーのヒープ・サイズが小さい場合は、次の手順を実行して、そのサイズを増やすことができます。

UNIXの場合:

1. ディレクトリMW_HOME/user_projects/domains/Domain_Name/bin/から、任意のテキスト・エディタでsetDomainEnv.shファイルを開きます。

2. 次の行を検索します。

if [ "${USER_MEM_ARGS}" != "" ]

3. 前の手順で特定した行のすぐ前に、次の行を追加します。

USER_MEM_ARGS="new_heap_size"
export USER_MEM_ARGS

ここで、new_heap_sizeは、WebLogic管理サーバーの新たなヒープ・サイズ(MB単位)です。

たとえば、WebLogic管理サーバーのヒープ・サイズを2GBに増やすには、次のように指定します。

USER_MEM_ARGS="-Xms2048m -Xmx2048m"
export USER_MEM_ARGS

Windowsの場合:

1. ディレクトリMW_HOME\user_projects\domains\Domain_Name\bin\から、任意のテキスト・エディタでsetDomainEnv.cmdファイルを開きます。

2. 次の行を検索します。

if NOT "%USER_MEM_ARGS%"=="" (

3. 前の手順で特定した行のすぐ前に、次の行を追加します。

set USER_MEM_ARGS="new_heap_size"

ここで、new_heap_sizeは、WebLogic管理サーバーの新たなヒープ・サイズ(MB単位)です。

たとえば、WebLogic管理サーバーのヒープ・サイズを2GBに増やすには、次のように指定します。

set USER_MEM_ARGS=-Xms2048m -Xmx2048m

2.17.3 Oracle Access Managerの移行時にLDAPページング機能が動作しない場合がある

一部のディレクトリまたは特別な構成では、Oracle Access Manager 10gの移行時にLDAPページング機能が動作しない場合があります。このような場合は、プロパティenable_ldap_pagingを第2.9項「プロパティ・ファイルの作成」で作成したoam_migration.propertiesファイルに追加し、このプロパティの値をfalseに設定して、LDAPページングを無効化します。

プロパティenable_ldap_pagingをfalseに設定すると、移行ツールによってすべてのLDAPエントリが一度に取得されます。データ・サイズが大きい場合にこのプロパティをfalseに取得するときは、Oracle Access Manager管理サーバー・プロセスのヒープ・サイズを増やすことをお薦めします。

3 Oracle Adaptive Access Manager 10g環境の移行

この章では、既存のOracle Adaptive Access Manager (OAAM) 10g環境をOracle Adaptive Access Manager 11gリリース2 (11.1.2.2.0)に移行する方法について説明します。

この章には次の項が含まれます:

- 第3.1項「移行の概要」

- 第3.2項「トポロジの比較」

- 第3.3項「移行ロードマップ」

- 第3.4項「移行の前提条件」

- 第3.5項「Oracle Identity and Access Management11.1.2.2.0のインストール」

- 第3.6項「Oracle Platform Security Servicesスキーマの作成」

- 第3.7項「OAAM 10gスキーマのアップグレード」

- 第3.8項「新規または既存のOracle WebLogicドメインOAAM 11.1.2.2.0の構成」

- 第3.9項「データベース・セキュリティ・ストアの構成」

- 第3.10項「ノード・マネージャの構成」

- 第3.11項「WebLogic管理サーバーの起動」

- 第3.12項「OAAM管理対象サーバーの停止」

- 第3.13項「アップグレード・アシスタントを使用したOAAM中間層のアップグレード」

- 第3.14項「OAAM管理対象サーバーの起動」

- 第3.15項「移行の確認」

3.1 移行の概要

OAAM 10gからOAAM 11.1.2.2.0の移行プロセスには、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)のインストール、OAAM 11.1.2.2.0の構成、OAAM 10gスキーマのアップグレード、データベース・セキュリティ・ストアの構成およびOracle Adaptive Access Manager中間層のアップグレードが含まれます。

他の移行シナリオの詳細は、第1.2項「移行および共存のシナリオ」を参照してください。

3.2 トポロジの比較

図3-1は、OAAM 10gとOAAM 11.1.2.2.0のトポロジを比較したものです。

図3-1 OAAM 10gとOAAM 11gのトポロジの比較

3.3 移行ロードマップ

表3-1は、移行ロードマップを示しています。

表3-1 タスク・ロードマップ

タスク番号

タスク

参照先

1

前提条件を満たします。

「移行の前提条件」を参照してください。

2

Oracle Identity and Access Management 11.1.2.2.0をインストールします。

「Oracle Identity and Access Management 11.1.2.2.0のインストール」を参照してください。

3

リポジトリ作成ユーティリティ(RCU)を使用して、Oracle Platform Security Services (OPSS)スキーマとMetadata Services (MDS)スキーマを作成します。

「Oracle Platform Security Servicesスキーマの作成」を参照してください。

4

アップグレード・アシスタントを使用してOAAM 10gスキーマをアップグレードします。

「OAAM 10gスキーマのアップグレード」を参照してください。

5

新規または既存ドメインでOAAM 11.1.2.2.0を構成します。

「新規または既存Oracle WebLogicドメインでのOAAM 11.1.2.2.0の構成」を参照してください。

6

configuresecuritystore.pyスクリプトを実行して、データベース・セキュリティ・ストアを構成します。

「データベース・セキュリティ・ストアの構成」を参照してください。

7

ノード・マネージャを構成します。

「ノード・マネージャの構成」を参照してください。

8

WebLogic管理サーバーを起動します。

「WebLogic管理サーバーの起動」を参照してください。

9

OAAM管理対象サーバー(OAAM管理サーバー、OAAMサーバーおよびOAAMオフライン・サーバー)を停止します。

「OAAM管理対象サーバーの停止」を参照してください。

10

アップグレード・アシスタントを使用してOAAM中間層をアップグレードします。

「アップグレード・アシスタントを使用したOAAM中間層のアップグレード」を参照してください。

11

OAAM管理対象サーバー(OAAM管理サーバー、OAAMサーバーおよびOAAMオフライン・サーバー)を起動します。

「OAAM管理対象サーバーの起動」を参照してください。

12

移行を確認します。

「移行の確認」を参照してください。

3.4 移行の前提条件

次のOracle Adaptive Access Manager 10gからOracle Adaptive Access Manager 11.1.2.2.0への移行の前提条件を実行しておく必要があります。

1. システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

2. 使用しているOracle Adaptive Access Manager 10gバージョンが移行のサポート対象であることを確認します。Oracle Adaptive Access Manager 10gの移行がサポートされている開始ポイントについては、第1.4.2項「Oracle Adaptive Access Manager 10gの移行がサポートされている開始ポイント」を参照してください。

3. oaam_offlineサーバー10gを11.1.2.2.0にアップグレードする場合に、oaam_server 10gスキーマからロードするスケジュール済ロード・ジョブがあるときは、oaam_serverをアップグレードしてからoaam_offlineサーバー(第3.14項「OAAM管理対象サーバーの起動」を参照)を起動する必要があります。oaam_serverスキーマをアップグレードできない場合、次のSQL文を実行して、oaam_serverスキーマでビューを作成する必要があります。

create or replace view oaam_load_data_view as
select l.create_time LOGIN_TIMESTAMP, l.request_id SESSION_ID,
l.user_id USER_ID, l.user_login_id LOGIN_ID, l.node_id DEVICE_ID,
l.user_group_id GROUP_ID, l.remote_ip_addr IP_ADDRESS,
l.auth_status AUTH_STATUS, l.auth_client_type_code CLIENT_TYPE,
(SELECT t1.data_value FROM v_fprints t1
WHERE t1.fprint_id=l.fprint_id) USER_AGENT,
(SELECT t2.data_value FROM v_fprints t2
WHERE t2.fprint_id=l.digital_fp_id) FLASH_FINGERPRINT,
l.sent_dig_sig_cookie DIGITAL_COOKIE,
l.expected_dig_sig_cookie EXP_DIGITAL_COOKIE,
l.sent_secure_cookie SECURE_COOKIE,
l.expected_secure_cookie EXP_SECURE_COOKIE
from vcrypt_tracker_usernode_logs l;

注意:

次のSQL文を実行して、データベース内のすべてのOAAMスキーマとそのバージョン番号をリストできます。

SELECT OWNER, VERSION FROM SCHEMA_VERSION_REGISTRY WHERE COMP_ID = 'OAAM';

oaam_offline、oaam_adminおよびoaam_serverを同時にアップグレードする場合は、このプレアップグレード・タスクを省略できます。

3.5 Oracle Identity and Access Management 11.1.2.2.0のインストール

移行プロセスの一部として、Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)をインストールする必要があります。

Oracle Identity and Access Management 11.1.2.2.0のインストールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.2.0)のインストールに関する説明を参照してください。

3.6 Oracle Platform Security Servicesスキーマの作成

リポジトリ作成ユーティリティ(RCU) 11.1.2.2.0を実行して、次のスキーマを作成します。IAU(監査スキーマ)はオプションです。

- Oracle Platform Security Services (OPSS) - (必須)

- Metadata Services (MDS) - (必須)

- IAU(監査スキーマ) - (オプション)

スキーマの作成の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』のスキーマの作成に関する項を参照してください。

3.7 OAAM 10gスキーマのアップグレード

アップグレード・アシスタントを実行して、OAAM 10gスキーマを11.1.2.2.0にアップグレードする必要があります。これを行うには、次の手順を実行します。

1. ORACLE_HOME/binから次のコマンドを実行して、アップグレード・アシスタントを起動します。
UNIXの場合: ./ua

Windowsの場合: ua.bat

2. Oracle Fusion Middlewareのアップグレード・アシスタントの「ようこそ」画面が表示されます。「次へ」をクリックします。

3. 「操作の指定」画面が表示されます。「Oracle Adaptive Access Managerスキーマのアップグレード」オプションを選択して、「次へ」をクリックします。

4. 「前提条件」画面が表示されます。データベース・スキーマのバックアップを完了済および「Fusion Middlewareのアップグレードを行うデータベースのバージョンがOracleにより動作保証済」オプションを選択し、「次へ」をクリックします。

注意:

「前提条件」画面でデータベース・スキーマのバックアップを完了済を選択する前に、データベース・スキーマをバックアップしていることを確認してください。また、「前提条件」画面で「Fusion Middlewareのアップグレードを行うデータベースのバージョンがOracleにより動作保証済」を選択する前に、使用しているデータベースがOracle Adaptive Access Manager 11.1.2.2.0でサポートされていることを確認してください。

5. 「OAAMソース・データベースの指定」画面が表示されます。次の情報を入力します。

- データベース・タイプ: ドロップダウン・リストからデータベース・タイプを選択します。

- 接続文字列: 次の形式でデータベースの接続文字列を入力します。
host:port:sid

- OAAMスキーマ・ユーザー: Oracle Adaptive Access Manager 10gスキーマ・ユーザー名を入力します。

- DBAユーザー: データベースのDBAユーザー名を入力します。

- DBAパスワード: DBAユーザーのパスワードを入力します。

「次へ」をクリックします。

6. 「コンポーネントの調査」画面が表示されます。
アップグレード・アシスタントは、コンポーネントを調べ、ソースおよびターゲットの各スキーマに予想される列が含まれていることを確認します。

操作が成功すると、「ステータス」列に「成功」が表示されます。「ステータス」に「失敗」が表示された場合、詳細はログ・ファイルua.logを確認します。ログ・ファイルを表示するには、画面最下部のリンクをクリックします。

「ステータス」に「成功」が表示された場合、「次へ」をクリックします。

7. 「アップグレード・サマリー」画面が表示されます。「アップグレード」をクリックします。

8. 「アップグレードの進行状況」画面が表示されます。この画面には次の情報が表示されます。

- アップグレードのステータス

- アップグレード中に発生したエラーまたは問題

「次へ」をクリックします。

9. 「アップグレード完了」画面が表示されます。この画面はアップグレードが完了していることを確認します。

10. 「閉じる」をクリックします。

3.8 新規または既存Oracle WebLogicドメインでのOAAM 11.1.2.2.0の構成

ソフトウェアをインストールした後、Oracle Adaptive Access Manager 11.1.2.2.0を構成する必要があります。OAAMは、新規または既存ドメインで構成できます。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Adaptive Access Managerの構成に関する項を参照してください。

注意:

Oracle Adaptive Access Manager 11gのデータベースの詳細の入力を求める画面では、必ずOracle Adaptive Access Manager 10gのデータベースの詳細を指定します。別の11gのデータベースはないため、10gの資格証明を入力する必要があります。Oracle Adaptive Access Manager 10gのデータベースには存在しないいくつかのシステム表について、データベースがチェックされます。

3.9 データベース・セキュリティ・ストアの構成

ドメインでOAAM 11.1.2.2.0を構成した後、configuresecuritystore.pyスクリプトを実行してデータベース・セキュリティ・ストアを構成します。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Managementドメインに対するデータベース・セキュリティ・ストアの構成に関する項を参照してください。

注意:

第3.8項「新規または既存のOracle WebLogicドメインOAAM 11.1.2.2.0の構成」のOAAM 11.1.2.2.0の構成の一環としてconfiguresecuritystore.pyスクリプトをすでに実行している場合、このタスクは無視します。

3.10 ノード・マネージャの構成

WebLogic管理コンソールを使用して管理対象サーバーを起動または停止する場合、ノード・マネージャを構成して起動する必要があります。ノード・マネージャの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』の管理対象サーバーを起動するためのノード・マネージャの構成に関する項を参照してください。

3.11 WebLogic管理サーバーの起動

WebLogic管理サーバーを起動するには、付録A「WebLogic管理サーバーの起動」に説明されている手順を実行します。

3.12 OAAM管理対象サーバーの停止

OAAM管理サーバー、OAAMオフライン・サーバー(存在する場合)およびOAAMサーバーを起動している場合、それらをすべて停止してからでないと、OAAM中間層のアップグレードを実行できません。

管理対象サーバーの停止の詳細は、付録A「管理対象サーバーの停止」を参照してください。

注意:

複数のOAAMサーバーが存在する場合、それらをすべて停止する必要があります。

3.13 アップグレード・アシスタントを使用したOAAM中間層のアップグレード

アップグレード・アシスタントを使用して、OAAM 10g中間層をアップグレードする必要があります。これを行うには、次の手順を実行します。

1. Oracle Adaptive Access Manager管理対象サーバーが起動している場合は、暗号化または復号化のために必要な対称鍵が自動的に生成されます。中間層のアップグレードを実行する前に、鍵を削除する必要があります。これを行うには、次の手順を完了します。

1. URLを使用して、Oracle Enterprise Managerにログインします。
host:port/em

2. 左側のペインでWebLogicドメインを開き、OAAMドメインを選択します。
OAAMドメインのページが表示されます。

3. OAAMドメインから「セキュリティ」を選択し、「資格証明」を選択します。
「資格証明」ページが表示されます。

4. oaamを開き、対称鍵関連のエントリを削除します。

2. 次の手順を実行して、アップグレード・アシスタントを起動します。
UNIXの場合:

1. 次のコマンドを使用して、現在の作業ディレクトリからMW_HOME/IAM_HOME/binディレクトリに移動します。

cd MW_HOME/IAM_HOME/bin

2. 次のコマンドを実行します。

./ua

Windowsの場合:

1. コマンド行で次のコマンドを使用して、現在の作業ディレクトリからMW_HOME\IAM_HOME\binディレクトリに移動します。

cd MW_HOME\IAM_HOME\bin

2. 次のコマンドを実行します。

ua.bat

Oracle Fusion Middlewareのアップグレード・アシスタントの「ようこそ」画面が表示されます。

3. 「次へ」をクリックします。
「操作の指定」画面が表示されます。

4. 「Oracle Adaptive Access Manager中間層のアップグレード」を選択します。
アップグレード・アシスタントで使用可能なオプションは、アシスタントを起動したOracleホーム固有のものです。Oracle Application Server Identity ManagementのOracleホームからアップグレード・アシスタントを起動する場合、「操作の指定」画面に表示されるオプションが、Oracle Application Server Identity ManagementのOracleホームに対して有効なオプションです。

5. 「次へ」をクリックします。
「ソース詳細の指定」画面が表示されます。

6. 次の情報を入力します。

- 「参照」をクリックして、Oracle Adaptive Access Manager Adaptive Strong Authenticator Webアプリケーション(ASA) 10gおよびAdaptive Risk Manager Webアプリケーション(ARM) 10gの各アプリケーションのディレクトリの場所を入力します。

- データベース・タイプ: ドロップダウン・リストからデータベース・タイプを選択します。

- 接続文字列: データベースが稼働しているサーバーの名前を入力します。Oracle Databaseについては、次のいずれかの形式を使用します。
//host:port/serviceまたはhost:port:sid

- スキーマ・ユーザー名: OAAMスキーマのユーザー名を入力します。

- スキーマ・パスワード: OAAMスキーマのパスワードを入力します。

7. 「次へ」をクリックします。
「WebLogic Serverの指定」画面が表示されます。

8. Oracle WebLogic Serverドメインについて次の情報を入力します。

- ホスト: WebLogic管理サーバーが稼動しているマシンのホスト名です。

- ポート: 管理サーバーのリスニング・ポートです。デフォルトの管理サーバー・ポートは7001です。

- ユーザー名: 管理サーバーへのログインに使用されるユーザー名。これは、ドメインの管理コンソールへのログインに使用するユーザー名と同じです。

- パスワード: 管理サーバーへのログインに使用される管理者アカウントのパスワード。これは、ドメインの管理コンソールへのログインに使用するパスワードと同じです。

- 「次へ」をクリックします。

「アップグレード・オプションの指定」画面が表示されます。

9. 「アップグレード完了後にアップグレード先コンポーネントを起動」を選択し、「次へ」を選択します。
「コンポーネントの調査」画面が表示されます。

注意:

「アップグレード完了後にアップグレード先コンポーネントを起動」を選択する前に、ノード・マネージャが稼動していることを確認します。

10. 「次へ」をクリックします。
「アップグレード・サマリー」画面が表示されます。

11. 「アップグレード」をクリックします。
「アップグレードの進行状況」画面が表示されます。この画面には次の情報が表示されます。

- アップグレードのステータス

- アップグレード中に発生したエラーまたは問題

12. 「次へ」をクリックします。
「アップグレード完了」画面が表示されます。この画面はアップグレードが完了していることを確認します。

13. 「閉じる」をクリックします。

3.14 OAAM管理対象サーバーの起動

OAAM中間層をアップグレードした後、次の順序でOAAM管理対象サーバーを起動する必要があります。

1. OAAM管理サーバー

2. OAAMオフライン・サーバーが構成されている場合、OAAMオフライン・サーバー

3. OAAMサーバー

管理対象サーバーの起動の詳細は、付録A「管理対象サーバーの起動」を参照してください。

注意:

OAAMサーバーを起動する前に、OAAM管理サーバーが起動していることを確認してください。

3.15 移行の確認

OAAM 10gの移行が成功したかどうかを確認するには、次の手順を実行します。

1. 管理サーバーのユーザー名とパスワードを使用してOracle Adaptive Access Manager 11.1.2.2.0の管理コンソールにログインし、OAAM 10gアーティファクトがOAAM 11gに移行されているかどうかを確認します。次のURLを使用して、OAAM管理サーバーにログインします。

http://host:port/oaam_admin

各項目は次のとおりです。

hostは、OAAM管理サーバーが稼動しているマシンです。

portは、OAAM管理サーバーのポート番号です。

2. ユーザーを作成し、Investigatorロールを割り当てます。このユーザーとしてOAAM管理サーバーにログインし、InvestigatorのUIが正しく表示されることを確認します。
OAAMユーザーの作成の詳細は、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドのOAAMユーザーの作成に関する項を参照してください。

4 Oracle Single Sign-On 10g環境の移行

この章では、既存のOracle Single Sign-On 10gをOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.2.0)に移行する方法について説明します。

この章には次の項が含まれます:

- 第4.1項「移行の概要」

- 第4.2項「移行のサマリー」

- 第4.3項「トポロジの比較」

- 第4.4項「移行シナリオ」

- 第4.5項「移行ロードマップ」

- 第4.6項「移行の前提条件」

- 第4.7項「Access Manager 11.1.2.2.0トポロジの理解」

- 第4.8項「オプション: Oracle Databaseのアップグレード」

- 第4.9項「リポジトリ作成ユーティリティを使用したスキーマの作成」

- 第4.10項「Access Manager 11.1.2.2.0中間層のインストールおよび構成」

- 第4.11項「アップグレード・アシスタントを使用したAccess Manager 11.1.2.2.0中間層のアップグレード」

- 第4.12項「移行後タスクの実行」

- 第4.13項「移行の確認」

4.1 移行の概要

Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行プロセスでは、Oracle Identity and Access Management 11.1.2.2.0をインストールしてOracle Access Management Access Manager 11.1.2.2.0を構成し、Access Manager中間層をアップグレードする必要があります。Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0に移行するには、次の3つのシナリオがあります。

- Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要

- Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要、ただしOracle Single Sign-On Adminは不要

- Oracle Single Sign-On 10gから11.1.2.2.0への移行後にOracle Delegated Administration Servicesは不要

選択するシナリオに応じて、「移行ロードマップ」に示されている対応タスクを実行する必要があります。

他の移行シナリオの詳細は、第1.2項「移行および共存のシナリオ」を参照してください。

4.2 移行のサマリー

Oracle Fusion Middlewareのアップグレード・アシスタントを使用して次のものを移行できます。

- Oracle Single Sign-On 10gの構成およびアーティファクト

- Oracle Single Sign-On 10g Serverによって格納されるパートナ・メタデータ

- Oracle Single Sign-On 10g Serverに登録されているパートナ

アップグレード・アシスタントを実行してOracle Single Sign-On 10gから移行する場合、次のコンポーネントはAccess Manager 11.1.2.2.0環境に移行されません。

- Windowネイティブ認証を統合したOracle Single Sign-On 10g。詳細は、『Oracle Fusion Middleware Oracle Access Manager統合ガイド』のWindowsネイティブ認証を使用するためのOracle Access Managerの構成に関する章を参照してください。

- ロギングの構成。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のコンポーネント・イベント・メッセージのロギングに関する項を参照してください。

- Oracle Identity Federationを統合したOracle Single Sign-On 10g。詳細は、Oracle Fusion Middleware Oracle Access Manager統合ガイドのOracle Identity Federationの統合に関する項を参照してください。

- カスタム認証。

- X509構成。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。

- 外部アプリケーション。

- ポリシー・ストア。

- マルチレルム構成。

4.3 トポロジの比較

図4-1は、Oracle Application Server 10gの一般的なOracle Single Sign-OnのトポロジとOracle Fusion Middleware 11gのAccess Manager 11.1.2.2.0のトポロジを比較したものです。

図4-1 Oracle Application Server 10gおよびOracle Fusion Middleware 11gの典型的なOracle Single Sign-Onのトポロジの比較

4.4 移行シナリオ

Oracle Single Sign-On 10gをAccess Manager 11.1.2.2.0に移行する前に、Oracle Single Sign-On 10gのインフラストラクチャ(図4-2)を検討し、保持することを選択した機能に応じて次のシナリオの1つを選択する必要があります。

- Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要

- Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要、ただしOracle Single Sign-On Adminは不要

- Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesは不要

移行前のOracle Single Sign-On 10gのインフラストラクチャ

図4-2に、Oracle Single Sign-On 10gのトポロジを示します。

図4-2 Oracle Single Sign-On 10gのインフラストラクチャ

「図4-2 Oracle Single Sign-On 10gのインフラストラクチャ」の説明

このトポロジは次のもので構成されています。

- Oracle Single Sign-Onのインフラストラクチャと通信するためのOracle HTTP Serverによってフロントエンド処理されるJava EEコンテナ内のパートナ・アプリケーション

- Oracle HTTP Server 10gによってフロントエンド処理されるOracle Delegated Administration ServicesアプリケーションおよびOracle Single Sign-On Serverを含むOracle Identity Managementのインフラストラクチャ

ホスト名とポート番号で構成されているOracle Single Sign-Onエンドポイントは、Oracle Single Sign-OnユーザーがOracle Single Sign-On ServerおよびOracle Delegated Administration Servicesアプリケーションへのアクセスに使用できるURLを表します。

Oracle Single Sign-Onエンドポイントの例は、host.domain.com:portです。

注意:

この例は、この項で様々な移行シナリオおよびそれらのOracle Single Sign-Onエンドポイントを表すために使用します。

4.4.1 Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要

Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後も、Oracle Delegated Administration Services (DAS)アプリケーションおよびOracle Single Sign-On Adminツールを引き続き使用する場合は、この移行シナリオを使用します。図4-3にこのシナリオを示します。

この移行シナリオを使用する場合は次の点に注意してください。

- Oracle Portalパートナ・アプリケーションを使用している場合は、Oracle Delegated Administration ServicesおよびOracle Single Sign-On Adminが必要であるため、このシナリオを使用します。すべてのパートナ・アプリケーションを一度に移行します。

- Oracle Single Sign-On 10gのフロントエンド処理を行っていたものと同じOracle HTTP Server 10gポートをOracle Access Manager 11.1.2.2.0の新しいポートとして使用しています。そのため、Oracle Single Sign-On 10gサーバーにアクセスすることはありません。かわりに、パートナ・アプリケーションではAccess Manager 11.1.2.2.0を使用します。

- Oracle Delegated Administration Services (DAS)アプリケーションは新しいポート上で実行されます。

- Oracle Portalなどのパートナ・アプリケーションからのOracle Delegated Administration Servicesのリクエストは、Oracle HTTP Server 11gに着信し、それからOracle HTTP Server 10gにリダイレクトされます。これがOracle Delegated Administration Services 10gアプリケーションのフロントエンド処理を行います。

注意:

Oracle Delegated Administration ServicesおよびOracle Single Sign-On AdminをOracle Access Manager 11.1.2.2.0に再登録する必要があります。これは、それらのポートが変更されているためです。

- Oracle Single Sign-On-Oracle Delegated Administration Servicesエンドポイント(same_host.domain.com:same_port)は、すべてのパートナ・アプリケーションに対して同じままです。

- 移行の実行後、Oracle Internet Directoryが自動的にユーザー・アイデンティティ・ストアとして選択されます。

図4-3 Oracle Single Sign-Onからの移行後にOracle Delegated Administration Servicesが必要

この移行シナリオを使用するには、表4-1に示す手順に従ってください。

4.4.2 Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要、ただしOracle Single Sign-On Adminは不要

Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後に、Oracle Single Sign-On Adminツール・アプリケーションは不要でOracle Delegated Administration Servicesアプリケーションが必要な場合は、この移行シナリオを使用します。図4-4にこのシナリオを示します。

この移行シナリオを使用する場合は次の点に注意してください。

- Oracle Delegated Administration Services用にOHS 10gポートを使用しています。そのため、Access Manager 11.1.2.2.0を別のマシンにインストールする必要があります。

- パートナ・アプリケーションは段階的に移行します。

- 移行後は、Oracle Single Sign-Onが機能しなくなります。ただし、Oracle Delegated Administration Servicesは引き続き機能します。

- 一連のパートナ・アプリケーションのフロント処理を行うOHSおよびmod_ossoごとに、移行中に生成されるosso.confファイルを手動でコピーする必要があります。この手順によって、これらのアプリケーションが新しいOracle Single Sign-OnプロバイダとしてAccess Manager 11.1.2.2.0と関連付けられます。この手順は、Oracle Delegated Administration Servicesに対しても必要です。

- Oracle Delegated Administration Servicesエンドポイント(same_host.domain.com:same_port)は、すべてのパートナ・アプリケーションに対して同じままです。

- Oracle Access Manager Oracle Single Sign-Onエンドポイントは、new_host.domain.com:new_portなどの新規です。

- 移行の実行後、Oracle Internet Directoryが自動的にユーザー・アイデンティティ・ストアとして選択されます。

図4-4 Oracle Single Sign-On管理サーバーが不要

この移行シナリオを使用するには、表4-1に示す手順に従ってください。

4.4.3 Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesは不要

Oracle Delegated Administration ServicesアプリケーションまたはOracle Single Sign-On Adminツールが不要な場合は、この移行シナリオを使用します。図4-5にこのシナリオを示します。

この移行シナリオを使用する場合は次の点に注意してください。

- 移行後は、Oracle Single Sign-OnおよびOracle Delegated Administration Servicesは機能しなくなります。

- すべてのパートナ・アプリケーションを一度に移行します。

- Oracle Single Sign-On 10gのフロントエンド処理を行っていたものと同じOHS 10gポートをAccess Manager 11.1.2.2.0の新しいポートとして使用します。そのため、Oracle Single Sign-On 10gサーバーおよびOracle Delegated Administration Servicesアプリケーションにはアクセスできません。

- Oracle Single Sign-Onエンドポイント(same_host.domain.com:same_port)は、すべてのパートナ・アプリケーションに対して同じままです。

- 移行の実行後、Oracle Internet Directoryが自動的にユーザー・アイデンティティ・ストアとして選択されます。

図4-5 Oracle Delegated Administration Servicesが不要

この移行シナリオを使用するには、表4-1に示す手順に従ってください。

4.5 移行ロードマップ

表4-1は、Oracle Single Sign-On 10gの各移行シナリオで実行する必要があるタスクを示しています。

表4-1 移行シナリオとタスク

シナリオ

完了するタスク

Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要

- 第4.6項「移行の前提条件」

- 第4.7項「Access Manager 11.1.2.2.0トポロジの理解」

- 第4.8項「オプション: Oracle Databaseのアップグレード」

- 第4.9項「リポジトリ作成ユーティリティを使用したスキーマの作成」

- 第4.10.1項「Oracle Single Sign-On 10gのホスト名とポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成」

- 第4.11項「アップグレード・アシスタントを使用したAccess Manager 11.1.2.2.0中間層のアップグレード」

- 第4.12項「移行後タスクの実行」

- 第4.13項「移行の確認」

Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesが必要、ただしOracle Single Sign-On Adminは不要

- 第4.6項「移行の前提条件」

- 第4.7項「Access Manager 11.1.2.2.0トポロジの理解」

- 第4.8項「オプション: Oracle Databaseのアップグレード」

- 第4.9項「リポジトリ作成ユーティリティを使用したスキーマの作成」

- 第4.10.2項「新しいホスト名またはポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成」

- 第4.11項「アップグレード・アシスタントを使用したAccess Manager 11.1.2.2.0中間層のアップグレード」

- 第4.12項「移行後タスクの実行」

- 第4.13項「移行の確認」

Oracle Single Sign-OnからAccess Manager 11.1.2.2.0への移行後にOracle Delegated Administration Servicesは不要

- 第4.6項「移行の前提条件」

- 第4.7項「Access Manager 11.1.2.2.0トポロジの理解」

- 第4.8項「オプション: Oracle Databaseのアップグレード」

- 第4.9項「リポジトリ作成ユーティリティを使用したスキーマの作成」

- 第4.10.1項「Oracle Single Sign-On 10gのホスト名とポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成」

- 第4.11項「アップグレード・アシスタントを使用したAccess Manager 11.1.2.2.0中間層のアップグレード」

- 第4.12項「移行後タスクの実行」

- 第4.13項「移行の確認」

4.6 移行の前提条件

Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0に移行するには、次の前提条件を満たす必要があります。

1. システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

2. 使用しているOracle Single Sign-On 10gのリリースが移行でサポートされていることを確認します。Oracle Single Sign-On 10gの移行がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。

4.7 Access Manager 11.1.2.2.0トポロジの理解

移行プロセスを開始する前に、Access Manager 11.1.2.2.0のトポロジに精通しておきます。

詳細は、第4.3項「トポロジの比較」を参照してください。

4.8 オプション: Oracle Databaseのアップグレード

Oracle Single Sign-On環境をAccess Manager 11.1.2.2.0に移行する場合は、Access ManagerとOracle Platform Security Services (OPSS)のスキーマをインストールする予定のデータベースのリリースがOracle Fusion Middleware 11gによってサポートされていることを確認する必要があります。

新しいデータベースをインストールするか、または既存のデータベースをサポートされているバージョンにアップグレードできます。

4.9 リポジトリ作成ユーティリティを使用したスキーマの作成

Access Manager 11.1.2.2.0を構成するには、必要なスキーマをデータベースに作成する必要があります。スキーマを作成するには、リポジトリ作成ユーティリティ(RCU)を実行する必要があります。ただし、指定したすべてのスキーマをRCUに作成する必要があるのは、Oracle Fusion Middlewareの完全な環境をインストールし、すべてのOracle Fusion Middlewareコンポーネント・スキーマに同じデータベースを使用する計画がある場合にかぎられます。

RCUを実行してAccess Manager 11.1.2.2.0に必要なスキーマを作成する場合の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Fusion Middlewareのリポジトリ作成ユーティリティ(RCU)を使用したデータベース・スキーマの作成に関する項を参照してください。

4.10 Access Manager 11.1.2.2.0中間層のインストールおよび構成

選択する移行シナリオに応じて、次のいずれかのタスクを完了する必要があります。

- Oracle Single Sign-On 10gのホスト名とポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成

- 新しいホスト名またはポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成

4.10.1 Oracle Single Sign-On 10gのホスト名とポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成

表4-2は、Oracle Single Sign-On 10gからOracle Access Manager 11.1.2.2.0への移行後に、Oracle Delegated Administration ServicesアプリケーションおよびOracle Single Sign-On Adminツールを使用するためのAccess Manager 11.1.2.2.0中間層のインストールおよび構成手順を示しています。

表4-2 Oracle Access Manager中間層のインストールおよび構成手順

No

タスク

参照先

1

Oracle WebLogic Server 10.3.6のインストールとOracleミドルウェア・ホームの作成

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のインストールの前提条件に関する項とグラフィカル・モードでのインストール・プログラムの実行に関する項を参照してください。

2

Oracle HTTP Server 10gの停止および構成

「Oracle HTTP Server 10gの再構成」を参照してください。

3

Oracle HTTP Server 11gのインストール

Oracle HTTP Server 11gをインストールし、Oracle HTTP Server 10gのポート番号を指定します。詳細は、『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』を参照してください。

4

Oracle Identity and Access Management 11.1.2.2.0のインストール

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management 11.1.2.2.0のインストールに関する項を参照してください。

5

Oracle Access Management Access Manager 11.1.2.2.0の構成

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Access Managementの構成に関する項を参照してください。

6

ノード・マネージャでの管理対象サーバーの起動の構成

Oracle Fusion Middleware管理者ガイドの管理対象サーバーを起動するためのノード・マネージャの構成に関する項を参照してください。

7

Oracle WebLogic Serverドメインの開始

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のスタックの起動に関する項を参照してください。

8

Oracle HTTP Server 11gによるAccess Manager 11.1.2.2.0管理対象サーバーのフロントエンド処理

「Oracle HTTP Server 11gによるAccess Manager 11.1.2.2.0管理対象サーバーのフロントエンド処理」を参照してください。

9

パートナ・アプリケーションとしてのOracle HTTP Server 10gの登録

「Oracle Access Manager 11gのパートナ・アプリケーションとしてのアプリケーションの登録」を参照してください。

10

Oracle HTTP Server 10gサーバーへのOIDDASリクエストのリダイレクト

「Oracle HTTP Server 10gサーバーへのパートナ・アプリケーション・リクエストのリダイレクト」を参照してください。

11

インストールの確認

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Access Managementのインストールの確認に関する項を参照してください。

Oracle HTTP Server 10gの再構成

次の手順を実行してください。

1. テキスト・エディタでhttpd.confファイルをディレクトリORACLE_HOME\Apache\Apache\conf (Windowsの場合)、またはORACLE_HOME/Apache/Apache/conf (UNIXの場合)から開き、既存のポート番号を変更し、新しいポート番号を変更します。

2. opmnctlコマンド行ツール(ORACLE_HOME\opmn\binにある)を次のように実行することで、Oracle HTTP Server 10gを停止します。

opmnctl stopproc ias-component=<name_of_the_OHS_instance>

3. 次のopmnctlコマンドを実行することでOracle HTTP Server 10gを再起動します。

OHS_INSTANCE_HOME/bin/opmnctl stopall
OHS_INSTANCE_HOME/bin/opmnctl startall

Oracle HTTP Server 11gによるAccess Manager 11.1.2.2.0管理対象サーバーのフロントエンド処理

mod_wl_ohsを使用して、Oracle HTTP Server 11gでAccess Manager 11.1.2.2.0管理対象サーバーのフロントエンド処理を行う必要があります。これを行うには、次の手順を完了します。

1. テキスト・エディタでディレクトリOHS_INSTANCE_HOME/config/OHS/ohs_instance_name(UNIXの場合)、またはOHS_INSTANCE_HOME\config\OHS\ohs_instance_name(Windowsの場合)からmod_wl_ohs.confファイルを開き、次のように編集します。

<IfModule weblogic_module>
WebLogicHost <OAM Managed Server Host>
WebLogicPort <OAM Managed Server Port>
Debug ON
WLLogFile /tmp/weblogic.log
MatchExpression *.jsp
</IfModule>
<Location />
SetHandler weblogic-handler
PathTrim /
ErrorPage  http://WEBLOGIC_HOST:WEBLOGIC_PORT/
</Location>

2. ORACLE_INSTANCE\binディレクトリ(Windowsの場合)、またはORACLE_INSTANCE/binディレクトリ(UNIXの場合)から次のopmnctlコマンドを実行することでOracle HTTP Server 11gを再起動します。

opmnctl stopall
opmnctl startall

3. テキスト・エディタで、Windowsの場合はMW_HOME\user_projects\domains\domain_name\config\fmwconfigディレクトリ、UNIXの場合はMW_HOME/user_projects/domains/domain_name/config/fmwconfigディレクトリからoam-config.xmlファイルを開き、次の例に示すように、serverhostエントリとserverportエントリを編集します。

<Setting Name="OAMSERVER" Type="htf:map">
<Setting Name="serverhost" Type="xsd:string"><OHS 11G HOST></Setting>
<Setting Name="serverprotocol" Type="xsd:string">http</Setting>
<Setting Name="serverport" Type="xsd:string"><OHS 11G PORT></Setting>
<Setting Name="MaxRetryLimit" Type="xsd:integer">5</Setting>
</Setting>

4. WebLogic管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーを再起動します。サーバーを再起動するには、それらを停止してから再起動する必要があります。
管理サーバーおよび管理対象サーバーの停止の詳細は、付録A「サーバーの停止」を参照してください。

管理サーバーおよび管理対象サーバーの起動の詳細は、付録A「サーバーの起動」を参照してください。

Oracle Access Manager 11gのパートナ・アプリケーションとしてのアプリケーションの登録

Oracle HTTP Server 10gパートナにデプロイ済のOracle Internet DirectoryおよびOracle Delegated Administration ServicesをAccess Manager 11.1.2.2.0に登録する必要があります。これを行うには、次の手順を完了します。

1. Oracle Access Management 11.1.2.2.0コンソールにログインします。

2. 「システム構成」タブをクリックします。

3. 「ようこそ」ページでOSSOエージェントの追加を選択します。

4. OSSOエージェントの作成ページで、次の詳細を入力します。

- エージェント名: mod_ossoエージェントの識別名。

- エージェントのベースURL: 必要なプロトコル、ホスト、およびエージェントのWebサーバーがインストールされるコンピュータのポート。たとえば、http://ohs_host:ohs_portです。

5. 「適用」をクリックします。
エージェントが作成され、osso.confファイルがDOMAIN_HOME/output/AGENT_NAME(UNIXの場合)とDOMAIN_HOME\output\AGENT_NAME(Windowsの場合)に作成されます。

6. 新しく生成されたエージェント・ファイルをOracle HTTP Server 10gのOHS_Config\ossoにコピーします。

7. 次のopmnctlコマンドを実行することでOracle HTTP Server 10gを再起動します。

OHS_INSTANCE_HOME/bin/opmnctl stopall
OHS_INSTANCE_HOME/bin/opmnctl startall

Oracle HTTP Server 10gサーバーへのパートナ・アプリケーション・リクエストのリダイレクト

mod_proxyを使用して、Oracle Internet DirectoryおよびOracle Delegated Administration ServicesリクエストをOracle HTTP Server 10gにリダイレクトする必要があります。

テキスト・エディタでOracle HTTP Server 11gのhttpd.confファイルを開き、Oracle Internet DirectoryおよびOracle Delegated Administration Servicesのフロントエンド処理を行うOHS 10gのホスト名とポート名のエントリを次の例に示すように追加します。

ProxyPass         /oiddas http://pdcasqa14-3.us.abc.com:8888/oiddas
ProxyPassReverse  /oiddas http://pdcasqa14-3.us.abc.com:8888/oiddas

注意:

前述の例では、OHS 10gポート番号を使用しています。

次のopmnctlコマンドを実行することでOracle HTTP Server 11gを再起動します。

ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME/opmn/bin/opmnctl startall

Oracle HTTP Server 10gでSSLが有効化されている場合、次の事項を完了します。

1. プロキシのウォレットを作成します。

2. Oracle HTTP Server 10gのルート証明書が既知でない場合、それを前述の作成済ウォレットに信頼できる証明書としてインポートする必要があります。

3. テキスト・エディタでOracle HTTP Server 11gのssl.confファイル(<ORACLE_INSTANCE>/config/OHS/<COMPONENT_NAME>/にある)を開き、次の行を<VirtualHost *:PORTNUMBER><IfModule ossl_module>の下に追加します。

SSLProxyEngine On
SSLProxyWallet <PATH of the wallet created above>

4. 次のopmnctlコマンドを実行することでOracle HTTP Server 11gを再起動します。

OHS_INSTANCE_HOME/bin/opmnctl stopall
OHS_INSTANCE_HOME/bin/opmnctl startall

4.10.2 新しいホスト名またはポート番号を使用したAccess Manager 11.1.2.2.0のインストールおよび構成

表4-3は、Oracle Access Managerの新しいホスト名またはポート番号を使用してAccess Manager 11.1.2.2.0中間層をインストールおよび構成するときに実行する必要がある手順を示しています。

表4-3 Oracle Access Manager中間層のインストールおよび構成手順

No

タスク

参照先

1

Oracle WebLogic Server 10.3.6のインストールとOracleミドルウェア・ホームの作成

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のインストールの前提条件に関する項とグラフィカル・モードでのインストール・プログラムの実行に関する項を参照してください。

2

Oracle Identity and Access Management 11gリリース2 (11.1.2.2.0)のインストール

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management 11.1.2.2.0のインストールに関する項を参照してください。

3

Oracle Access Management Access Manager 11.1.2.2.0の構成

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Access Managementの構成に関する項を参照してください。

4

ノード・マネージャでの管理対象サーバーの起動の構成

Oracle Fusion Middleware管理者ガイドの管理対象サーバーを起動するためのノード・マネージャの構成に関する項を参照してください。

5

Oracle WebLogic Serverドメインの開始

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のスタックの起動に関する項を参照してください。

6

インストールの確認

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Access Managementのインストールの確認に関する項を参照してください。

4.11 アップグレード・アシスタントを使用したAccess Manager 11.1.2.2.0中間層のアップグレード

Access Manager 11.1.2.2.0をインストールする場合、アップグレード・アシスタントがOracleホームのbinディレクトリに自動的にインストールされます。

アップグレード・アシスタントは、アップグレードするOracleホームごとに1回ずつ実行します。たとえば、同じ10gリリース2 (10.1.2)ファームの一部である、2つの異なる10gリリース2 (10.1.2) Oracleホームをアップグレードする場合、それぞれの10gリリース2 (10.1.2) Oracleホームに対して1回ずつ、つまり2回アップグレード・アシスタントを実行する必要があります。

中間層をアップグレードするには、次の手順を完了します。

1. 次の操作を実行してアップグレード・アシスタントを起動します。
UNIXの場合:

1. 次のコマンドを使用して、現在の作業ディレクトリからMW_HOME/IAM_HOME/binディレクトリに移動します。
cd MW_HOME/IAM_HOME/bin

2. 次のコマンドを実行します。
./ua

Windowsの場合:

1. コマンド行で次のコマンドを使用して、現在の作業ディレクトリからMW_HOME\IAM_HOME\binディレクトリに移動します。
cd MW_HOME/IAM_HOME/bin

2. 次のコマンドを実行します。
ua.bat

Oracle Fusion Middlewareのアップグレード・アシスタントの「ようこそ」画面が表示されます。

2. 「次へ」をクリックします。
「操作の指定」画面が表示されます。

3. Oracle Access Manager中間層のアップグレードを選択します。
アップグレード・アシスタントで使用可能なオプションは、アシスタントを起動したOracleホーム固有のものです。Oracle Application Server Identity ManagementのOracleホームからアップグレード・アシスタントを起動する場合、「操作の指定」画面に表示されるオプションが、Oracle Application Server Identity ManagementのOracleホームに対して有効なオプションです。

4. 「次へ」をクリックします。
「ソース詳細の指定」画面が表示されます。

5. 次の情報を入力します。

- プロパティ・ファイル: 「参照」をクリックし、Oracle Single Sign-On 10gのpolicy.propertiesファイルのパスを指定します。
Oracle Access Manager 11.1.2.2.0インストールが、Oracle Single Sign-On 10gインストールとは別のホスト上にある場合は、10gのpolicy.propertiesファイルをAccess Manager 11.1.2.2.0ホストの一時ディレクトリにコピーする必要があります。その後、一時フォルダ内にあるpolicy.propertiesファイルのパスを指定します。

- データベース・ホスト: Oracle Single Sign-Onスキーマを含むデータベース・ホスト名を入力します。

- データベース・ポート: データベース・ポート番号を入力します。

- データベース・サービス: データベース・サービス名を入力します。

- SYSパスワード: 「データベース」ドロップダウン・メニューから選択したデータベースのSYSデータベース・アカウントのパスワードを入力します。アップグレード・アシスタントでは、10gコンポーネント・スキーマをアップグレードする前にログイン資格証明が必要です。

注意:

Oracle Single Sign-On 10gのデータベース構成のデータベースの詳細を必ず入力します。

6. 「次へ」をクリックします。
「OIDの詳細の指定」画面が表示されます。

7. 次の情報を入力します。

- OIDホスト:: Oracle Internet Directoryサーバーのホスト名を入力します。

- OID SSLポート:: 使用するOracle Internet Directoryのポート番号を入力します。

- OIDパスワード: Oracle Internet Directoryの管理アカウント(cn=orcladmin)のパスワードを入力します。

8. 「次へ」をクリックします。
「WebLogic Serverの指定」画面が表示されます。

9. 次の情報を入力します。

- ホスト: Oracle WebLogic Serverドメインのホスト名を入力します。

- ポート: 管理サーバーのリスニング・ポートを入力します。デフォルト・サーバー・ポートは7001です。

- ユーザー名: 管理サーバーへのログインに使用されるユーザー名。これは、ドメインの管理コンソールへのログインに使用するものと同じユーザー名です。

- パスワード: 管理サーバーへのログインに使用される管理者アカウントのパスワード。これは、ドメインの管理コンソールへのログインに使用するパスワードと同じです。

10. 「次へ」をクリックします。
「アップグレード・オプションの指定」画面が表示されます。

11. 「アップグレード完了後にアップグレード先コンポーネントを起動」を選択し、「次へ」を選択します。

注意:

外部アプリケーションを使用している場合は、外部アプリケーションでもアップグレードを選択します。

「コンポーネントの調査」画面が表示されます。

12. 「次へ」をクリックします。
「アップグレード・サマリー」画面が表示されます。

13. 「アップグレード」をクリックします。
「アップグレードの進行状況」画面が表示されます。この画面には次の情報が表示されます。

- アップグレードのステータス

- アップグレード中に発生したエラーまたは問題

14. 「次へ」をクリックします。
「アップグレード完了」画面が表示されます。この画面はアップグレードが完了していることを確認します。

15. 「閉じる」をクリックします。

4.12 移行後タスクの実行

次の項では、Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後に手動で実行する必要がある手順について説明します。

- Oracle HTTP Serverポートが変更された場合のAccess Manager 11.1.2.2.0サーバーを使用したOracle Portal 10gの構成

- ロールを調整するためのOracle Access Management 11.1.2.2.0管理コンソールの構成

- osso.confファイルのコピー

- Access Manager 11.1.2.2.0でのOracle Business Intelligence Discoverer 11gの構成

- 保護されるDASリソースのヘッダーの認証ポリシーでの設定

- デフォルトの認証スキームの設定

- Access Manager 11.1.2.2.0のデフォルト・ストアおよびシステム・ストアとしての移行アイデンティティ・ストアの設定

- SSLサーバー認証モードで構成されたOracle Internet Directoryの追加手順

- 移行後の追加のAccess Managerタスク

- Oracle Single Sign-On 10gの停止

4.12.1 Oracle HTTP Serverポートが変更された場合のAccess Manager 11.1.2.2.0サーバーを使用したOracle Portal 10gの構成

Oracle PortalのOracle Single Sign-OnサーバーをAccess Manager 11.1.2.2.0サーバーに移行した後、Oracle PortalスキーマをAccess Manager 11.1.2.2.0サーバーに関する情報で更新する必要があります。そのためには、wwsec_enabler_config_info$表を次のように更新する必要があります。

1. Portalスキーマのパスワードを取得するには、次のコマンドを実行します。

ldapsearch -v -D "cn=orcladmin" -w "orcladminpassword" -h OIDHost -p OIDPort -s sub -b "cn=IAS  Infrastructure Databases, cn=IAS, cn=Products, cn=OracleContext" "orclresourcename=PORTAL"  orclpasswordattribute

2. Oracle Portalスキーマをホストしているデータベースに接続し、そのPortalスキーマのユーザー名とパスワードを使用してログインします。

3. portal_post_upgrade.sqlスクリプト(<ORACLE_HOME>\oam\server\upgrade\sqlにある)を実行します。

4. 入力を求められたら、ご使用のAccess Manager 11.1.2.2.0管理対象サーバーのホスト名およびポート番号を入力します。

4.12.2 ロールを調整するためのOracle Access Management 11.1.2.2.0管理コンソールの構成

移行後に、Oracle Access Management 11.1.2.2.0管理コンソールではランタイム認証および認可にシステム・アイデンティティ・ストアが使用されます。既存のロールを調整するには、次の手順を実行します。

1. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME/common/binディレクトリに移動します。
cd IAM_HOME/common/bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
./wlst.sh

Windowsの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME\common\binディレクトリに移動します。
cd IAM_HOME\common\bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
wlst.cmd

2. WLSTシェルで、次のコマンドを入力します。

editUserIdentityStore(name="UserIdentityStoreName",roleSecAdmin="SecurityAdminRoleName")

例:

(name="MigratedUserIdentityStore",roleSecAdmin="Administrators")

Oracle Access Management 11.1.2.2.0管理コンソールに対してAccess Manager 11.1.2.2.0管理者のグループを構成する場合は、次の手順を実行します。

1. Oracle Internet Directoryに例の管理者のグループを作成します。

2. Access Manager 11.1.2.2.0管理者権限の完全修飾ドメイン名を追加します。たとえば、グループの一意のメンバーとして次のものを入力します。

cn=orcladmin,cn=users,dc=us,dc=abc,dc=com

3. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME/common/binディレクトリに移動します。
cd IAM_HOME/common/bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
./wlst.sh

Windowsの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME\common\binディレクトリに移動します。
cd IAM_HOME\common\bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
wlst.cmd

4. WLSTシェルで、次のコマンドを入力します。

editUserIdentityStore(name="MigratedUserIdentityStore",roleSecAdmin="SecurityAdminRoleName")

例:

editUserIdentityStore(name="MigratedUserIdentityStore",roleSecAdmin="Administrators")

4.12.3 osso.confファイルのコピー

選択したアップグレード・シナリオに応じて、Oracle Upgrade Assistantでは、パートナ・アプリケーションごとにosso.confという名前の新しいファイルがOracle_Home/upgrade/tempディレクトリに生成されることがあります。このosso.confファイルを、Oracle Access Manager 11.1.2.2.0に登録されているパートナ・アプリケーションの場所にコピーする必要があります。

パートナ・アプリケーションと関連付けられている正しいosso.confファイルを識別する必要があります。

例:

F78CFE57-dadvmb0097.us.abc.com_22776_769_osso.conf

正しいosso.confファイルを識別するには、oam-config.xmlファイル(IDM_HOME/oam/server/configにある)を調べます。oam-config.xmlファイルには、パートナ・アプリケーションの詳細とOracle HTTP Serverのホスト・アドレスおよびポート番号が指定されています。

4.12.4 Access Manager 11.1.2.2.0でのOracle Business Intelligence Discoverer 11gの構成

Oracle Business Intelligence DiscovererのOracle Single Sign-OnサーバーをAccess Manager 11.1.2.2.0サーバーに移行した後、Oracle Business Intelligence Discovererのシングル・サインオン構成を次のように更新する必要があります。

1. テキスト・エディタでmod_osso.confファイル(Oracle Business Intelligence DiscovererインスタンスのORACLE_INSTANCE/config/OHS/<COMPONENT_NAME>/moduleconfにある)を開きます。

2. <IfModule mod_osso.c>に次の行を追加します。

OssoHTTPOnly Off

3. 次のopmnctlコマンドを実行することでOracle HTTP Serverを再起動します。

OHS_INSTANCE_HOME/bin/opmnctl stopall
OHS_INSTANCE_HOME/bin/opmnctl startall

4.12.5 保護されるDASリソースの認証ポリシーでのヘッダーの設定

移行後、Oracle Access Management 11.1.2.2.0コンソールを使用して、保護されるOracle Delegated Administration Servicesのヘッダーを認証ポリシーで設定する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Management 11.1.2.2.0コンソールをホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「ポリシー構成」タブに移動します。

3. 「アプリケーション・ドメイン」を開きます。

4. 「Oracle Access Manager 11gのパートナ・アプリケーションとしてのアプリケーションの登録」手順の実行中に作成したagentを開きます。

5. 「認証ポリシー」を開きます。

6. 保護されるリソースのポリシーをダブルクリックします。

7. 保護されるリソースのポリシー・ページの「レスポンス」タブに移動します。

8. +記号をクリックしてレスポンスを追加します。

9. 表4-4に記載されている3つのヘッダーを、表で指定されている名前、タイプおよび値の各フィールドの正しい値で追加します。各ヘッダーの追加後、「追加」をクリックします。

表4-4 追加するヘッダー

ヘッダー名

タイプ

値

osso-subscriber

Header

DEFAULT COMPANY

osso-subscriber-dn

Header

サブツリーのDN
例:

dc=us,dc=oracle,dc=com

osso-subscriber-guid

Header

DNのGUID

10. 次の手順を実行して、WebLogic管理サーバーおよびAccess Manager管理対象サーバーを再起動します。サーバーを再起動するには、それらを停止してから再起動する必要があります。
管理サーバーおよび管理対象サーバーの停止の詳細は、付録A「サーバーの停止」を参照してください。

管理サーバーおよび管理対象サーバーの起動の詳細は、付録A「サーバーの起動」を参照してください。

4.12.6 デフォルトの認証スキームの設定

移行後、デフォルトの認証スキームはLDAPSchemeのまま変わりません。これをSSOCoexistMigrateSchemeに変更する必要があります。そのため、移行後にOracle Access Management 11.1.2.2.0コンソールを使用して、SSOCoexistMigrateSchemeをデフォルトの認証スキームとして設定する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Management 11.1.2.2.0管理コンソールをホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「ポリシー構成」タブに移動します。

3. 左のナビゲーション・ペインで「共有コンポーネント」を開きます。

4. 「認証スキーム」を開きます。

5. SSOCoexistMigrateSchemeをダブルクリックします。

6. 「デフォルトとして設定」をクリックして、「適用」をクリックします。

4.12.7 Access Manager 11.1.2.2.0のデフォルト・ストアおよびシステム・ストアとしての移行アイデンティティ・ストアの設定

Oracle Single Sign-On 10gからAccess Manager 11.1.2.2.0への移行後、migratedUserIdentityStoreをAccess Manager 11.1.2.2.0のデフォルト・ストアおよびシステム・ストアとして明示的に設定する必要があります。これを設定するには、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のデフォルト・ストアとシステム・ストアの設定に関する項を参照してください。

4.12.8 SSLサーバー認証モードで構成されたOracle Internet Directoryの追加手順

Oracle Single Sign-On 10gで使用されているOracle Internet Directory (OID)がSSLサーバー認証モードで構成されている場合、次の手順を実行する必要があります。

1. 次のコマンドを実行して、Access Manager 11.1.2.2.0サーバーを実行しているJVMのcacertsファイルにOracle Internet Directory自己署名証明書を追加します。
<JRE_HOME>/lib/security > ../../../bin/keytool -import -trustcacerts -keystore <location of cacerts in jvm> -storepass changeit -noprompt -alias <cert-name> -file <cert-file-path>

2. WebLogic管理サーバーおよびAccess Manager 11.1.2.2.0管理対象サーバーを再起動します。サーバーを再起動するには、それらを停止してから再起動する必要があります。
管理サーバーおよび管理対象サーバーの停止の詳細は、付録A「サーバーの停止」を参照してください。

管理サーバーおよび管理対象サーバーの起動の詳細は、付録A「サーバーの起動」を参照してください。

3. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。
http://host:port/oamconsole

4. 「システム構成」タブに移動します。

5. 左のナビゲーション・ペインで「共通構成」の「データソース」を開きます。

6. 「ユーザー・アイデンティティ・ストア」をクリックし、「作成」をクリックします。

7. 必要な詳細を指定し、「SSLの有効化」を選択していることを確認します。

8. 「ロケーション」フィールドで適切なSSLポートを指定していることを確認します。

9. 「適用」をクリックします。

図4-6は、新しいユーザー・アイデンティティ・ストアを作成するAccess Managerコンソールを示しています。

図4-6 新しいユーザー・アイデンティティ・ストアの作成

4.12.9 移行後の追加のAccess Managerタスク

Access Manager 11.1.2.2.0への移行後に、次の移行後のタスクを追加で実行する必要があります。

- 宛先トポロジが、ソースと同じマシン上のOracle HTTP Server 11g (11gコンパニオンCDによってインストール済)によってフロントエンド処理されている場合、そのOracle HTTP Server 11gのインストール・ディレクトリからアップグレード・アシスタントを実行し、Oracle Single Sign-Onのフロントエンド処理を行うOracle HTTP Serverを移行できます。そのような場合、アップグレード・アシスタントのポート保持オプションを使用すると、mod_ossoパートナとOracle Access Managerの再関連付けは不要になります。

- Oracle Portal 10gから移行したOracle Portal 11gを使用している場合、portal_post_upgrade.sqlスクリプト(Oracle_IDM1/oam/server/upgrade/sqlにある)を実行してOracle Single Sign-On構成を更新することと、シングル・サインオン認証にAccess Manager 11.1.2.2.0を使用するようにすることが必要です。

- その他の場合は、移行後にmod_ossoパートナと新しく移行されたOracle Access Manager 11.1.2.2.0の再関連付けを実行する必要があります。移行の一部として生成されたmod_osso構成は、このために使用できます。

- Oracle Portalにログインする前に、次のopmnctlコマンド(Windowsでは<ORACLE_INSTANCE>\binディレクトリに、UNIXでは<ORACLE_INSTANCE>/binディレクトリにある)を実行することでOracle Web Cacheを再起動する必要があります。

opmnctl stopall
opmnctl startall

4.12.10 Oracle Single Sign-On 10gの停止

Access Manager 11.1.2.2.0に移行した後、Oracle Internet Directory 10gまたはOracle Delegated Administration Services 10gでOracle Single Sign-On 10gを使用していない場合は、Oracle Single Sign-On 10gを削除できます。それを行うには、コマンド行で次のコマンドを実行することで、Oracle Single Sign-On 10gサーバーをOracle Identity Management 10gサーバー(OC4J_SECURITY)からアンデプロイします。

java -jar admin_client.jar <uri> <adminId> <adminPassword> -undeploy sso

4.13 移行の確認

移行の完了後、Access Managerはデフォルトで共存モードになります。Oracle Access Managerの移行が正常に実行されたことを確認する手順は次のとおりです。

1. アップグレード・アシスタントを再度実行し、「操作の指定」画面で「インスタンスの検証」を選択します。
特定のOracle Fusion Middlewareコンポーネントが稼働していることを確認するには、画面の手順に従ってください。

2. Access Manager 11.1.2.2.0管理サーバーが起動され実行中であることを確認するには、次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Management 11.1.2.2.0管理コンソールをホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

3. Access Manager 11.1.2.2.0管理対象サーバーが起動され実行していることを確認するには、次のようにします。

1. 必要な管理者資格証明を使用してOracle WebLogic Server管理コンソールにログインします。

2. 左側のペインでドメイン構造を開き、「デプロイメント」を選択します。

3. ご使用の管理対象サーバーが「デプロイメントのサマリー」ページにリストされていることを確認します。

かわりに、エラー・メッセージがないか移行ログ・ファイルをチェックするか、Fusion Middleware Controlを使用してAccess Manager 11.1.2.2.0および他のOracle Identity ManagementコンポーネントがそのOracle Fusion Middleware環境で稼働していることを確認できます。

詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイドを参照してください。

5 Sun OpenSSO Enterprise 8.0環境の移行

この章では、Sun OpenSSO Enterprise (OpenSSO Enterprise) 8.0をOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.2.0)に移行する方法について説明します。

この章は次の項で構成されています。

- 第5.1項「移行の概要」

- 第5.2項「移行のモード」

- 第5.3項「移行のサマリー」

- 第5.4項「トポロジの比較」

- 第5.5項「移行ロードマップ」

- 第5.6項「移行の前提条件」

- 第5.7項「Oracle Identity and Access Management11.1.2.2.0のインストール」

- 第5.8項「Oracle Access Management Access Manager 11.1.2.2.0の構成」

- 第5.9項「評価レポートの生成」

- 第5.10項「WebLogic管理サーバーの起動」

- 第5.11項「増分移行のための追加手順」

- 第5.12項「プロパティ・ファイルの作成」

- 第5.13項「OpenSSO Enterprise 8.0のアーティファクトのAccess Manager 11.1.2.2.0への移行」

- 第5.14項「移行後タスクの実行」

- 第5.15項「移行の確認」

5.1 移行の概要

この項では、Sun OpenSSO Enterprise 8.0からOracle Access Manager 11.1.2.2.0への移行プロセスで使用される2つのツールを紹介します。

OpenSSOエージェント評価ツール

OpenSSOエージェント評価ツールは、OpenSSO Enterprise 8.0サーバーからエージェントとポリシーを読み取り、Access Manager 11.1.2.2.0に移行可能なエージェントとポリシー要素を分析して、評価レポートを生成します。生成されたレポートでは、エージェントを移行できるかどうかと、Access Manager 11.1.2.2.0ポリシー・モデルに基づいて、ポリシーの手動移行、自動移行または準移行のいずれが可能かについての情報が提供されます。

評価ツールは、OpenSSO Enterpriseのエージェント、プロファイル、ポリシー、ユーザー・ストアおよび認証ストアに関する情報を読み取り、表示します。このツールは、Access Manager 11.1.2.2.0でサポートされるアーティファクトに関する情報に基づいて、Access Manager 11.1.2.2.0に移行できるデータと移行できないデータを評価します。

OpenSSO Enterprise 8.0をAccess Manager 11.1.2.2.0に移行する前に、評価レポートを複数回生成できます。

移行ツール

移行ツールは、OpenSSO Enterprise 8.0の次のアーティファクトをAccess Manager 11.1.2.2.0に移行します。

- エージェントの構成

- ポリシー

- ユーザー・ストアの構成

- 認証ストアの構成

注意:

移行ツールと評価ツールでは、SSLポートを介した構成ストアへの接続はサポートされません。

他の移行シナリオの詳細は、第1.2項「移行および共存のシナリオ」を参照してください。

5.2 移行のモード

この項では、この章で説明する手順を使用して実行可能な移行の3つのモードについて説明します。移行のモードは次の2つになります。

- 完全移行

- 増分移行

- デルタ移行

5.2.1 完全移行

完全移行は、OpenSSO Enterprise 8.0の互換性のあるエージェント、ポリシー、ユーザー・ストアおよび認証ストアをすべてAccess Manager 11.1.2.2.0に移行します。初めて行う移行は完全移行になります。最初の移行後、次に行われるそれぞれの移行はデルタ移行になります。完全移行を実行できるのは最初の1回のみです。

新規移行では、Access Manager 11.1.2.2.0構成ストアで移行バージョンを設定します。

完全移行を実行するには、「移行ロードマップ」で説明する手順に従います。

注意:

完全移行が失敗した場合、完全移行の再実行を開始する前に、部分的に移行されたデータを手動で削除する必要があります。

5.2.2 増分移行

増分移行は、選択移行とも呼ばれます。Access Manager 11.1.2.2.0に移行するOpenSSO Enterprise 8.0のエージェントおよびポリシーを選択できるためです。この移行は、様々なエージェントおよびポリシーのセットを使用して複数回実行できるため、増分移行と呼ばれます。増分移行の対象としてユーザー・ストアおよび認証ストアのみを選択することはできません。増分移行の対象としてエージェントおよびポリシーを選択する際に、ユーザー・ストアおよび認証ストアは自動的に移行されます。

注意:

完全移行を実行した後、増分移行を実行できます。これは、増分デルタと呼ばれます。

複数の増分移行の後、完全移行を実行できます。この場合、完全移行では、以前の増分移行の一環としてすでに移行されているエージェントとポリシーは無視されます。

すでに移行されているアーティファクト(エージェントおよびポリシー)を選択して複数の増分移行を実行した場合、それらのアーティファクトは無視され、増分移行では、移行されていないアーティファクトのみが移行されます。

5.2.3 デルタ移行

デルタ移行は、OpenSSO Enterprise 8.0の新しく追加されたアーティファクト(エージェント、ポリシー、ユーザー・ストアおよび認証ストア)をAccess Manager 11.1.2.2.0に移行できる移行モードです。デルタ移行は、作成操作の場合のみサポートされます。

1回目の移行(完全移行)後、実行する移行はすべてデルタ移行になります。

デルタ移行を実行するたびに、完全移行によってAccess Manager 11.1.2.2.0構成ストアで設定される移行バージョンに関する情報が取得され、1ずつ増えて、Access Manager 11.1.2.2.0構成ストアに保存されます。

データ移行を実行する手順は、完全移行の手順と同じで「移行ロードマップ」で説明します。

5.3 移行のサマリー

この項では、Access Manager 11.1.2.2.0と互換性のあるOpenSSO Enterprise 8.0のアーティファクトについてまとめています。この項には次のトピックが含まれます:

- エージェントの移行のサマリー

- ポリシーの移行のサマリー

- ユーザー・ストアの移行のサマリー

- 認証ストアの移行のサマリー

5.3.1 エージェントの移行のサマリー

この項では、OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0へのエージェントの移行についてまとめています。

- この移行ツールは、エージェント自体ではなくエージェント構成を移行します。移行では次のエージェントがサポートされます。
Java EEエージェント3.0: WebLogic 10.3

Webエージェント3.0: Internet Information Services (IIS) 7.5

- 中央管理エージェントはAccess Manager 11.1.2.2.0に移行されます。これらは中央管理構成モードで機能するエージェントです。それらはOpenSSO Enterprise 8.0サーバーにその構成の詳細をすべて保存し、エージェントのブートストラップ時にRESTコールによってOpenSSO Enterpriseサーバーから構成を読み取ります。これらのエージェントはローカルの構成ファイルを受け入れません。移行後、これらのエージェントの構成の詳細はAccess Manager 11.1.2.2.0に保存されます。

- ローカル・エージェントは、最小限の構成で移行されます。ローカル・エージェントはローカル構成モードで機能するエージェントです。これらのエージェントは、各自の構成のローカル構成ファイルのみを受け入れます。ローカル・エージェントのエージェントID、エージェント・パスワード、エージェント・ベースURLなどの基本構成プロパティのみがOpenSSO Enterprise 8.0サーバーに保存されます。移行後、このような構成の詳細はAccess Manager 11.1.2.2.0サーバーに保存されます。

- エージェントの移行には下位互換性があります。

- 異なるレルムに名前が同じエージェントが2つ以上存在する場合、エージェントは先頭にレルム名が付いた名前で移行されます。
例: j2eeAgentという名前のエージェントがTopRealm(/)とSubRealm(/>SubRealm)の両方に存在する場合、これらのエージェントは、TopRealm_j2eeAgentおよびSubRealm_j2eeAgentという名前で移行されます。

5.3.2 ポリシーの移行のサマリー

この項では、OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0へのポリシーの移行についてまとめています。

OpenSSO Enterprise 8.0ポリシーは、次の4つのアーティファクトで構成されます。

- ルール(リソース + アクション)

- サブジェクト

- 条件

- レスポンス・プロバイダ

OpenSSOエージェント評価ツールの実行時に生成される評価レポート(PolicyInfo.txt)のポリシーは、Access Manager 11.1.2.2.0のアーティファクトの互換性に基づき、自動ポリシー、準ポリシーおよび手動ポリシーに分類されます。

- 自動ポリシー: 該当ポリシーのすべてのアーティファクトをAccess Manager 11.1.2.2.0のポリシーのアーティファクトにマップできる場合は、自動ポリシーとみなされます。自動ポリシーはすべてAccess Manager 11.1.2.2.0に移行できます。

- 準ポリシー: 該当ポリシーの一部のアーティファクトをAccess Manager 11.1.2.2.0のポリシーのアーティファクトにマップできる場合は、準ポリシーとみなされます。準ポリシーはAccess Manager 11.1.2.2.0に移行されません。

- 手動ポリシー: 該当ポリシーのどのアーティファクトもAccess Manager 11.1.2.2.0のポリシーのアーティファクトにマップできない場合は、手動ポリシーとみなされます。手動ポリシーはAccess Manager 11.1.2.2.0に移行されません。

OpenSSO Enterprise 8.0には次の2種類のポリシーがあります。

- 参照ポリシー: これらのポリシーは移行に適用されません。

- 非参照ポリシー: これらのポリシーは移行されます。

ルール

- ルールを使用しないOpenSSO Enterpriseポリシーは移行でサポートされません。このようなポリシーは無効とみなされます。

- 移行に適用できるのは、アクションGETおよびPOSTが含まれるルールのみです。これらのルールには、サービス・タイプURL Policy Agentがあります。

- その他のサービス・タイプ(LOOKUPおよびUPDATEアクションが含まれるDiscovery Serviceや、QUERYおよびMODIFYアクションが含まれるLiberty Personal Profile Serviceなど)は、移行に適用されません。これらのアクション(Access Manager 11.1.2.2.0でリソース操作と呼ばれる)はAccess Manager 11.1.2.2.0でサポートされていないためです。

サブジェクト

サブジェクト・タイプOpenSSO Identity Subject(ユーザーおよびグループ)とAuthenticated Usersのみが移行でサポートされます。これらのサブジェクトは、Access Manager 11.1.2.2.0でIdentity Conditionの一部として移行されます。

条件

- アクティブ・セッション時間

- OpenSSO Enterpriseポリシーのこの条件は、Access Manager 11.1.2.2.0のAttributeConditionのSession Expiry Time属性にマップされます。

- この条件の属性Terminate sessionは、この属性の適切なマッピングがAccess Manager 11.1.2.2.0に存在しないため、移行時に無視されます。

- モジュール・インスタンスごとの認証

- OpenSSO Enterpriseポリシーのこの条件は、Access Manager 11.1.2.2.0に条件ではなくAuthNスキームとして移行されます。

- 表5-1は、Access Manager 11.1.2.2.0に移行されてAuthNスキームでマップされるOpenSSO Enterprise 8.0の認証モジュールを示しています。

表5-1 認証モジュールのマッピング

OpenSSO Enterprise 8.0の認証モジュール

Access Manager 11.1.2.2.0の認証プラグイン

証明書認証モジュール

X509認証プラグイン

WindowsDesktopSSO認証モジュール

Kerberos認証プラグイン

LDAP認証モジュール

LDAP認証プラグイン

- 認証レベル(less than or equal to)および認証レベル(greater than or equal to)

- OpenSSO Enterpriseポリシーのどちらの条件も、ネームスペースがSESSIONで属性名がAuthentication LevelのAttributeConditionのセッション属性にマップされます。

- Access Manager 11.1.2.2.0にはgreater than or equal toおよびless than or equal toに対応するマッピングがないため、どちらの条件もAttributeOperatorのEQUALSにマップされます。このマッピングは、OpenSSO Enterprise 8.0のポリシー条件のequalsファクタが原因で行われます。そのため、greater than or equal toとless than or equal toのどちらの条件もAccess Manager 11.1.2.2.0では同様になります。
たとえば、認証レベルの条件がless than or equal to 5のOpenSSO Enterprise 8.0ポリシーを移行する場合、Access Manager 11.1.2.2.0に移行後のポリシーの認証レベルはequal to 5になります。

- 現在のセッション・プロパティ

- この条件は、ネームスペースがSESSIONで属性名がOtherのAttributeConditionのセッション属性にマップされ、キーと値がこの条件の属性として追加されます。OpenSSO Enterprise 8.0のこの条件の値は複数になります。そのため、Access Manager 11.1.2.2.0のこの条件には、名前は同じでも値が異なる複数の属性があります。

- アイデンティティ・メンバーシップ

- OpenSSO Enterpriseポリシーのこの条件は、Access Manager 11.1.2.2.0のIdentity conditionにマップされます。

- すべてのサブジェクトの一意のユーザーまたはグループ、およびOpenSSO Enterprise 8.0のすべてのアイデンティティ・メンバーシップ条件の一意のユーザーまたはグループは、Access Manager 11.1.2.2.0の1つのアイデンティティ条件にユーザーまたはグループのセットとして作成されます。

- 実行時の検証では、ユーザーまたはグループのこのセット間でORが実行されます。

- IPアドレスおよびDNS名

- OpenSSO Enterprise 8.0ポリシーのIP Address条件は、Access Manager 11.1.2.2.0のIP conditionにマップされます。

- 条件DNS nameはAccess Manager 11.1.2.2.0ではサポートされません。

- LDAPフィルタ条件

- OpenSSO Enterpriseポリシーのこの条件は、Access Manager 11.1.2.2.0のIdentity conditionにマップされます。

- OpenSSO Enterprise 8.0のすべてのLDAPフィルタ条件の一意のLDAPフィルタはすべて、Access Manager 11.1.2.2.0の1つのアイデンティティ条件にLDAPフィルタのセットとして作成されます。

- 時間(曜日、日付、時刻およびタイムゾーン)

- OpenSSO Enterprise 8.0ポリシーのこの条件は、Access Manager 11.1.2.2.0のTime conditionにマップされます。

- OpenSSO Enterprise 8.0のTime条件には、日付、時刻、曜日またはタイムゾーンのいずれかの値が含まれます。Access Manager 11.1.2.2.0のTime条件には、時刻または曜日が含まれます。そのため、時刻(開始および終了時刻)と曜日のみを含むOpenSSO Enterprise 8.0のTime条件をAccess Manager 11.1.2.2.0のTime条件にマップできます。それ以外の場合はすべて無視されます。

レスポンス・プロバイダ

- OpenSSO Enterpriseサーバーまたはポリシー・サーバーは、アイデンティティまたはユーザー・リポジトリ属性(ユーザー・ストアのユーザー属性)をレスポンス・プロバイダとしてエージェントに送信します。OpenSSOエージェントは、これらの属性を、エージェントの構成に従ってHttpヘッダー、リクエスト属性またはHttp Cookieを介してリソースまたはアプリケーションに戻します。
レスポンス・プロバイダ(静的および動的)はすべて、Httpヘッダー・タイプでOpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0に移行されます。

5.3.3 ユーザー・ストアの移行のサマリー

この項では、OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0へのユーザー・ストアの移行についてまとめています。

OpenSSO Enterprise 8.0には次の3種類のユーザー・ストアがあります。

- アクティブ・ディレクトリ: このユーザー・ストアはAccess Manager 11.1.2.2.0に移行できます。

- 汎用LDAPv3: このユーザー・ストアはAccess Manager 11.1.2.2.0に移行できます。

- OpenSSOスキーマのSun DS: 11.1.2.2.0ではサポートされるデータ・ストアのタイプがないため、このユーザー・ストアは、Access Manager 11.1.2.2.0に移行できません。

5.3.4 認証ストアの移行のサマリー

この項では、OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0への認証ストアの移行についてまとめています。

Access Manager 11.1.2.2.0の対応する認証モジュールに移行およびマップ可能なOpenSSO Enterprise 8.0の認証ストアは、次のとおりです。

- OpenSSO Enterprise 8.0のLDAPは、Access Manager 11.1.2.2.0のOAM LDAPにマップされます。

- OpenSSO Enterprise 8.0の証明書は、Access Manager 11.1.2.2.0のX509にマップされます。

- OpenSSO Enterprise 8.0のWindows Desktop SSOは、Kerberos Access Manager 11.1.2.2.0にマップされます。

LDAPタイプの認証ストアはすべて、名前AS_レルム名_モジュール名でAccess Manager 11.1.2.2.0に移行されます。LDAP以外のタイプの認証ストアは移行されません。

5.4 トポロジの比較

図5-1は、Sun OpenSSO Enterprise 8.0とAccess Manager 11.1.2.2.0のトポロジを比較したものです。

図5-1 OpenSSO Enterprise 8.0とAccess Manager 11.1.2.2.0のトポロジ

5.5 移行ロードマップ

表5-2に、Sun OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0への移行手順を示します。

表5-2 タスク・ロードマップ

タスク番号

タスク

参照先

1

前提条件を満たします。

「移行の前提条件」を参照してください。

2

Oracle Identity and Access Management 11.1.2.2.0をインストールします。

「Oracle Identity and Access Management 11.1.2.2.0のインストール」を参照してください。

3

Oracle Access Management Access Manager 11.1.2.2.0を構成します。

「Oracle Access Management Access Manager 11.1.2.2.0の構成」を参照してください。

4

評価レポートを生成し、Access Manager 11.1.2.2.0にどのアーティファクトを移行できるかを分析します。

このタスクは複数回実行できます。

「評価レポートの生成」を参照してください。

5

WebLogic管理サーバーを起動します。

「WebLogic管理サーバーの起動」を参照してください。

6

増分移行を実行する場合は、追加手順を実行します。

「増分移行のための追加手順」を参照してください。

7

プロパティ・ファイルを作成します。

「プロパティ・ファイルの作成」を参照してください。

8

移行ツールを実行して、OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0に移行します。

「OpenSSO Enterprise 8.0のアーティファクトのAccess Manager 11.1.2.2.0への移行」を参照してください。

9

移行後の手順を完了します。

「移行後タスクの実行」を参照してください。

10

移行を確認します。

「移行の確認」を参照してください。

5.6 移行の前提条件

OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0に移行するには、次の前提条件を満たす必要があります。

1. システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

2. 使用しているOpenSSO Enterpriseのリリースが移行でサポートされていることを確認します。OpenSSO Enterprise 8.0の移行がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。

5.7 Oracle Identity and Access Management 11.1.2.2.0のインストール

移行プロセスの一環として、Oracle Identity and Access Management 11.1.2.2.0を新規でインストールしておく必要があります。この11.1.2.2.0のインストールは、Sun OpenSSO Enterprise 8.0をインストールする同じマシンか、別のマシンで行うことができます。

Oracle Identity and Access Management 11.1.2.2.0のインストールの詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドのOracle Identity and Access Management (11.1.2.2.0)のインストールに関する説明を参照してください。

5.8 Oracle Access Management Access Manager 11.1.2.2.0の構成

Access Manager 11.1.2.2.0を構成してドメインを作成します。

Access Manager 11.1.2.2.0の構成については、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドのOracle Access Managementの構成に関する項を参照してください。

5.9 評価レポートの生成

この項では、OpenSSOエージェント評価ツールを使用して評価レポートを生成する方法について説明します。評価レポートには、OpenSSO Enterprise 8.0サーバーで利用可能なエージェント、ポリシー、ユーザー・ストアおよび認証ストアのプレビューが表示され、Access Manager 11.1.2.2.0に移行可能なアーティファクトが示されます。

移行プロセスを開始する前に、評価レポートを複数回生成できます。

この項には次のトピックが含まれます:

- 評価ツールの入手

- LDAP接続の詳細の指定

- OpenSSOエージェント評価ツールの実行

- 評価レポートの分析

注意:

OpenSSOエージェント評価ツールを実行する前に、次の前提条件を満たす必要があります。

- OpenSSO Enterprise 8.0をデプロイするコンテナを起動します。

- JDKは必ず1.6以上のバージョンを使用してください。

- JDK 1.6をインストールする適切な場所に、変数JAVA_HOMEを設定します。

5.9.1 評価ツールの入手

次のコマンドを使用して、現在の作業ディレクトリからIAM_HOME/oam/server/tools/opensso_assessmentディレクトリに移動します。

UNIXの場合:

cd IAM_HOME/oam/server/tools/opensso_assessment/

Windowsの場合:

cd IAM_HOME\oam\server\tools\opensso_assessment\

OpenssoAgentdiscTool.zipフォルダの内容を、選択したディレクトリに抽出します。解凍したフォルダには名前OpenssoAgentdiscToolを使用することをお薦めします。

5.9.2 LDAP接続の詳細の指定

OpenSSOエージェント評価ツールを実行する前に、LDAP接続の詳細をプロパティ・ファイルで指定する必要があります。手順は次のとおりです。

1. 次の場所にあるOpenSSOAgentDiscTool.propertiesファイルを開きます。
UNIXの場合: unzipped_folder/resources/

Windowsの場合: unzipped_folder\resources\

2. 次のプロパティについて適切な値を設定します。

- openSSOLDAPServerURL=host:port
このプロパティでは、hostおよびportは、OpenSSO Enterprise 8.0で使用される構成ストアのLDAPホストとポートを表します。

- openSSOLDAPBindDN=login_id
ここで、login_idは、LDAPサーバーのバインドDNになります。OpenSSO Enterprise 8.0の構成ディレクトリ・サーバーの管理権限またはルート権限が必要です。

- openSSOLDAPSearchBase=LDAP_search_base
ここで、LDAP_search_baseは、構成ストアのLDAP検索ベースになります。

3. ファイルを保存して閉じます。

注意:

LDAP接続の詳細を指定しない場合、メッセージがUserStoresInfo.txtファイルとAuthnStoreInfo.txtファイルに表示されます。このメッセージは、情報を入手できないことを示します。同じメッセージがDashBoardInfo.txtファイルのユーザー・ストアと認証ストアのセクションに表示されます。正しいLDAP接続の詳細をOpenSSOAgentDiscTool.propertiesファイルに指定してファイルを保存し、評価ツールを再実行する必要があります。

これらのパラメータについて不適切な値を指定した場合、評価ツールを実行できず、エラーが表示されます。

5.9.3 OpenSSOエージェント評価ツールの実行

OpenSSOエージェント評価ツールを実行するには、次の操作を行います。

1. 第5.9.1項「評価ツールの入手」の説明に従い、次のコマンドを使用して、内容を抽出したフォルダにディレクトリを変更します。

cd <path to the unzipped folder>

2. 次のコマンドを実行します。

java -jar openssoagentdisc.jar OpenSSO_server_URL username debugLevel

このコマンドでは、次のように指定します。

OpenSSO_server_URLは、OpenSSO Enterprise 8.0サーバーのURLです。URLはhttp://host:port/openssoの形式で指定する必要があります。hostおよびportは、OpenSSO Enterprise 8.0サーバーが動作しているマシンのホスト名とポートを表します。

usernameは、OpenSSO Enterprise 8.0サーバーのユーザー名です。

debugLevelパラメータはオプションです。このパラメータの値は、errorまたはmessageのいずれかにします。コマンドでこのパラメータを指定しない場合、デフォルト値errorを取ります。

次の入力が求められます。

1. Enter server login password:
OpenSSO Enterprise 8.0サーバーの管理ユーザーのパスワードを入力します。

2. Enter LDAP login password:
LDAPサーバーのログイン・パスワードを入力します。

注意:

このコマンドで使用される引数の詳細は、解凍したディレクトリで次のコマンドを実行します。

java -jar openssoagentdisc.jar -help

5.9.4 評価レポートの分析

OpenSSOエージェント評価ツールは、次の場所に5つのカンマ区切りの値(CSV)ファイルを生成します。

unzipped_folder/consoleOutput/

これらのレポートには、Access Manager 11.1.2.2.0でサポートされる、OpenSSO Enterprise 8.0のエージェント、ポリシー、ユーザー・ストアおよび認証ストアに関する情報があります。

表5-3は、OpenSSOエージェント評価ツールの実行時に生成されるCSVファイルを示しています。

表5-3 生成されるレポート・ファイル

ファイル

説明

AgentInfo.csv

Sun OpenSSO Enterprise 8.0に登録されているJ2EEおよびWebエージェントに関する情報と、Access Manager 11.1.2.2.0でサポートされるエージェントのリストが含まれます。

AuthnStoreInfo.csv

認証ストアに関する情報が含まれます。

DashBoardInfo.csv

エージェント、ポリシー、ユーザー・ストアおよび認証ストアに関する簡単な情報が含まれます。

PolicyInfo.csv

ポリシーに関する情報が含まれます。

UserStoreInfo.csv

ユーザー・ストアに関する情報が含まれます。

注意:

CSVファイルは、CSVとして直接開くことも、Microsoft Excelを使用して開くこともできます。レポート内のデータは階層構造で表示されます。最上部にレルム名またはサブレルム名が表示され、エージェント、ポリシー、認証ストアおよびユーザー・ストアに関連するデータがその後に続きます。

5.10 WebLogic管理サーバーの起動

移行ツールを実行する前に、WebLogic管理サーバーを起動する必要があります。

WebLogic管理サーバーを起動するには、次の手順を実行します。

UNIXの場合:

1. コマンドを使用して、現在の作業ディレクトリからMW_HOME/user_projects/domains/domain_name/binディレクトリに移動します。

cd MW_HOME/user_projects/domains/domain_name/bin/

2. 次のコマンドを実行します。

./startWebLogic.sh

プロンプトが表示されたら、WebLogic管理サーバーのユーザー名とパスワードを入力します。

Windowsの場合:

1. コマンド行で次のコマンドを使用して、現在の作業ディレクトリからMW_HOME\user_projects\domains\domain_name\binディレクトリに移動します。

cd MW_HOME\user_projects\domains\domain_name\bin\

2. 次のコマンドを実行します。

startWebLogic.cmd

プロンプトが表示されたら、WebLogic管理サーバーのユーザー名とパスワードを入力します。

5.11 増分移行のための追加手順

この項では、増分移行を行う場合に実行する追加手順について説明します。完全移行やデルタ移行などの他の移行モードの場合、この項は無視してください。

評価レポートを生成すると(「評価レポートの生成」を参照)、IncrementalMigrationIncludeFile.txtというファイルがAssessmentToolUnzippedFolder/consoleOutput/に生成されます。このファイルの内容は次のとおりです。

REALM#TopRealm##AGENT#j2eeAgent_1##N

REALM#TopRealm##AGENT#j2eeAgent_2##N

REALM#TopRealm##POLICY#Policy1##N

REALM#TopRealm##POLICY#Policy2##N

各行には、OpenSSO Enterprise 8.0のレルム名、エージェントまたはポリシーの名前、およびデフォルトでNに設定されているフラグが含まれます。フラグの値Yは「Yes」を表し、Nは「No」を表します。指定されたフラグによって、エージェントまたはポリシーが増分移行に含まれるか、除外されるかが決まります。

注意:

前述の値では大文字と小文字が区別されません。

一部のエージェントおよびポリシーを増分移行に含める場合は、IncrementalMigrationIncludeFile.txtファイルでそれらのエージェントおよびポリシーのフラグをYに設定します。また、第5.12項「プロパティ・ファイルの作成」で作成するプロパティ・ファイルのopenSSOSMIncludeFilePathプロパティで、このファイルの絶対パスを指定します。これにより、フラグがYに設定されているすべてのエージェントおよびポリシーが移行に含まれます。

注意:

IncrementalMigrationIncludeFile.txtファイルの内容が空の場合、プロパティ・ファイルのopenSSOSMIncludeFilePathプロパティでこのファイルの絶対パスを指定しても、Open Single Sign-On 8.0のアーティファクトはAccess Manager 11.1.2.2.0に移行されません。

一部のエージェントおよびポリシーを増分移行から除外する場合は、IncrementalMigrationIncludeFile.txtファイルでそれらのエージェントおよびポリシーのフラグをYに設定します。また、第5.12項「プロパティ・ファイルの作成」で作成するプロパティ・ファイルのopenSSOSMExcludeFilePathプロパティで、このファイルの絶対パスを指定します。これにより、フラグがYに設定されているすべてのエージェントおよびポリシーが移行から除外されます。

注意:

IncrementalMigrationIncludeFile.txtファイルの内容が空の場合、プロパティ・ファイルのopenSSOSMExcludeFilePathプロパティでこのファイルの絶対パスを指定していれば、Open Single Sign-On 8.0のすべてのアーティファクトがAccess Manager 11.1.2.2.0に移行されます。つまり、完全移行が実行されます。

5.12 プロパティ・ファイルの作成

アクセス可能な場所でプロパティ・ファイルを作成します。たとえば、oam_migration.propertiesという名前でプロパティ・ファイルを作成します。

プロパティ・ファイルで次のプロパティについて適切な値を入力します。

- openSSOServerURL=OpenSSO_server_URL

- openSSOAdminUser=OpenSSO_admin_username

- openSSOAdminPassword=

- openSSOServerDebugLevel=error/message

- openSSOLDAPServerURL=LDAP host:port

- openSSOLDAPBindDN=LDAP_bind_DN

- openSSOLDAPBindPwd=

- openSSOLDAPSearchBase=LDAP_searchBase

- openSSOMigrationMode=Complete/Incremental

- openSSOSMIncludeFilePath=absolute_path_to_include_file

- openSSOSMExcludeFilePath=absolute_path_to_exclude_file

表5-4は、プロパティ・ファイルの各プロパティに指定する必要がある値の説明です。

表5-4 プロパティ・ファイルの値

プロパティ

説明

openSSOServerURL

OpenSSO Enterprise 8.0管理サーバーのURLを指定します。これは次の形式で指定してください。

http://<host>:<port>/opensso

各項目は次のとおりです。

<host>は、OpenSSO Enterprise 8.0管理サーバーが動作しているマシンです。

<port>は、OpenSSO Enterprise管理サーバーのポート番号です。

openSSOAdminUser

OpenSSO Enterprise 8.0管理サーバーのユーザー名を指定します。

openSSOAdminPassword

このプロパティの値を指定しないでください。手順4の説明に従い、移行コマンドを実行すると、移行ツールによってOpenSSO Enterprise管理パスワードの入力が求められます。

openSSOServerDebugLevel

次のいずれかの値を指定します。

- error

- message

この値はデバッグ・レベルを表します。

openSSOLDAPServerURL

LDAPサーバーのURLを指定します。これは次の形式で指定してください。

host:port

各項目は次のとおりです。

hostは、OpenSSO Enterprise 8.0で使用される構成ストアのLDAPホストを表します。

portは、OpenSSO Enterprise 8.0で使用される構成ストアのLDAPポートを表します。

hostおよびportの値はコロンで区切る必要があります。

openSSOLDAPBindDN

LDAPサーバーのバインドDNを指定します。このユーザーには、OpenSSO Enterpriseの構成ディレクトリ・サーバーの管理権限またはルート権限が必要です。

openSSOLDAPBindPwd

このプロパティの値を指定しないでください。手順4の説明に従い、移行コマンドを実行すると、移行ツールによってLDAPバインド・パスワードの入力が求められます。

openSSOLDAPSearchBase

構成ストアのLDAP検索ベースを指定します。

openSSOMigrationMode

このプロパティに次のいずれかの値を設定して、移行のモードを指定します。

- Complete
完全移行を実行する場合、この値を設定します。

- Incremental
増分移行を実行する場合、この値を設定します。増分移行は、openSSOSMIncludeFilePathおよびopenSSOSMExcludeFilePathプロパティによって決まります。

- DELTA
デルタ移行を実行する場合、この値を設定します。

このプロパティに値を指定しなかった場合は、完全移行が実行されます。また、値CompleteまたはIncrementalに誤りがあった場合、移行モードはCompleteとみなされ、完全移行が実行されます。

これらの値では、大/小文字が区別されます。

移行のモードの詳細は、「移行のモード」を参照してください。

openSSOSMIncludeFilePath

増分移行を実行する場合、OpenSSO Enterprise 8.0の一部のエージェントおよびポリシーを移行に含めるには、openSSOSMIncludeFilePathプロパティを使用する必要があります。

openSSOSMIncludeFilePathプロパティの値は、移行に含めるエージェントおよびポリシーのフラグがYに設定されているIncrementalMigrationIncludeFile.txtの絶対パスである必要があります。IncrementalMigrationIncludeFile.txtファイルの詳細は、「増分移行のための追加手順」を参照してください。

openSSOSMIncludeFilePathプロパティを指定して増分移行を実行する場合は、openSSOSMExcludeFilePathプロパティをコメント・アウトします。

増分移行の実行時にopenSSOSMIncludeFilePathとopenSSOSMExcludeFilePathの両方のプロパティを指定した場合、openSSOSMIncludeFilePathプロパティがopenSSOSMExcludeFilePathプロパティより優先され、openSSOSMExcludeFilePathプロパティは無視されます。

完全移行の場合、このプロパティは無視してください。

openSSOSMExcludeFilePath

増分移行を実行する場合、OpenSSO Enterprise 8.0の一部のエージェントおよびポリシーを移行から除外するには、openSSOSMExcludeFilePathプロパティを使用する必要があります。

openSSOSMExcludeFilePathプロパティの値は、移行から除外するエージェントおよびポリシーのフラグがYに設定されているIncrementalMigrationIncludeFile.txtの絶対パスである必要があります。IncrementalMigrationIncludeFile.txtファイルの詳細は、「増分移行のための追加手順」を参照してください。

openSSOSMExcludeFilePathプロパティを指定して増分移行を実行する場合は、openSSOSMIncludeFilePathプロパティをコメント・アウトします。

増分移行の実行時にopenSSOSMExcludeFilePathとopenSSOSMIncludeFilePathの両方のプロパティを指定した場合、openSSOSMIncludeFilePathプロパティがopenSSOSMExcludeFilePathプロパティより優先され、openSSOSMExcludeFilePathプロパティは無視されます。

完全移行の場合、このプロパティは無視してください。

注意:

openSSOAdminPasswordおよびopenSSOLDAPBindPwdプロパティの値を指定しないでください。

openSSOSMExcludeFilePathまたはopenSSOSMExcludeFilePathで指定したファイル・パスが正しくない場合や、指定したファイル・パスが権限の問題のために読取り可能でない場合、該当するエラー・メッセージが表示されます。これをログ・ファイルで確認することもできます。

増分移行を実行する際にIncrementalMigrationIncludeFile.txtファイルが空の場合は、モードがCompleteに変更され、完全移行が実行されます。

5.13 OpenSSO Enterprise 8.0のアーティファクトのAccess Manager 11.1.2.2.0への移行

OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0,にアーティファクトを実際に移行する前に、評価レポートを生成して(第5.9項「評価レポートの生成」を参照)、Access Manager 11gにどのアーティファクトを移行できるかを分析したことを確認します。

Sun OpenSSO Enterprise 8.0をAccess Manager 11.1.2.2.0に移行するには、次の手順を実行します。

1. 増分移行を実行する場合は、第5.11項「増分移行のための追加手順」に記載されている追加手順を実行していることを確認します。

2. 第5.12項「プロパティ・ファイルの作成」の説明に従ってプロパティ・ファイルを作成していることを確認します。

3. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME/common/binディレクトリに移動します。
cd IAM_HOME/common/bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
./wlst.sh

Windowsの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME\common\binディレクトリに移動します。
cd IAM_HOME\common\bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
wlst.cmd

4. 次のコマンドを実行して、WLSTをWebLogic Serverインスタンスに接続します。

connect('wls_admin_username','wls_admin_password','t3://hostname:port');

このコマンドでは、次のように指定します。

wls_admin_usernameは、WebLogic管理サーバーのユーザー名です。

wls_admin_passwordは、WebLogic管理サーバーのパスワードです。

hostnameは、WebLogic管理サーバーが動作しているマシンです。

portは、管理サーバーのポートです。

5. 次のコマンドを実行して、OpenSSO Enterprise 8.0のアーティファクトをAccess Manager 11.1.2.2.0に移行します。

oamMigrate(oamMigrateType="OpenSSO",pathMigrationPropertiesFile="absolute_path_of_properties_file");

このコマンドでは、次のように指定します。

absolute_path_of_properties_fileは、手順1で作成したプロパティ・ファイルの絶対パスです。次に例を示します。

UNIXの場合: oamMigrate(oamMigrateType="OpenSSO",pathMigrationPropertiesFile="abc/def/oam_migration.properties"

Windowsの場合: oamMigrate(oamMigrateType="OpenSSO",pathMigrationPropertiesFile="abc\\def\\oam_migration.properties

次の入力が求められます。

1. Enter value for property : openSSOAdminPassword :
OpenSSO Enterprise 8.0管理サーバーのパスワードを入力します。

2. Enter value for property : openSSOLDAPBindPwd :
LDAPサーバーへのバインド・パスワードを入力します。

注意:

初めてoamMigrate()コマンドを実行すると、完全移行が行われます。

最初の移行(完全移行)後、このコマンドを再実行してデルタ移行を行うことができます。

完全移行とデルタ移行の詳細は、第5.2項「移行のモード」を参照してください。

移行が完了すると、WLSTコンソールには、移行の結果を示すメッセージが表示されます。

5.14 移行後タスクの実行

OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0に移行した後、次の移行後のタスクを完了する必要があります。

1. エージェントのアーティファクト(プロパティ・ファイル)は、移行を実行すると生成されます。次の2つのプロパティ・ファイルが、domain_home/output/OpenSSOMigration/OpenSSO8.0/Realm_Name/Agent_Name/*.propertiesに生成されます。

- OpenSSOAgentBootstrap.properties

- OpenSSOAgentConfiguration.properties

これらのプロパティ・ファイルをエージェントの構成場所にコピーする必要があります。エージェントごとに、次の手順を完了します。

1. エージェントを停止します。

2. 既存のプロパティ・ファイル(移行プロセスを開始する前にエージェント・ホストに存在したプロパティ・ファイル)をバックアップします。

3. エージェントのアーティファクト(プロパティ・ファイル)をエージェントのデプロイメントの場所にコピーします。
/agent_install_dir/weblogic_v10_agent/Agent_001/config

4. OpenSSOAgentBootstrap.propertiesファイルのコンテナ固有のプロパティを次のように変更します。
Glassfishエージェントの場合、次のプロパティを設定します。

com.sun.identity.agents.config.service.resolver=com.sun.identity.agents.appserver.v81.AmASAgentServiceResolver

WebLogicエージェントの場合、次のプロパティを設定します。

com.sun.identity.agents.config.service.resolver=com.sun.identity.agents.weblogic.v10.AmWLAgentServiceResolver

5. エージェントを再起動します。

6. ブラウザのCookieとキャッシュを消去します。

2. 移行ツールは、OpenSSO Enterprise 8.0からAccess Manager 11.1.2.2.0に移行されるユーザー・ストアのパスワードを取得しません。そのため、移行後は、移行されるすべてのユーザー・ストアのパスワードを手動で更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

このURLでは、hostは、Oracle Access Managementサーバーをホストするマシンの完全修飾ドメイン名を表し、portは、Oracle Access Managementコンソールの指定のバインド・ポート(管理サーバーのバインド・ポートと同じ)を表します。

2. 「システム構成」タブに移動します。

3. 「共通構成」の左ナビゲーション・ペインで「データソース」を開きます。

4. 「ユーザー・アイデンティティ・ストア」を開き、存在する移行後のすべてのLDAPユーザーのパスワードを手動で更新します。

3. 移行後、移行した認証ストアの最小および最大プール・サイズはデフォルトで0に設定されます。そのため、Oracle Access Management 11.1.2.2.0コンソールで認証ストアの「最小プール・サイズ」と「最大プール・サイズ」に適切な値を手動で設定する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

2. 「システム構成」タブに移動します。

3. 左のナビゲーション・ペインで「共通構成」を開きます。

4. 「データソース」→「ユーザー・アイデンティティ・ストア」を開きます。

5. 編集する認証ストアを選択します。

6. 「接続の詳細」にスクロール・ダウンして、「最小プール・サイズ」と「最大プール・サイズ」の値を設定します。たとえば、最小プール・サイズを10、最大プール・サイズを50にします。

7. 「適用」をクリックします。

4. 次の手順を実行して、Access Manager管理対象サーバーおよび移行したエージェントのWebインスタンスを再起動します。

1. 移行されているエージェントのWebコンテナ・インスタンスを停止します。

2. Access Manager管理対象サーバーを停止します。
管理対象サーバーの停止の詳細は、付録A「管理対象サーバーの停止」を参照してください。

3. Access Manager管理対象サーバーを起動します。
管理対象サーバーの起動の詳細は、付録A「管理対象サーバーの起動」を参照してください。

4. 移行されているエージェントのWebコンテナ・インスタンスを起動します。

5.15 移行の確認

移行を確認するには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Management 11.1.2.2.0コンソールをホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

OpenSSO Enterpriseのエージェント、ユーザー・ストア、認証ストア、認証モジュール、ホスト識別子、リソース、および正しい認証モジュールを備えた正しい認証スキームのポリシーがAccess Manager 11.1.2.2.0に移行されていることを確認します。

2. URLを使用して、保護されているページにアクセスします。このURLにより、Oracle Access Managementサーバーの「ログイン」ページにリダイレクトされるようになっています。認証が成功すると、正常な認可が実行され、リソースに正常にアクセスできます。

6 Sun Java System Access Manager 7.1環境の移行

この章では、Sun Java System Access Manager 7.1をOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.2.0)に移行する方法について説明します。

この章は次の項で構成されています。

- 第6.1項「移行の概要」

- 第6.2項「移行のモード」

- 第6.3項「移行のサマリー」

- 第6.4項「トポロジの比較」

- 第6.5項「移行ロードマップ」

- 第6.6項「移行の前提条件」

- 第6.7項「Oracle Identity and Access Management11.1.2.2.0のインストール」

- 第6.8項「Oracle Access Manager 11.1.2.2.0の構成」

- 第6.9項「評価レポートの生成」

- 第6.10項「WebLogic管理サーバーの起動」

- 第6.11項「増分移行のための追加手順」

- 第6.12項「プロパティ・ファイルの作成」

- 第6.13項「Sun Java System Access Manager 7.1のアーティファクトのOAM 11.1.2.2.0への移行」

- 第6.14項「移行後タスクの実行」

- 第6.15項「移行の確認」

6.1 移行の概要

この項では、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0への移行プロセスで使用される2つのツールを紹介します。

OpenSSOエージェント評価ツール

OpenSSOエージェント評価ツールは、Sun Java System Access Manager 7.1サーバーからエージェントとポリシーを読み取り、Access Manager 11.1.2.2.0に移行可能なエージェントとポリシー要素を分析して、評価レポートを生成します。生成されたレポートでは、エージェントを移行できるかどうかと、Access Manager 11.1.2.2.0ポリシー・モデルに基づいて、ポリシーの手動移行、自動移行または準移行のいずれが可能かについての情報が提供されます。

評価ツールは、Sun Java System Access Manager 7.1のエージェント、プロファイル、ポリシー、ユーザー・ストアおよび認証ストアに関する情報を読み取り、表示します。このツールは、Access Manager 11.1.2.2.0でサポートされるアーティファクトに関する情報に基づいて、Access Manager 11.1.2.2.0に移行できるデータとAccess Manager 11.1.2.2.0に移行できないデータを評価します。

Sun Java System Access Manager 7.1環境を移行する前に、評価ツールを使用して評価レポートを複数回生成できます。

移行ツール

移行ツールは、Sun Java System Access Manager 7.1の次のアーティファクトをAccess Manager 11.1.2.2.0に移行します。

- エージェントの構成

- ポリシー

- ユーザー・ストアの構成

- 認証ストアの構成

注意:

移行ツールと評価ツールでは、SSLポートを介した構成ストアへの接続はサポートされません。

他の移行シナリオの詳細は、第1.2項「移行および共存のシナリオ」を参照してください。

6.2 移行のモード

この項では、この章で説明する手順を使用して実行可能な移行の3つのモードについて説明します。移行のモードは次の2つになります。

- 完全移行

- 増分移行

- デルタ移行

6.2.1 完全移行

完全移行は、Sun Java System Access Manager 7.1の互換性のあるエージェント、ポリシー、ユーザー・ストアおよび認証ストアをすべてAccess Manager 11.1.2.2.0に移行します。初めて行う移行は完全移行になります。最初の移行後、次に行われるそれぞれの移行はデルタ移行になります。完全移行を実行できるのは最初の1回のみです。

新規移行では、移行フレームワークによってAccess Manager 11.1.2.2.0構成ストアで移行バージョンが設定されます。

完全移行を実行するには、「移行ロードマップ」で説明する手順に従います。

注意:

完全移行が失敗した場合、完全移行の再実行を開始する前に、部分的に移行されたデータを手動で削除する必要があります。

6.2.2 増分移行

増分移行は、選択移行とも呼ばれます。Access Manager 11.1.2.2.0に移行するSun Java System Access Manager 7.1のエージェントおよびポリシーを選択できるためです。この移行は、様々なエージェントおよびポリシーのセットを使用して複数回実行できるため、増分移行と呼ばれます。増分移行の対象としてユーザー・ストアおよび認証ストアのみを選択することはできません。増分移行の対象としてエージェントおよびポリシーを選択する際に、それぞれのユーザー・ストアおよび認証ストアも選択する必要があります。

注意:

完全移行を実行した後、増分移行を実行できます。これは、増分デルタと呼ばれます。

複数の増分移行の後、完全移行を実行できます。この場合、完全移行では、以前の増分移行の一環としてすでに移行されているエージェントとポリシーは無視されます。

すでに移行されているアーティファクト(エージェントおよびポリシー)を選択して複数の増分移行を実行した場合、それらのアーティファクトは無視され、増分移行では、移行されていないアーティファクトのみが移行されます。

6.2.3 デルタ移行

デルタ移行は、Sun Java System Access Manager 7.1の新しく追加されたアーティファクト(エージェント、ポリシー、ユーザー・ストアおよび認証ストア)をAccess Manager 11.1.2.2.0に移行できる移行モードです。デルタ移行は、作成操作の場合のみサポートされます。

1回目の移行(完全移行)後、実行する移行はすべてデルタ移行になります。

デルタ移行を実行するたびに、完全移行によってAccess Manager 11.1.2.2.0構成ストアで設定される移行バージョンに関する情報が取得され、1ずつ増えて、Access Manager 11.1.2.2.0構成ストアに保存されます。

データ移行を実行する手順は、完全移行の手順と同じで「移行ロードマップ」で説明します。

6.3 移行のサマリー

この項では、Access Manager 11.1.2.2.0と互換性のあるSun Java System Access Manager 7.1のアーティファクトについてまとめています。この項には次のトピックが含まれます:

- エージェントの移行のサマリー

- ポリシーの移行のサマリー

- ユーザー・ストアの移行のサマリー

- 認証ストアの移行のサマリー

6.3.1 エージェントの移行のサマリー

この項では、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0へのエージェントの移行についてまとめています。

- この移行ツールは、エージェント自体ではなくエージェント構成を移行します。移行でサポートされるWebエージェント2.2はSun Java System Web Server 7.0です。

- ローカル・エージェントは、最小限の構成で移行されます。ローカル・エージェントはローカル構成モードで機能するエージェントです。これらのエージェントは、各自の構成のローカル構成ファイルのみを受け入れます。ローカル・エージェントのエージェントID、エージェント・パスワード、エージェント・ベースURLなどの基本構成プロパティのみがSun Java System Access Manager 7.1サーバーに保存されます。移行後、このような構成の詳細はAccess Manager 11.1.2.2.0サーバーに保存されます。

- エージェントの移行には下位互換性があります。

- 異なるレルムに名前が同じエージェントが2つ以上存在する場合、エージェントは先頭にレルム名が付いた名前で移行されます。
例: j2eeAgentという名前のエージェントがTopRealm(/)とSubRealm(/>SubRealm)の両方に存在する場合、これらのエージェントは、TopRealm_j2eeAgentおよびSubRealm_j2eeAgentという名前で移行されます。

6.3.2 ポリシーの移行のサマリー

この項では、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0へのポリシーの移行についてまとめています。

Sun Java System Access Manager 7.1のポリシーは、次の4つのアーティファクトで構成されます。

- ルール(リソース + アクション)

- サブジェクト

- 条件

- レスポンス・プロバイダ

OpenSSOエージェント評価ツールの実行時に生成される評価レポート(PolicyInfo.txt)のポリシーは、Access Manager 11.1.2.2.0のアーティファクトの互換性に基づき、自動ポリシー、準ポリシーおよび手動ポリシーに分類されます。

- 自動ポリシー: 該当ポリシーのすべてのアーティファクトをAccess Manager 11.1.2.2.0のポリシーのアーティファクトにマップできる場合は、自動ポリシーとみなされます。自動ポリシーはすべてAccess Manager 11.1.2.2.0に移行できます。

- 準ポリシー: 該当ポリシーの一部のアーティファクトをAccess Manager 11.1.2.2.0のポリシーのアーティファクトにマップできる場合は、準ポリシーとみなされます。準ポリシーはAccess Manager 11.1.2.2.0に移行されません。

- 手動ポリシー: 該当ポリシーのどのアーティファクトもAccess Manager 11.1.2.2.0のポリシーのアーティファクトにマップできない場合は、手動ポリシーとみなされます。手動ポリシーはAccess Manager 11.1.2.2.0に移行されません。

Sun Java System Access Manager 7.1には次の2種類のポリシーがあります。

- 参照ポリシー: これらのポリシーは移行に適用されません。

- 非参照ポリシー: これらのポリシーは移行されます。

ルール

- ルールを使用しないSun Java System Access Manager 7.1のポリシーは移行でサポートされません。このようなポリシーは無効とみなされます。

- 移行に適用できるのは、アクションGETおよびPOSTが含まれるルールのみです。これらのルールには、サービス・タイプURL Policy Agentがあります。

- その他のサービス・タイプ(LOOKUPおよびUPDATEアクションが含まれるDiscovery Serviceや、QUERYおよびMODIFYアクションが含まれるLiberty Personal Profile Serviceなど)は、移行に適用されません。これらのアクション(Access Manager 11.1.2.2.0でリソース操作と呼ばれる)はAccess Manager 11.1.2.2.0でサポートされていないためです。

サブジェクト

移行でサポートされるサブジェクト・タイプは、AM Identity Subject(ユーザーおよびグループ)とAuthenticated Usersのみです。これらのサブジェクトは、Access Manager 11.1.2.2.0でIdentity Conditionの一部として移行されます。

条件

- アクティブ・セッション時間

- Sun Java System Access Manager 7.1ポリシーのこの条件は、Access Manager 11.1.2.2.0のAttributeConditionのSession Expiry Time属性にマップされます。

- この条件の属性Terminate sessionは、この属性の適切なマッピングがAccess Manager 11.1.2.2.0に存在しないため、移行時に無視されます。

- モジュール・インスタンスごとの認証

- Sun Java System Access Manager 7.1ポリシーのこの条件は、Access Manager 11.1.2.2.0に条件ではなくAuthNスキームとして移行されます。

- 表6-1は、Access Manager 11.1.2.2.0に移行されてAuthNスキームでマップされるSun Java System Access Manager 7.1の認証モジュールを示しています。

表6-1 認証モジュールのマッピング

Sun Java System Access Manager 7.1の認証モジュール

Access Manager 11.1.2.2.0の認証プラグイン

証明書認証モジュール

X509認証プラグイン

WindowsDesktopSSO認証モジュール

Kerberos認証プラグイン

LDAP認証モジュール

LDAP認証プラグイン

- 認証レベル(less than or equal to)および認証レベル(greater than or equal to)

- Sun Java System Access Manager 7.1ポリシーのどちらの条件も、ネームスペースがSESSIONで属性名がAuthentication LevelのAttributeConditionのセッション属性にマップされます。

- Access Manager 11.1.2.2.0にはgreater than or equal toおよびless than or equal toに対応するマッピングがないため、どちらの条件もAttributeOperatorのEQUALSにマップされます。このマッピングは、Sun Java System Access Manager 7.1のポリシー条件のequalsファクタが原因で行われます。そのため、greater than or equal toとless than or equal toのどちらの条件もAccess Manager 11.1.2.2.0では同様になります。
たとえば、認証レベルの条件がless than or equal to 5のSun Java System Access Manager 7.1ポリシーを移行する場合、Access Manager 11.1.2.2.0の移行後のポリシーの認証レベルはequal to 5になります。

- 現在のセッション・プロパティ

- この条件は、ネームスペースがSESSIONで属性名がOtherのAttributeConditionのセッション属性にマップされ、キーと値がこの条件の属性として追加されます。Sun Java System Access Manager 7.1のこの条件の値は複数になります。そのため、Access Manager 11.1.2.2.0のこの条件には、名前は同じでも値が異なる複数の属性があります。

- アイデンティティ・メンバーシップ

- Sun Java System Access Manager 7.1ポリシーのこの条件は、Access Manager 11.1.2.2.0のIdentity conditionにマップされます。

- Sun Java System Access Manager 7.1のすべてのサブジェクトの一意のユーザーまたはグループ、およびすべてのアイデンティティ・メンバーシップ条件の一意のユーザーまたはグループは、Access Manager 11.1.2.2.0の1つのアイデンティティ条件にユーザーまたはグループのセットとして作成されます。

- 実行時の検証では、ユーザーまたはグループのこのセット間でORが実行されます。

- IPアドレスおよびDNS名

- Sun Java System Access Manager 7.1ポリシーの条件IP Addressは、Access Manager 11.1.2.2.0のIP conditionにマップされます。

- 条件DNS nameはAccess Manager 11.1.2.2.0ではサポートされません。

- LDAPフィルタ条件

- Sun Java System Access Manager 7.1ポリシーのこの条件は、Access Manager 11.1.2.2.0のIdentity conditionにマップされます。

- Sun Java System Access Manager 7.1のすべてのLDAPフィルタ条件の一意のLDAPフィルタはすべて、Access Manager 11.1.2.2.0の1つのアイデンティティ条件にLDAPフィルタのセットとして作成されます。

- 時間(曜日、日付、時刻およびタイムゾーン)

- Sun Java System Access Manager 7.1ポリシーのこの条件は、Access Manager 11.1.2.2.0のTime conditionにマップされます。

- Sun Java System Access Manager 7.1のTime条件には、日付、時刻、曜日またはタイムゾーンのいずれかの値が含まれます。Access Manager 11.1.2.2.0のTime条件には、時刻または曜日が含まれます。そのため、時刻(開始および終了時刻)と曜日のみを含むSun Java System Access Manager 7.1のTime条件をAccess Manager 11.1.2.2.0のTime条件にマップできます。それ以外の場合はすべて無視されます。

レスポンス・プロバイダ

- Sun Java System Access Manager 7.1サーバーまたはポリシー・サーバーは、アイデンティティまたはユーザー・リポジトリ属性(ユーザー・ストアのユーザー属性)をレスポンス・プロバイダとしてエージェントに送信します。OpenSSOエージェントは、これらの属性を、エージェントの構成に従ってHttpヘッダー、リクエスト属性またはHttp Cookieを介してリソースまたはアプリケーションに戻します。
レスポンス・プロバイダ(静的および動的)はすべて、Httpヘッダー・タイプでSun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0に移行されます。

6.3.3 ユーザー・ストアの移行のサマリー

この項では、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0へのユーザー・ストアの移行についてまとめています。

OpenSSO Enterprise 8.0には次の3種類のユーザー・ストアがあります。

- アクティブ・ディレクトリ: このユーザー・ストアはAccess Manager 11.1.2.2.0に移行できます。

- 汎用LDAPv3: このユーザー・ストアはAccess Manager 11.1.2.2.0に移行できます。

- OpenSSOスキーマのSun DS: 11.1.2.2.0ではサポートされるデータ・ストアのタイプがないため、このユーザー・ストアは、Access Manager 11.1.2.2.0に移行できません。

6.3.4 認証ストアの移行のサマリー

この項では、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0への認証ストアの移行についてまとめています。

Access Manager 11.1.2.2.0の対応する認証モジュールに移行およびマップ可能なSun Java System Access Manager 7.1の認証ストアは、次のとおりです。

- Sun Java System Access Manager 7.1のLDAPは、Access Manager 11.1.2.2.0のOAM LDAPにマップされます。

- Sun Java System Access Manager 7.1の証明書は、Access Manager 11.1.2.2.0のX509にマップされます。

- Sun Java System Access Manager 7.1のWindows Desktop SSOは、Kerberos Access Manager 11.1.2.2.0にマップされます。

LDAPタイプの認証ストアはすべて、名前AS_レルム名_モジュール名でAccess Manager 11.1.2.2.0に移行されます。LDAP以外のタイプの認証ストアは移行されません。

6.4 トポロジの比較

図6-1は、Sun Java System Access Manager 7.1とAccess Manager 11.1.2.2.0のトポロジを比較したものです。

図6-1 Sun Java System Access Manager 7.1とAccess Manager 11.1.2.2.0のトポロジ

6.5 移行ロードマップ

表6-2に、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0への移行手順を示します。

表6-2 タスク・ロードマップ

タスク番号

タスク

参照先

1

前提条件を満たします。

「移行の前提条件」を参照してください。

2

Oracle Identity and Access Management 11.1.2.2.0をインストールします。

「Oracle Identity and Access Management 11.1.2.2.0のインストール」を参照してください。

3

Oracle Access Management Access Manager 11.1.2.2.0を構成します。

「Oracle Access Manager 11.1.2.2.0の構成」を参照してください。

4

評価レポートを生成し、Access Manager 11.1.2.2.0にどのアーティファクトを移行できるかを分析します。

このタスクは複数回実行できます。

「評価レポートの生成」を参照してください。

5

WebLogic管理サーバーを起動します。

「WebLogic管理サーバーの起動」を参照してください。

6

増分移行を実行する場合は、追加手順を実行します。

「増分移行のための追加手順」を参照してください。

7

プロパティ・ファイルを作成します。

「プロパティ・ファイルの作成」を参照してください。

8

移行ツールを実行して、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0に移行します。

「Sun Java System Access Manager 7.1のアーティファクトのOAM 11.1.2.2.0への移行」を参照してください。

9

移行後の手順を完了します。

「移行後タスクの実行」を参照してください。

10

移行を確認します。

「移行の確認」を参照してください。

6.6 移行の前提条件

Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0に移行するには、次の前提条件を満たす必要があります。

1. システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

2. 使用しているSun Java System Access Managerのリリースが移行でサポートされていることを確認します。Sun Java System Access Manager 7.1の移行がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。

6.7 Oracle Identity and Access Management 11.1.2.2.0のインストール

移行プロセスの一環として、Oracle Identity and Access Management 11.1.2.2.0を新規でインストールする必要があります。この11.1.2.2.0のインストールは、Sun Java System Access Manager 7.1をインストールするマシンまたは別のマシンで行うことができます。

Oracle Identity and Access Management 11.1.2.2.0のインストールの詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドのOracle Identity and Access Management (11.1.2.2.0)のインストールに関する説明を参照してください。

6.8 Oracle Access Manager 11.1.2.2.0の構成

Oracle Identity and Access Management 11.1.2.2.0のインストール後、ドメインでAccess Manager 11.1.2.2.0を構成する必要があります。

Access Manager 11.1.2.2.0の構成の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Access Managementの構成に関する項を参照してください。

6.9 評価レポートの生成

この項では、OpenSSOエージェント評価ツールを使用して評価レポートを生成する方法について説明します。評価レポートには、Sun Java System Access Manager 7.1デプロイメントで利用可能なエージェント、ポリシー、ユーザー・ストアおよび認証ストアのプレビューが表示され、Access Manager 11.1.2.2.0に移行可能なアーティファクトが示されます。

移行プロセスを開始する前に、評価レポートを複数回生成できます。

この項には次のトピックが含まれます:

- ツールの入手

- LDAP接続の詳細の指定

- 2.2エージェントのエージェント・プロファイルの更新

- OpenSSOエージェント評価ツールの実行

- 評価レポートの分析

注意:

評価ツールを実行する前に、次の前提条件を満たす必要があります。

- Access Manager 7.1をデプロイするコンテナを起動します。

- JDKは必ず1.6以上のバージョンを使用してください。

- JDK 1.6をインストールする適切な場所に、変数JAVA_HOMEを設定します。

6.9.1 ツールの入手

次のコマンドを使用して、現在の作業ディレクトリからIAM_HOME/oam/server/tools/opensso_assessmentに移動します。

UNIXの場合:

cd IAM_HOME/oam/server/tools/opensso_assessment/

Windowsの場合:

cd IAM_HOME\oam\server\tools\opensso_assessment\

OpenssoAgentdiscTool.zipフォルダの内容を、選択したディレクトリに抽出します。解凍したフォルダには名前OpenssoAgentdiscToolを使用することをお薦めします。

6.9.2 LDAP接続の詳細の指定

評価ツールを実行する前に、LDAP接続の詳細をプロパティ・ファイルで指定する必要があります。手順は次のとおりです。

1. 次の場所にあるOpenSSOAgentDiscTool.propertiesファイルを開きます。
UNIXの場合: unzipped_folder/resources/

Windowsの場合: unzipped_folder\resources\

2. 次のプロパティについて適切な値を設定します。

- openSSOLDAPServerURL=host:port
このプロパティでは、hostおよびportは、Sun Java System Access Manager 7.1で使用される構成ストアのLDAPホストとポートを表します。

- openSSOLDAPBindDN=login_id
ここで、login_idは、LDAPサーバーのバインドDNになります。Sun Java System Access Manager 7.1の構成ディレクトリ・サーバーの管理権限またはルート権限が必要です。

- openSSOLDAPSearchBase=LDAP_search_base
ここで、LDAP_search_baseは、構成ストアのLDAP検索ベースになります。

3. ファイルを保存して閉じます。

注意:

LDAP接続の詳細を指定しない場合、メッセージがUserStoresInfo.txtファイルとAuthnStoreInfo.txtファイルに表示されます。このメッセージは、情報を入手できないことを示します。同じメッセージがDashBoardInfo.txtファイルのユーザー・ストアと認証ストアのセクションに表示されます。正しいLDAP接続の詳細をOpenSSOAgentDiscTool.propertiesファイルに指定してファイルを保存し、評価ツールを再実行する必要があります。

これらのパラメータについて不適切な値を指定した場合、評価ツールを実行できず、エラーが表示されます。

6.9.3 2.2エージェントのエージェント・プロファイルの更新

OpenSSOエージェント評価ツールを実行する前に、移行する2.2エージェントのエージェント・プロファイルを、エージェント・キーの値でエージェントの属性agentRootURLおよびtypeに適切な値を指定して更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してSun Java System Access Manager 7.1管理コンソールにログインします。

http://host:port/amserver

2. 「アクセス制御」タブに移動し、2.2エージェントをインストールするレルムをクリックします。

3. 「サブジェクト」タブに移動して、「エージェント」タブをクリックします。

4. 移行するエージェントのリンクをクリックします。

5. エージェント・キーの値で、属性agentRootURLおよびTypeの値がまだない場合は、これらの属性の適切な値を次の形式で「新規の値」フィールドに入力します。
agentRootURL=agent_webcontainer_URL

Type=WebAgent/J2EEAgent

注意:

前述のキーと値では大文字と小文字が区別されます。

各属性の入力後、「追加」をクリックします。

6. 「保存」をクリックします。

6.9.4 OpenSSOエージェント評価ツールの実行

OpenSSOエージェント評価ツールを実行するには、次の操作を行います。

1. 第6.9.1項「評価ツールの入手」の説明に従い、次のコマンドを使用して、内容を抽出したフォルダにディレクトリを変更します。

cd <path to the unzipped folder>

2. 次のコマンドを実行します。

java -jar openssoagentdisc.jar <sam server URL> <username> <debugLevel>

各項目は次のとおりです。

<sam server URL>は、Sun Java System Access Manager 7.1サーバーのURLです。これはhttp://<host>:<port>/amserver形式で指定します。<host>および<port>は、Sun Java System Access Manager 7.1サーバーが動作しているマシンのホスト名とポートを表します。

<username>は、Sun Java System Access Manager 7.1サーバーのユーザー名です。

<debugLevel>はオプションです。この引数の値は、errorまたはmessageのいずれかにします。コマンドでこの引数を指定しない場合、デフォルト値errorを取ります。

次の入力が求められます。

1. Enter server login password:
Sun Java System Access Manager 7.1サーバーの管理ユーザーのパスワードを入力します。このユーザーは、通常amadminになります。

2. Enter LDAP login password:
LDAPサーバーのログイン・パスワードを入力します。

注意:

このコマンドで使用される引数の詳細は、解凍したディレクトリで次のコマンドを実行します。

java -jar openssoagentdisc.jar -help

6.9.5 評価レポートの分析

評価ツールは、次の場所に5つのカンマ区切りの値(CSV)ファイルを生成します。

unzipped_folder/consoleOutput/

これらのレポートには、Access Manager 11.1.2.2.0でサポートされる、Sun Java System Access Manager 7.1のエージェント、ポリシー、ユーザー・ストアおよび認証ストアに関する情報があります。

表6-3は、評価ツールの実行時に生成されるCSVファイルを示しています。

表6-3 生成されるレポート・ファイル

ファイル

説明

AgentInfo.csv

Sun Java System Access Manager 7.1に登録されているJ2EEおよびWebエージェントに関する情報と、Access Manager 11.1.2.2.0でサポートされるエージェントのリストが含まれます。

AuthnStoreInfo.csv

認証ストアに関する情報が含まれます。

DashBoardInfo.csv

エージェント、ポリシー、ユーザー・ストアおよび認証ストアに関する簡単な情報が含まれます。

PolicyInfo.csv

ポリシーに関する情報が含まれます。

UserStoreInfo.csv

ユーザー・ストアに関する情報が含まれます。

注意:

CSVファイルは、CSVとして直接開くことも、Microsoft Excelを使用して開くこともできます。レポート内のデータは階層構造で表示されます。最上部にレルム名またはサブレルム名が表示され、エージェント、ポリシー、認証ストアおよびユーザー・ストアに関連するデータがその後に続きます。

6.10 WebLogic管理サーバーの起動

移行ツールを実行する前に、WebLogic管理サーバーを起動する必要があります。

管理サーバーを起動するには、次を実行します。

UNIXの場合:

1. コマンドを使用して、現在の作業ディレクトリからMW_HOME/user_projects/domains/domain_name/binディレクトリに移動します。

cd MW_HOME/user_projects/domains/domain_name/bin/

2. 次のコマンドを実行します。

startWebLogic.sh

プロンプトが表示されたら、WebLogic管理サーバーのユーザー名とパスワードを入力します。

Windowsの場合:

1. コマンド行で次のコマンドを使用して、現在の作業ディレクトリからMW_HOME\user_projects\domains\domain_name\binディレクトリに移動します。

cd MW_HOME\user_projects\domains\domain_name\bin\

2. 次のコマンドを実行します。

startWebLogic.cmd

プロンプトが表示されたら、WebLogic管理サーバーのユーザー名とパスワードを入力します。

6.11 増分移行のための追加手順

この項では、増分移行を行う場合に実行する追加手順について説明します。完全移行やデルタ移行などの他の移行モードの場合、この項は無視してください。

評価レポートを生成すると(「評価レポートの生成」を参照)、IncrementalMigrationIncludeFile.txtというファイルがAssessmentToolUnzippedFolder/consoleOutput/に生成されます。このファイルの内容は次のとおりです。

REALM#TopRealm##AGENT#j2eeAgent_1##N

REALM#TopRealm##AGENT#j2eeAgent_2##N

REALM#TopRealm##POLICY#Policy1##N

REALM#TopRealm##POLICY#Policy2##N

各行には、Sun Java System Access Manager 7.1のレルム名、エージェントまたはポリシーの名前、およびデフォルトでNに設定されているフラグが含まれます。フラグの値Yは「Yes」を表し、Nは「No」を表します。指定されたフラグによって、エージェントまたはポリシーが増分移行に含まれるか、除外されるかが決まります。

注意:

前述の値では大文字と小文字が区別されません。

一部のエージェントおよびポリシーを増分移行に含める場合は、IncrementalMigrationIncludeFile.txtファイルでそれらのエージェントおよびポリシーのフラグをYに設定します。また、第6.12項「プロパティ・ファイルの作成」で作成するプロパティ・ファイルのopenSSOSMIncludeFilePathプロパティで、このファイルの絶対パスを指定します。これにより、フラグがYに設定されているすべてのエージェントおよびポリシーが移行に含まれます。

注意:

IncrementalMigrationIncludeFile.txtファイルの内容が空の場合、プロパティ・ファイルのopenSSOSMIncludeFilePathプロパティでこのファイルの絶対パスを指定しても、Sun Java System Access Manager 7.1のアーティファクトはAccess Manager 11.1.2.2.0に移行されません。

一部のエージェントおよびポリシーを増分移行から除外する場合は、IncrementalMigrationIncludeFile.txtファイルでそれらのエージェントおよびポリシーのフラグをYに設定します。また、第6.12項「プロパティ・ファイルの作成」で作成するプロパティ・ファイルのopenSSOSMExcludeFilePathプロパティで、このファイルの絶対パスを指定します。これにより、フラグがYに設定されているすべてのエージェントおよびポリシーが移行から除外されます。

注意:

IncrementalMigrationIncludeFile.txtファイルの内容が空の場合、プロパティ・ファイルのopenSSOSMExcludeFilePathプロパティでこのファイルの絶対パスを指定していれば、Sun Java System Access Manager 7.1のすべてのアーティファクトがAccess Manager 11.1.2.2.0に移行されます。つまり、完全移行が実行されます。

6.12 プロパティ・ファイルの作成

アクセス可能な場所でプロパティ・ファイルを作成します。たとえば、oam_migration.propertiesという名前でプロパティ・ファイルを作成します。

プロパティ・ファイルで次のプロパティについて適切な値を入力します。

- openSSOServerURL=SAM_server_URL

- openSSOAdminUser=SAM_admin_username

- openSSOAdminPassword=

- openSSOServerDebugLevel=error/message

- openSSOLDAPServerURL=LDAP host:port

- openSSOLDAPBindDN=LDAP_bind_DN

- openSSOLDAPBindPwd=

- openSSOLDAPSearchBase=LDAP_searchBase

- openSSOMigrationMode=Complete/Incremental

- openSSOSMIncludeFilePath=absolute_path_to_include_file

- openSSOSMExcludeFilePath=absolute_path_to_exclude_file

表6-4は、プロパティ・ファイルの各プロパティに指定する必要がある値の説明です。

表6-4 プロパティ・ファイルの値

プロパティ

説明

openSSOServerURL

Sun Java System Access Manager 7.1サーバーのURLを指定します。これは次の形式で指定してください。

http://<host>:<port>/amserver

各項目は次のとおりです。

<host>は、Sun Java System Access Manager 7.1管理サーバーが動作しているマシンです。

<port>は、Sun Java System Access Manager管理サーバーのポート番号です。

openSSOAdminUser

Sun Java System Access Manager管理サーバーのユーザー名を指定します。

openSSOAdminPassword

このプロパティの値を指定しないでください。手順4の説明に従って、移行コマンドを実行すると、移行ツールによってSun Java System Access Manager管理パスワードの入力が求められます。

openSSOServerDebugLevel

次のいずれかの値を指定します。

- error

- message

この値はデバッグ・レベルを表します。

openSSOLDAPServerURL

LDAPサーバーのURLを指定します。これは次の形式で指定してください。

host:port

各項目は次のとおりです。

hostは、Sun Java System Access Manager 7.1で使用される構成ストアのLDAPホストを表します。

portは、Sun Java System Access Manager 7.1で使用される構成ストアのLDAPポートを表します。

hostおよびportの値はコロンで区切る必要があります。

openSSOLDAPBindDN

LDAPサーバーのバインドDNを指定します。Sun Java System Access Managerの構成ディレクトリ・サーバーの管理権限またはルート権限が必要です。

openSSOLDAPBindPwd

このプロパティの値を指定しないでください。手順4の説明に従い、移行コマンドを実行すると、移行ツールによってLDAPバインド・パスワードの入力が求められます。

openSSOLDAPSearchBase

構成ストアのLDAP検索ベースを指定します。

openSSOMigrationMode

このプロパティに次のいずれかの値を設定して、移行のモードを指定します。

- Complete
完全移行を実行する場合、この値を設定します。

- Incremental
増分移行を実行する場合、この値を設定します。増分移行は、openSSOSMIncludeFilePathおよびopenSSOSMExcludeFilePathプロパティによって決まります。

- Delta
デルタ移行を実行する場合、この値を設定します。

このプロパティに値を指定しなかった場合は、完全移行が実行されます。また、値CompleteまたはIncrementalに誤りがあった場合、移行モードはCompleteとみなされ、完全移行が実行されます。

これらの値では、大/小文字が区別されます。

移行のモードの詳細は、「移行のモード」を参照してください。

openSSOSMIncludeFilePath

増分移行を実行する場合、Sun Java System Access Manager 7.1の一部のエージェントおよびポリシーを移行に含めるには、openSSOSMIncludeFilePathプロパティを使用する必要があります。

openSSOSMIncludeFilePathプロパティの値は、移行に含めるエージェントおよびポリシーのフラグがYに設定されているIncrementalMigrationIncludeFile.txtの絶対パスである必要があります。IncrementalMigrationIncludeFile.txtファイルの詳細は、「増分移行のための追加手順」を参照してください。

openSSOSMIncludeFilePathプロパティを指定して増分移行を実行する場合は、openSSOSMExcludeFilePathプロパティをコメント・アウトします。

増分移行の実行時にopenSSOSMIncludeFilePathとopenSSOSMExcludeFilePathの両方のプロパティを指定した場合、openSSOSMIncludeFilePathプロパティがopenSSOSMExcludeFilePathプロパティより優先され、openSSOSMExcludeFilePathプロパティは無視されます。

完全移行の場合、このプロパティは無視してください。

openSSOSMExcludeFilePath

増分移行を実行する場合、Sun Java System Access Manager 7.1の一部のエージェントおよびポリシーを移行から除外するには、openSSOSMExcludeFilePathプロパティを使用する必要があります。

openSSOSMExcludeFilePathプロパティの値は、移行から除外するエージェントおよびポリシーのフラグがYに設定されているIncrementalMigrationIncludeFile.txtの絶対パスである必要があります。IncrementalMigrationIncludeFile.txtファイルの詳細は、「増分移行のための追加手順」を参照してください。

openSSOSMExcludeFilePathプロパティを指定して増分移行を実行する場合は、openSSOSMIncludeFilePathプロパティをコメント・アウトします。

増分移行の実行時にopenSSOSMExcludeFilePathとopenSSOSMIncludeFilePathの両方のプロパティを指定した場合、openSSOSMIncludeFilePathプロパティがopenSSOSMExcludeFilePathプロパティより優先され、openSSOSMExcludeFilePathプロパティは無視されます。

完全移行の場合、このプロパティは無視してください。

注意:

openSSOAdminPasswordおよびopenSSOLDAPBindPwdプロパティの値を指定しないでください。

openSSOSMExcludeFilePathまたはopenSSOSMExcludeFilePathで指定したファイル・パスが正しくない場合や、指定したファイル・パスが権限の問題のために読取り可能でない場合、該当するエラー・メッセージが表示されます。これをログ・ファイルで確認することもできます。

増分移行を実行する際にIncrementalMigrationIncludeFile.txtファイルが空の場合は、モードがCompleteに変更され、完全移行が実行されます。

6.13 Sun Java System Access Manager 7.1のアーティファクトのOAM 11.1.2.2.0への移行

Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0にアーティファクトを実際に移行する前に、評価レポートを生成して(第6.9項「評価レポートの生成」を参照)、Access Manager 11.1.2.2.0にどのアーティファクトを移行できるかを分析したことを確認します。

Sun Java System Access Manager 7.1をAccess Manager 11.1.2.2.0に移行するには、次の手順を実行します。

1. 増分移行を実行する場合は、第6.11項「増分移行のための追加手順」に記載されている追加手順を実行していることを確認します。

2. 第6.12項「プロパティ・ファイルの作成」の説明に従ってプロパティ・ファイルを作成していることを確認します。

3. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME/common/binディレクトリに移動します。
cd IAM_HOME/common/bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
./wlst.sh

Windowsの場合:

1. コマンド行で次のコマンドを実行し、現在の作業ディレクトリからIAM_HOME\common\binディレクトリに移動します。
cd IAM_HOME\common\bin

2. 次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
wlst.cmd

4. 次のコマンドを実行して、WLSTをWebLogic Serverインスタンスに接続します。

connect('wls_admin_username','wls_admin_password','t3://hostname:port');

このコマンドでは、次のように指定します。

wls_admin_usernameは、WebLogic管理サーバーのユーザー名です。

wls_admin_passwordは、WebLogic管理サーバーのパスワードです。

hostnameは、WebLogic管理サーバーが動作しているマシンです。

portは管理サーバーのポートです。

5. 次のコマンドを実行して、Sun Java System Access Manager 7.1のアーティファクトをAccess Manager 11.1.2.2.0に移行します。

oamMigrate(oamMigrateType="OpenSSO",pathMigrationPropertiesFile="<absolute_path_of_properties_file>");

各項目は次のとおりです。

<absolute_path_of_properties_file>は、手順1で作成したプロパティ・ファイルの絶対パスです。次に例を示します。

UNIXの場合: oamMigrate(oamMigrateType="OpenSSO",pathMigrationPropertiesFile="abc/def/oam_migration.properties"

Windowsの場合: oamMigrate(oamMigrateType="OpenSSO",pathMigrationPropertiesFile="abc\\def\\oam_migration.properties

次の入力が求められます。

1. Enter value for property : openSSOAdminPassword :
Sun Java System Access Manager 7.1管理サーバーのパスワードを入力します。

2. Enter value for property : openSSOLDAPBindPwd :
LDAPサーバーへのバインド・パスワードを入力します。

注意:

初めてoamMigrate()コマンドを実行すると、完全移行が行われます。

最初の移行(完全移行)後、このコマンドを再実行してデルタ移行を行うことができます。

完全移行とデルタ移行の詳細は、第6.2項「移行のモード」を参照してください。

移行が完了すると、WLSTコンソールには、移行の結果を示すメッセージが表示されます。

6.14 移行後タスクの実行

Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0に移行した後、次の移行後のタスクを完了する必要があります。

1. 移行ツールは、次の場所にAMAgent.propertiesファイルを作成します。
<domain_home>/<domain_name>/output/OpenSSOMigration/AM7.1/<realm_name>/<agent_name>/AMAgent.properties

AMAgent.propertiesファイルで、@DEBUG_LOGS_DIR@タグをエージェント・ホスト上のデバッグ・ログの有効なディレクトリ・パスに置き換える必要があります。これを行うには、次の手順を実行します。

1. AMAgent.propertiesファイルを開きます。

2. プロパティcom.sun.am.policy.agents.config.local.log.file =@DEBUG_LOGS_DIR@/amAgentで、タグ@DEBUG_LOGS_DIR@を、エージェント・ホスト上のデバッグ・ログの有効なディレクトリ・パスに置き換えます。

2. エージェント・ホスト上にある既存のプロパティ・ファイルをバックアップして、新しく作成されたAMAgent.propertiesファイルをエージェント・ホストにコピーする必要があります。これを行うには、次の手順を実行します。

1. エージェントのWebコンテナ・インスタンスを停止します。

2. 既存のプロパティ・ファイル(移行プロセスを開始する前にエージェント・ホストに存在したプロパティ・ファイル)をバックアップします。

3. 新しく作成されたAMAgent.propertiesファイルを次の場所からエージェント・ホストにコピーします。
<domain_home>/<domain_name>/output/OpenSSOMigration/AM7.1/<realm_name>/<agent_name>/AMAgent.properties

4. エージェントのWebコンテナ・インスタンスを起動します。

この実行後、保護されているリソースにアクセスすると、ユーザーはAccess Manager 11.1.2.2.0サーバーにリダイレクトされ認証が行われます。

3. 移行ツールは、Sun Java System Access Manager 7.1からAccess Manager 11.1.2.2.0に移行されるユーザー・ストアのパスワードを取得しません。そのため、移行後は、移行されるすべてのユーザー・ストアのパスワードを手動で更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

ここで、hostはAccess Manager 11.1.2.2.0が動作しているマシンを表し、portはポート番号を表します。

2. 「起動パッド」タブに移動します。

3. 構成で、「ユーザー・アイデンティティ・ストア」をクリックします。存在するすべての移行されたLDAPユーザー・ストアのパスワードを手動で更新します。

4. 移行後、移行した認証ストアの最小および最大プール・サイズはデフォルトで0に設定されます。そのため、Oracle Access Management 11.1.2.2.0コンソールで認証ストアの「最小プール・サイズ」と「最大プール・サイズ」に適切な値を手動で設定する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

2. 「起動パッド」タブに移動します。

3. 構成で、「ユーザー・アイデンティティ・ストア」をクリックします。

4. 編集する認証ストアを選択します。

5. 「接続の詳細」にスクロール・ダウンして、「最小プール・サイズ」と「最大プール・サイズ」の値を設定します。たとえば、最小プール・サイズを10、最大プール・サイズを50にします。

6. 「適用」をクリックします。

5. 次の手順を実行して、Access Manager管理対象サーバーおよび移行したエージェントのWebインスタンスを再起動します。

1. 移行されているエージェントのWebコンテナ・インスタンスを停止します。

2. Access Manager管理対象サーバーを停止します。
管理対象サーバーの停止の詳細は、付録A「管理対象サーバーの停止」を参照してください。

3. Access Manager管理対象サーバーを起動します。
管理対象サーバーの起動の詳細は、付録A「管理対象サーバーの起動」を参照してください。

4. 移行されているエージェントのWebコンテナ・インスタンスを起動します。

6.15 移行の確認

移行を確認するには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Management 11.1.2.2.0コンソールをホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

Sun Java System Access Manager 7.1のエージェント(2.2エージェント)、ユーザー・ストア、認証ストア、認証モジュール、ホスト識別子、リソース、および正しい認証モジュールを備えた正しい認証スキームのポリシーがAccess Manager 11.1.2.2.0に移行されていることを確認します。

2. URLを使用して、保護されているページにアクセスします。このURLにより、Oracle Access Management 11.1.2.2.0サーバーの「ログイン」ページにリダイレクトされるようになっています。認証が成功すると、正常な認可が実行され、リソースに正常にアクセスできます。

7 Oracle Identity AnalyticsからOracle Identity Managerへの完了した証明の移行

この章では、クローズした証明をOracle Identity Analytics 11gリリース1 (11.1.1.5.0)からOracle Identity Manager 11gリリース2 (11.1.2.2.0)に移行する方法について説明します。

注意:

以前のバージョンのOracle Identity Analytics (たとえば、11gリリース1 (11.1.1.3.0)以前)を使用している場合、クローズした証明をOracle Identity Manager 11gリリース2 (11.1.2.2.0)に移行するために、最初にOracle Identity Analytics to 11gリリース1 (11.1.1.5.0)をアップグレードする必要があります。

この章には次の項が含まれます:

- 第7.1項「移行の概要」

- 第7.2項「移行ロードマップ」

- 第7.3項「移行の前提条件」

- 第7.4項「移行ツールの入手」

- 第7.5「Oracle Identity Analyticsインストールからのjarファイルのコピー」

- 第7.6項「データベース接続の詳細の指定」

- 第7.7項「クローズした証明の移行」

- 第7.8項「移行の確認」

7.1 移行の概要

クローズした証明のOracle Identity AnalyticsからOracle Identity Managerへの移行は、移行ツールを使用して実行できます。移行ツールは、Oracle Identity AnalyticsおよびOracle Identity Managerデータベースの両方に接続するプロパティ・ファイルに指定されているデータベース接続情報を使用して、Oracle Identity AnalyticsからOracle Identity Managerに証明データを移行します。

図7-1は、Oracle Identity Analytics 11gリリース1 (11.1.1.5.0)の移行のコンポーネント・アーキテクチャを示しています。

図7-1 Oracle Identity Analyticsの移行のコンポーネント・アーキテクチャ

クローズした証明をOracle Identity AnalyticsからOracle Identity Managerに移行するには、Oracle Identity AnalyticsおよびOracle Identity Managerの両方を実行している必要があります。移行ユーティリティを起動すると、移行ツールは、config.propertiesファイル(図7-1のConfiguration File)に指定されているデータベース接続情報を使用して、Oracle Identity AnalyticsおよびOracle Identity Managerデータベースに接続し、データを移行します。移行中に、Oracle Identity Analyticsデータベースの証明データが読み取られ、処理され、Oracle Identity Managerデータベースに書き込まれます。移行ツールは、ログ情報を含むoiadatamigration.logというログ・ファイルを生成します。移行が正常に完了すると、Oracle Identity Analyticsのすべての完了した証明は、Oracle Identity Managerダッシュボード経由で利用可能になります。

7.2 移行ロードマップ

表7-1は、クローズした証明をOracle Identity AnalyticsからOracle Identity Managerに移行するために完了する必要のあるタスクをリストしています。

表7-1 Oracle Identity AnalyticsからOracle Identity Managerにクローズした証明を移行するためのロードマップ

Sl番号

タスク

参照先

1

移行プロセスを開始する前に、前提条件を完了します。

「移行の前提条件」を参照してください。

2

移行ツール(oiaDataMigration.zip)を取得します。

「移行ツールの入手」を参照してください。

3

必要な.jarファイルをOracle Identity Analyticsインストールから、oiaDataMigration.zipファイルのコンテンツを抽出したフォルダのlibディレクトリにコピーします。

「Oracle Identity Analyticsインストールからのjarファイルのコピー」を参照してください。

4

config.propertiesファイルでOracle Identity AnalyticsおよびOracle Identity Managerのデータベース接続の詳細を指定します。

「データベース接続の詳細の指定」を参照してください。

5

移行ユーティリティを実行して、クローズした証明をOracle Identity AnalyticsからOracle Identity Managerに移行します。

「クローズした証明の移行」を参照してください。

5

移行ユーティリティによって生成されたログ・ファイルを確認して、移行を確認します。

「移行の確認」を参照してください。

7.3 移行の前提条件

クローズした証明をOracle Identity AnalyticsからOracle Identity Manager 11.1.2.2.0に移行する前に、次の前提条件を完了する必要があります。

- システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

- Oracle Identity Manager 11.1.2.2.0をインストールし、構成していることを確認してください。この移行を実行するには、Oracle Identity AnalyticsおよびOracle Identity Managerの両方を実行している必要があります。

7.4 移行ツールの入手

移行ツールキットは、oiaDataMigration.zipという名前のzipファイルとして利用できます。Oracle Supportに連絡して移行ツールを入手します。

oiaDataMigration.zipのファイルを任意の場所に抽出します。oiaDataMigration.zipフォルダには次のディレクトリが含まれています。

- config: このディレクトリには、config.propertiesというプロパティ・ファイルが含まれており、このファイルには、Oracle Identity AnalyticsおよびOracle Identity Managerのデータベース接続情報が含まれています。

- lib: これは、空のディレクトリです。Oracle Identity Analyticsインストールにある特定のjarファイルをこのディレクトリにコピーする必要があります。このフォルダにコピーする必要があるjarファイルのリストは、第7.5項「Oracle Identity Analyticsインストールからのjarファイルのコピー」に示されています。

- logs: このディレクトリには、移行ユーティリティで作成されたログ・ファイルが含まれています。

- oiaDataMigration.jar: これは、クローズした証明をOracle Identity AnalyticsからOracle Identity Managerに移行する、実行可能な移行ユーティリティです。

- readme.txt: このファイルには、リリースと移行ユーティリティの使用方法に関する情報が含まれています。

7.5 Oracle Identity Analyticsインストールからのjarファイルのコピー

次の.jarファイルを既存のOracle Identity Analyticsインストールから<unzipped_folder_of_oiaDataMigration.zip>/libにコピーします。

- aopalliance.jar

- commons-collections-3.1.jar*

- commons-collections-3.2.1.jar*

- commons-dbcp.jar*

- commons-logging-1.1.jar*

- commons-logging.jar*

- commons-pool-1.2.jar*

- commons-pool-1.3.jar*

- log4j-1.2.14.jar*

- ojdbc6.jar*

- spring-aop.jar

- spring-beans.jar

- spring-context.jar

- spring-core.jar

- spring-jdbc.jar

- spring-tx.jar

7.6 データベース接続の詳細の指定

移行ユーティリティを実行する前に、config.propertiesファイルでOracle Identity AnalyticsおよびOracle Identity Managerのデータベース接続の詳細を指定する必要があります。これを行うには、次の手順を実行します。

1. テキスト・エディタで<folder_where_you_unzipped_oiaDataMigration.zip>/config/のconfig.propertiesファイルを開きます。

2. 次のパラメータに適切な値を指定します。

- oia.jdbc.url: Oracle Identity AnalyticsのJDBC URLを指定します。

- oia.jdbc.username: Oracle Identity Analytics JDBCユーザー名を指定します。

- oim.jdbc.url: Oracle Identity Manager 11.1.2.2.0のJDBC URLを指定します。

- oim.jdbc.username: Oracle Identity Manager JDBCユーザー名を指定します。

- logging.level: 移行ユーティリティによって生成されたログ・ファイルに、使用する詳細のレベルを指定します。このパラメータに、次の値のいずれかを指定します。
- DEBUG - デバッグに関する情報にこの値を指定します。

- INFO - 一般情報にこの値を指定します。

- WARN - 警告メッセージにこの値を指定します。

- ERROR - エラー・メッセージにこの値を指定します。

プロパティ・ファイルの例:

#oia parameters

oia.jdbc.url = jdbc:oracle:thin:@$SERVER_NAME:$PORT:rbacx
oia.jdbc.username=oiadbuser

#oim paramters

oim.jdbc.url = jdbc:oracle:thin:@$SERVER_NAME:$PORT:oimdb
oim.jdbc.username=oimdbuser

# could be one of DEBUG,INFO,WARN,ERROR.
logging.level = WARN

3. config.propertiesファイルを保存します。

7.7 クローズした証明の移行

次の手順で移行ツールを実行して、クローズした証明をOracle Identity AnalyticsからOracle Identity Managerに移行します。

1. oiaDataMigration.zipのファイルを抽出した場所に移動します。

2. 次に示すoiaDataMigration.jarファイルを実行します。
java -jar oiaDataMigration.jar -<option>

このコマンドでは、<option>は、oiaDataMigration.jarコマンド(実行するタスクによって異なる)を実行するときに使用する必要のあるオプションを表します。表7-2は、oiaDataMigration.jarコマンドを実行中に使用できるオプションを示しています。

表7-2 oiaDataMigration.jarコマンドを実行中に使用するオプション

オプション

説明

例

-all

すべてのクローズした証明をOracle Identity AnalyticsからOracle Identity Manager 11.1.2.2.0に移行する場合、このオプションを使用します。

このオプションはオプション-rangeと互換性がありません。

java -jar oiaDataMigration.jar -all

-purge

Oracle Identity AnalyticsからOracle Identity Manager 11.1.2.2.0に移行されたすべての完了した証明データを削除する場合、このオプションを使用します。これは、Oracle Identity Managerから生成されたすべての証明データも削除します。

java -jar oiaDataMigration.jar -purge

-range start <MM/DD/YYYY> end <MM/DD/YYYY>

特定の期間の完了日の一連のクローズした証明を移行する場合、このオプションを使用します。このオプションを使用する場合、期間の開始日と終了日を指定する必要があります。

java -jar oiaDataMigration.jar -range start 01/01/2012 end 03/31/2012

-stats

Oracle Identity Analyticsの証明データとOracle Identity Managerの証明データを比較する場合、このオプションを使用します。

java -jar oiaDataMigration.jar -stats

-help

oiaDataMigration.jarコマンドの実行方法の詳細を確認する場合、このオプションを使用します。

java -jar oiaDataMigration.jar -help

3. 求められた場合、Oracle Identity AnalyticsおよびOracle Identity Managerデータベースのパスワードを指定します。

これにより、Oracle Identity AnalyticsからOracle Identity Managerにクローズした証明が移行されます。

7.8 移行の確認

移行が完了した後、次のように-statsオプションを使用し、再度移行ツールを実行して指定したデータが正常に移行されていることを確認してください。

java -jar oiaDataMigration.jar -stats

注意:

移行ツールの実行の詳細は、第7.7項「クローズした証明の移行」を参照してください。

出力には、各Oracle Identity Analyticsテーブルおよび各Oracle Identity Managerテーブルにあるレコードの数が表示されます。移行が成功した場合、各列の値は等しくなります。

<folder_where_you_unzipped_oiaDataMigration.zip>/logs/に生成されるログ・ファイルoiadatamigration.logにエラーまたは警告がないか確認することもできます。

第III部

共存シナリオ

次の章で構成されています。

- 第8章「Oracle Access Manager 10gおよびOracle Access Management Access Manager 11.1.2.2.0の共存」

- 第9章「Sun OpenSSO Enterprise 8.0およびOracle Access Management Access Manager 11.1.2.2.0の共存」

- 第10章「Sun Java System Access Manager 7.1およびOracle Access Management Access Manager 11.1.2.2.0の共存」

8 Oracle Access Manager 10gとOracle Access Management Access Manager 11.1.2.2.0の共存

この章では、Oracle Access Manager 10gをOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.2.0)のデプロイメントが共存する環境を設定する方法について説明します。

この章には次の項が含まれます:

- 第8.1項「共存の概要」

- 第8.2項「共存の機能」

- 第8.3項「共存のトポロジ」

- 第8.4項「タスク・ロードマップ」

- 第8.5項「共存の前提条件」

- 第8.6項「オプション: Oracle HTTP Server 11g (OHS-1)のインストールと構成」

- 第8.7項「オプション: WebGate 11g-1のインストールと構成」

- 第8.8項「オプション: WebGate 10gのインストールと構成」

- 第8.9項「Access Manager 11.1.2.2.0サーバーの共存モードの有効化」

- 第8.10項「ログアウト設定の構成」

- 第8.11項「構成の確認」

- 第8.12項「共存の機能の無効化」

- 第8.13項「既知の問題」

8.1 共存の概要

一部のアプリケーションはOracle Access Manager 10gで保護され、その他のアプリケーションはAccess Manager 11.1.2.2.0で保護されるように、Oracle Access Manager 10gおよびAccess Manager 11.1.2.2.0の両方のデプロイメントを共存させることができます。これを共存モードと呼び、Oracle Access Manager 10gおよびAccess Manager 11.1.2.2.0の両方のデプロイメントが共存します。

共存モードでは、Access Manager 11.1.2.2.0は、移行されたアプリケーション、およびAccess Manager 11.1.2.2.0に登録された新しいアプリケーションを保護し、Oracle Access Manager 10gは、Access Manager 11.1.2.2.0に移行されていないアプリケーションを引き続き保護します。

エンドユーザーは、Oracle Access Manager 10gで保護されるアプリケーションとAccess Manager 11.1.2.2.0で保護されるアプリケーションの間を移動する際に、シームレスなシングル・サインオン(SSO)を利用できます。

8.2 共存の機能

図8-1は、Oracle Access Manager 10gサーバーとAccess Manager 11.1.2.2.0サーバーの共存を示しています。Resource Aは、Access Manager 11g WebGateで保護され、他のリソースは、Oracle Access Manager 10g WebGateで保護されます。Oracle Access Manager 10gサーバーまたはAccess Manager 11.1.2.2.0サーバーのいずれかと連携するようにOracle Access Manager 10g WebGateを構成したり、Access Manager 11.1.2.2.0サーバーのみと連携するようにAccess Manager 11g WebGateを構成することができます。

図8-1 Oracle Access Manager 10gとAccess Manager 11.1.2.2.0の共存

「図8-1 Oracle Access Manager 10gとAccess Manager 11.1.2.2.0の共存」の説明

- Oracle Access Manager 10gとAccess Manager 11.1.2.2.0サーバーは、それらにルーティングされるすべての認証リクエストと認可リクエストを、相互に依存せず独立して処理できます。

- 共存している間、すべての認証スキームとポリシーは維持されます。これは、Oracle Access Manager 10gで保護されている既存のアプリケーションおよびAccess Manager 11.1.2.2.0プラットフォームで保護されている移行されたアプリケーションのいずれにも適用されます。たとえば、アプリケーションがX509認証スキームで保護されている場合、これは、共存している間Access Manager 11.1.2.2.0プラットフォームのX509認証スキームでも保護されます。

- Access Manager 11.1.2.2.0サーバーで認証されているユーザーは、Oracle Access Manager 10gサーバーで保護されている各リソースにアクセスする場合、資格証明を再度入力する必要がなく、その逆も同様です。これにより、ユーザーにシームレスなシングル・サインオン(SSO)が提供されます。ユーザーは、Oracle Access Manager 10gで保護されているResource Bにアクセスすると、Access Manager 11.1.2.2.0で保護されているResource Aに、再度ユーザー資格証明を入力せずにアクセスできます。

- 1ユーザーにつき1セッションしか作成されないため、共存モードでセッション管理機能を使用することはできません。

- ユーザーがいずれかのサーバーからログアウトした場合、セッションは終了し、ユーザーはAccess Manager 11.1.2.2.0とOracle Access Manager 10gサーバーの両方からログアウトされます。ユーザーは、再認証した場合のみ、保護されているリソースにアクセスできます。

- 共存モードでは、ユーザーは、Access Manager 11.1.2.2.0の認証に関連するすべての機能および拡張機能を利用できます。Oracle Access Manager 11.1.2.2.0の機能拡張の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management 11.1.2.2.0の製品拡張機能に関する説明を参照してください。

- すべての保護されているリソースの認証レベルは、認証スキームに関係なく同じである必要があります。図8-1では、Resource A、BおよびCの認証レベルは同じである必要があり、同じでない場合、ユーザーは、異なる認証レベルを持つリソースへのアクセスを試みるときに、再度資格証明を入力する必要があります。

- 共存モードでは、複数のデータ・センター(MDC)全体でSSOを有効化するために、Access Manager 11gサーバーに必要な設定はありません。ユーザー認証のソースとして、Access Manager 11gサーバーとOracle Access Manager 10gサーバーの両方で生成されるObSSOCookieが使用されます。Cookieの検証のみが、有効なユーザー・セッションの条件である共存モードでは、プレーン10g MDCモードがサポートされています。ユーザー・セッションが任意のデータ・センターにない場合、それ以外のデータ・センターに既存のセッションがあるかどうかに関係なく新しいセッションが作成されます。MDCのデプロイメントの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の複数のデータ・センターの使用に関する説明を参照してください。

8.2.1 資格証明コレクションについて

Access Manager 11.1.2.2.0サーバーは、認証プロセス時の資格証明コレクションに、2つのメカニズムを提供します。

- 埋込み資格証明コレクタ(ECC)。デフォルトのECCは、Access Managerサーバーによってインストールされ、その他のインストールや設定手順を行うことなくそのまま使用できます。ECCを使用したユーザー資格証明の収集および処理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOAMエージェントおよびECCを使用したSSOログイン処理に関する説明を参照してください。

- 個別の外部資格証明コレクタ(DCC)およびリソースWebGate。これは、アプリケーションを保護するWebGateが、一元化されたDCCとは別に独立的に管理されている分散デプロイメントです。リソースを保護するリソースWebGateは、ユーザー・リクエストをDCC対応11g WebGateにリダイレクトして認証します。DCCを使用したユーザー資格証明の収集および処理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOAMエージェントおよびDCCを使用したログイン処理に関する説明を参照してください。

表8-1は、Access Manager 11.1.2.2.0サーバーに登録されているWebGate 11gおよびWebGate 10gが共存モードの資格証明コレクションに使用するメカニズムの比較を示しています。

表8-1 比較: Access Manager 11gのWebGate 11gとWebGate 10g

11g WebGate

10g WebGate

ECC

資格証明の収集にECCをサポートしていません。

資格証明の収集にECCをサポートしています。

DCC

共存モードで動作するためにDCCが有効化された11g WebGateが必要で、これは11gリソースWebGateから独立しています。

ECCまたはDCCが有効化された11g WebGateが必要です。

表8-2は、10gおよび11gデプロイメントでWebGate 10gが資格証明の収集に使用するメカニズムの比較を示しています。11g Access Managerデプロイメントで操作するための10g WebGateのインストールと10g Oracle Access Managerデプロイメントでの10g WebGateのインストールの違いの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の表23-1 10g WebGateのインストールの比較を参照してください。

表8-2 比較: 11gデプロイメントと10gデプロイメントにおけるWebGate 10g

11gデプロイメントへの10g WebGate

10gデプロイメントへの10g WebGate

ログイン・フォーム

10g WebGateで提供される10gフォームは、Access Managerサーバーで使用できません。

Access Managerサーバーでの10g WebGateの使用方法や範囲は、リソースWebGate(認証用WebGateではなく、転送を行う側)と同様です。10g WebGateと11g OAMサーバーを使用する場合、10g WebGateは常に認証用WebGateとして機能する11g資格証明コレクタにリダイレクトされます。

10gデプロイメントで使用するために提供される10gフォームを使用できます。

8.3 共存のトポロジ

図8-1は、Oracle Access Manager 10gサーバーとAccess Manager 11.1.2.2.0サーバーの共存を示しています。

トポロジは、Oracle Access Manager 10gとAccess Manager 11.1.2.2.0の非結合設定で構成され、ここでは、リソース、WebGateおよびサーバーが同じドメインにあります。

この共存設定の内容は次のとおりです。

- Access Manager 11.1.2.2.0サーバーに対して登録されたOracle Access Manager 10gのWebGateパートナ。共存を有効にするには、11g Access ManagerのDCCまたはECCにOracle Access Manager 10g WebGateを構成します。

- Oracle Access Manager 10gサーバーに対して登録されたOracle Access Manager 10gのWebGateパートナ。

- Access Manager 11.1.2.2.0サーバーに対して登録されたAccess Manager 11gのWebGateパートナ。

トポロジの説明

- WebGate 11g-1: Access Manager 11.1.2.2.0サーバーに登録された11gのWebGateパートナを表します。これは、OHS-1というOracle HTTP Server 11gにデプロイされます。WebGate 11g-1は、Resource A (Access Manager 11.1.2.2.0サーバーにインストールされているアプリケーション)を保護し、11g WebGateは、Access Manager 11.1.2.2.0サーバーのみと連携します。11g WebGateを有効化して、共存モードで動作させるには、11g WebGateが外部資格証明コレクタ(DCC)と連携するように構成する必要があります。

- WebGate 11g-2: 外部資格証明コレクタ(DCC)として構成されている11g WebGateを表します。外部資格証明コレクタ(DCC)として機能するように構成された11g WebGateは、認証WebGateと呼ばれます。その他の11g WebGateおよびリソースを保護するWebGate 11g-1は、リソースWebGateと呼ばれます。WebGate 11g-1およびWebGate 11g-2は、共存モードで別々のDCCおよびリソースWebGateとして同時に動作します。
リソースWebGateは、Access Manager 11.1.2.2.0サーバーと直接通信しません。Access Manager 11.1.2.2.0サーバーは、リソースWebGateからリクエストを受信し、認証リクエストをDCCにリダイレクトします。DCCは、セッションのObSSOCookieを設定し、これは、Access Manager 11.1.2.2.0サーバーおよびOracle Access Manager 10gサーバーの両方で使用されます。11g WebGateを別々のDCCおよびリソースWebGateとして構成する方法の詳細は、『Oracle Fusion Middleware Oracle Access Management管理ガイド』のDCCのための11g WebGateおよび認証ポリシーの構成に関する説明を参照してください。

- WebGate 10g-1: Access Manager 11.1.2.2.0サーバーに登録されたOracle Access Manager 10gのWebGateパートナを表します。これは、OHS-2というOracle HTTP Server 11gにデプロイされます。WebGate 10g-1は、Resource C (Access Manager 11.1.2.2.0サーバーにインストールされているアプリケーション)を保護します。

- WebGate 10g-2: Oracle Access Manager 10gサーバーに登録されたOracle Access Manager 10gのWebGateパートナを表します。これは、OHS-3というOracle HTTP Server 11gにデプロイされます。WebGate 10g-2は、Resource B (Oracle Access Manager 10gで保護されているアプリケーション)を保護します。

- ユーザー・アイデンティティ・ストア: Access Manager 11.1.2.2.0サーバーおよびOracle Access Manager 10gサーバーを、同じユーザー・アイデンティティ・ストアを共有するように構成すると、いずれのサーバーも、ユーザー・リクエストに存在するObSSOCookieを確認して更新できます。

次のシナリオは、ユーザーがAccess Manager 11.1.2.2.0サーバーおよびOracle Access Manager 10gサーバーで保護されているリソースにアクセスするときの、共存モードのSSOの動作について説明しています。

- 第8.3.1項「10g WebGateおよびOracle Access Manager 10gで保護されているリソースへのアクセスおよび10g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス」

- 第8.3.2項「11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセスおよび10g WebGateおよびAccess Manager 10gで保護されているリソースへのアクセス」

- 第8.3.3項「10g WebGateおよびAccess Manager 10gで保護されているリソースへのアクセスおよび11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス」

- 第8.3.4項「10g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセスおよび11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス」

8.3.1 10g WebGateおよびOracle Access Manager 10gで保護されているリソースへのアクセスおよび10g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス

共存モードでは、ユーザーがすでにOracle Access Manager 10gサーバーで認証されている場合、Access Manager 11.1.2.2.0サーバーは、Access Manager 10gサーバーで設定されているObSSOCookieを使用し、統合セッションを作成します。そのため、ユーザーは資格証明を再度入力する必要はありません。

図8-2は、ユーザーが、Oracle Access Manager 10gサーバーに対して登録されているWebGate 10g-2で保護されているResource Bにアクセスし、次にAccess Manager 11.1.2.2.0サーバーに対して登録されているWebGate 10g-1で保護されているResource Cにアクセスするときの、SSOの共存モードでの動作を示しています。

図8-2 ユーザーが、10g WebGateおよびOracle Access Manager 10gで保護されているResource Bにアクセスし、次に10g WebGateおよびAccess Manager 11gで保護されているResource Cにアクセスを試みる

「図8-2 ユーザーが、10g WebGateおよびOracle Access Manager 10gで保護されているResource Bにアクセスし、次に10g WebGateおよびAccess Manager 11gで保護されているResource Cにアクセスを試みる」の説明

表8-3は、リクエスト・フローの説明です。手順列の数字は、図8-2のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。

表8-3 リクエスト・フロー

手順

説明

1

次のURLで、Oracle Access Manager 10gサーバーによって保護されるResource-Bへのアクセスをリクエストします。

http://OHS-3:port/ResourceB

OHS-3は、Oracle HTTP Server 10g (OHS-3)のホスト名、portは、OHS-3が動作するマシンのポート番号です。

2

OHS-3にデプロイされるWebGate 10g-2は、リクエストをインターセプトし、ユーザーを認証するために、Oracle Access Manager 10gサーバーと通信します。

3

WebGate 10g-2は、資格証明を収集するログイン・フォームにユーザーをリダイレクトします。

4および5

ユーザーが資格証明を入力すると、WebGate 10g-2はOracle Access Manager 10gサーバーと通信し、認証に続いて認可を行います。認可が終わると、Oracle Access Manager 10gサーバーは、ポリシー構成に従って、関連するすべてのヘッダーとObSSOCookieをWebGate 10g-2に提供します。WebGate 10g-2は、ユーザーのブラウザにObSSOCookieを設定します。

6

次のURLで、Access Manager 11.1.2.2.0サーバーによって保護されるResource-Cへのアクセスをリクエストします。

http://OHS-2:port/ResourceC

OHS-2は、Oracle HTTP Server 11g (OHS-2)のホスト名、portは、OHS-2が動作するマシンのポート番号です。

リクエストには、WebGate 10g-2によってヘッダーに設定されたObSSOCookieが含まれています。

7-8

Access Manager 11.1.2.2.0サーバーは、ポリシー構成に従って、ObSSOCookieを確認し、ユーザーを認可し、統合セッションを作成し、WebGate 10g-1にリフレッシュされたObSSOCookieを送信します。

8.3.2 11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセスおよび10g WebGateおよびAccess Manager 10gで保護されているリソースへのアクセス

図8-3は、ユーザーが、Access Manager 11.1.2.2.0サーバーで保護されているResource Aにアクセスし、次にOracle Access Manager 10gサーバーで保護されているResource Bにアクセスするときの、SSOの共存モードでの動作を示しています。

図8-3 ユーザーが、11g WebGateおよびOracle Access Manager 11gサーバーで保護されているResource Aにアクセスし、次に10g WebGateおよびOracle Access Manager 10gサーバーで保護されているResource Cにアクセスを試みる

「図8-3 ユーザーが、11g WebGateおよびOracle Access Manager 11gサーバーで保護されているResource Aにアクセスし、次に10g WebGateおよびOracle Access Manager 10gサーバーで保護されているResource Cにアクセスを試みる」の説明

表8-4は、リクエスト・フローの説明です。手順列の数字は、図8-3のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。

表8-4 リクエスト・フロー

手順

説明

1

次のURLで、Access Manager 11.1.2.2.0サーバーによって保護されるResource-Aへのアクセスをリクエストします。

http://OHS-1:port/ResourceA

OHS-1は、Oracle HTTP Server 11g (OHS-1)のホスト名、portは、OHS-1が動作するマシンのポート番号です。

2

OHS-1にデプロイされるWebGate 11g-1は、リクエストをインターセプトし、認証スキームを取得するためにAccess Manager 11.1.2.2.0サーバーと通信します。

3

Access Manager 11.1.2.2.0サーバーは、外部資格証明コレクタ(DCC)にリクエストをリダイレクトし、これによりログイン・ページにスローされます。DCCは、ユーザーが認証のために入力した資格証明を収集して処理します。

4-5

ユーザーが資格証明を入力すると、外部資格証明コレクタはAccess Manager 11.1.2.2.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.2.0サーバーは、ポリシー構成に従って、関連するすべてのヘッダーとObSSOCookieをWebGate 11g-1に提供します。ObSSOCookieがOracle Access Manager 10gサーバー仕様に従って生成され、WebGate 11g-1は、ユーザーのブラウザにObSSOCookieを設定します。

6

次のURLで、Oracle Access Manager 10gサーバーによって保護されるResource-Bへのアクセスをリクエストします。

http://OHS-2:port/ResourceB

OHS-2は、Oracle HTTP Server 10g (OHS-2)のホスト名、portは、OHS-2が動作するマシンのポート番号です。

リクエストには、WebGate 11g-1によってヘッダーに設定されたObSSOCookieが含まれています。

7-8

Oracle Access Manager 10gサーバーは、ポリシー構成に従ってObSSOCookieを復号化して検証し、ユーザーを認可して、WebGate 10g-2にリフレッシュされたObSSOCookieを送信します。

共存モードでは、Access Manager 11.1.2.2.0サーバーはユーザー・リクエストを資格証明コレクタにリダイレクトし、10gおよび11g WebGateの両方の資格証明を収集します。WebGate 11gおよびWebGate 10gが共存モードで資格証明を収集するために使用されるメカニズムの比較は、第8.2.1項「資格証明コレクションについて」を参照してください。

8.3.3 10g WebGateおよびAccess Manager 10gで保護されているリソースへのアクセスおよび11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス

図8-4は、ユーザーが、Oracle Access Manager 10gサーバーで保護されているResource Bにアクセスし、次にAccess Manager 11.1.2.2.0サーバーで保護されているResource Aにアクセスするときの、SSOの共存モードでの動作を示しています。

図8-4 ユーザーが、10g WebGateおよびAccess Manager 10gサーバーで保護されているResource Bにアクセスし、次に11g WebGateおよびAccess Manager 11gサーバーで保護されているResource Aにアクセスを試みる

「図8-4 ユーザーが、10g WebGateおよびAccess Manager 10gサーバーで保護されているResource Bにアクセスし、次に11g WebGateおよびAccess Manager 11gサーバーで保護されているResource Aにアクセスを試みる」の説明

表8-5は、リクエスト・フローの説明です。手順列の数字は、図8-4のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。

表8-5 リクエスト・フロー

手順

説明

1

次のURLで、Oracle Access Manager 10gサーバーによって保護されるResource-Bへのアクセスをリクエストします。

http://OHS-3:port/ResourceB

OHS-3は、Oracle HTTP Server 10g (OHS-3)のホスト名、portは、OHS-3が動作するマシンのポート番号です。

2

OHS-3にデプロイされるWebGate 10g-2は、リクエストをインターセプトし、ユーザーを認証するために、Oracle Access Manager 10gサーバーと通信します。

3

WebGate 10g-2は、資格証明を収集するログイン・フォームにユーザーをリダイレクトします。

4および5

ユーザーが資格証明を入力すると、WebGate 10g-2はOracle Access Manager 10gサーバーと通信し、認証に続いて認可を行います。認可が終わると、Oracle Access Manager 10gサーバーは、ポリシー構成に従って、関連するすべてのヘッダーとObSSOCookieをWebGate 10g-2に提供し、これらはWebGateで設定されます。WebGate 10g-2は、ユーザーのブラウザにObSSOCookieを設定します。

6

次のURLで、Access Manager 11.1.2.2.0サーバーによって保護されるResource-Aへのアクセスをリクエストします。

http://OHS-1:port/ResourceA

OHS-1は、Oracle HTTP Server 11g (OHS-2)のホスト名、portは、OHS-1が動作するマシンのポート番号です。

リクエストには、WebGate 10g-2によってヘッダーに設定されたObSSOCookieが含まれています。

7

OHS-1にデプロイされるWebGate 11g-1は、リクエストをインターセプトし、認証スキームを取得するためにAccess Manager 11.1.2.2.0サーバーと通信します。

8

Access Manager 11.1.2.2.0サーバーは、リクエストをWebGate 10g-2によって設定されたObSSOCookieとともにDCCにリダイレクトします。

9-10

DCCはAccess Manager 11.1.2.2.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.2.0サーバーは、ポリシー構成に従って、更新されたObSSOCookieをWebGate 11g-1に送信します。

8.3.4 10g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセスおよび11g WebGateおよびAccess Manager 11gで保護されているリソースへのアクセス

図8-5は、ユーザーが、Access Manager 11.1.2.2.0サーバーで保護されているResource Cにアクセスし、次にAccess Manager 11.1.2.2.0 サーバーで保護されているResource Aにアクセスするときの、SSOの共存モードでの動作を示しています。

図8-5 ユーザーが、10g WebGateおよびAccess Manager 11gサーバーで保護されているResource Cにアクセスし、次に11g WebGateおよびAccess Manager 11gサーバーで保護されているResource Aにアクセスを試みる

「図8-5 ユーザーが、10g WebGateおよびAccess Manager 11gサーバーで保護されているResource Cにアクセスし、次に11g WebGateおよびAccess Manager 11gサーバーで保護されているResource Aにアクセスを試みる」の説明

表8-6は、リクエスト・フローの説明です。手順列の数字は、図8-5のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。

表8-6 リクエスト・フロー

手順

説明

1

次のURLで、Access Manager 11.1.2.2.0サーバーによって保護されるResource-Cへのアクセスをリクエストします。

http://OHS-2:port/ResourceC

OHS-2は、Oracle HTTP Server 10g (OHS-2)のホスト名、portは、OHS-2が動作するマシンのポート番号です。

2

OHS-2にデプロイされるWebGate 10g-1は、リクエストをインターセプトし、認証スキームを取得するためにAccess Manager 11.1.2.2.0サーバーと通信します。

3

Access Manager 11.1.2.2.0サーバーは、ECCまたはDCCにリクエストをリダイレクトし、これによりログイン・ページにスローされます。ECCまたはDCCは、ユーザーが認証のために入力した資格証明を収集して処理します。

4-5

ユーザーが資格証明を入力すると、ECCまたはDCCはAccess Manager 11.1.2.2.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.2.0サーバーは、ポリシー構成に従って、関連するすべてのヘッダーとObSSOCookieをWebGate 10g-1に提供します。WebGate 10g-1は、ユーザーのブラウザにObSSOCookieを設定します。

6

次のURLで、Access Manager 11.1.2.2.0サーバーによって保護されるResource-Aへのアクセスをリクエストします。

http://OHS-1:port/ResourceA

OHS-1は、Oracle HTTP Server 11g (OHS-1)のホスト名、portは、

OHS-1が動作するマシンのポート番号です。

リクエストには、WebGate 10g-1によってヘッダーに設定されたObSSOCookieが含まれています。

7

OHS-1にデプロイされるWebGate 11g-1は、リクエストをインターセプトし、認証スキームを取得するためにAccess Manager 11.1.2.2.0サーバーと通信します。

8

Access Manager 11.1.2.2.0サーバーは、リクエストをWebGate 10g-1によって設定されたObSSOCookieとともにDCCにリダイレクトします。

9

DCCはAccess Manager 11.1.2.2.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.2.0サーバーは、ポリシー構成に従って、更新されたObSSOCookieをWebGate 11g-1に送信します。

8.4 タスク・ロードマップ

表8-7は、図8-1に示されているトポロジの設定および構成手順を示しています。

表8-7 完了するタスク

タスク番号

タスク

参照先

1

構成プロセスを開始する前に、共存トポロジを理解して精通しておきます。

「共存のトポロジ」を参照してください。

2

前提条件を満たします。

「共存の前提条件」を参照してください。

3

Oracle HTTP Server 11gの新しいインスタンス(OHS-1)をインストールします。

Oracle HTTP Serverの新しいインスタンスをインストールしない場合、Oracle Access Manager 10g移行の一環で利用可能なOracle HTTP Serverインスタンスを使用できます。

「オプション: Oracle HTTP Server 11g (OHS-1)のインストールと構成」を参照してください。

4

新しい11g WebGateをインストールし、Access Manager 11.1.2.2.0サーバーおよびDCCと連携するように構成します。

WebGate 11g-1はOHS-1にデプロイされ、Access Manager 11.1.2.2.0サーバーで構成されます。

「オプション: WebGate 11g-1のインストールと構成」を参照してください。

5

既存の10g WebGateを使用するか、3つのWebGate: WebGate 10g-1およびWebGate 10g-2をインストールします。10gまたは11g WebGateをインストールできます。10g WebGateを、Access Manager 11.1.2.2.0サーバーまたはOracle Access Manager 10gサーバーと連携するように構成できます。11g WebGateを、Access Manager 11.1.2.2.0サーバーのみと連携するように構成できます。

WebGate 10g-1はOHS-2にデプロイされ、Access Manager 11.1.2.2.0サーバーで構成されます。

WebGate 10g-2はOHS-3にデプロイされ、Oracle Access Manager 10gサーバーで構成されます。このWebGateは10gのWebGateにします。

「オプション: WebGate 10gのインストールと構成」を参照してください。

6

Access Manager 11.1.2.2.0サーバーで共存モードを有効化します。

「Access Manager 11.1.2.2.0サーバーの共存モードの有効化」を参照してください。

7

WebGateとAccess Manager 11.1.2.2.0サーバーの両方でログアウトが機能するようにログアウト設定を構成します。

「ログアウト設定の構成」を参照してください。

8

構成を確認します。

「構成の確認」を参照してください。

8.5 共存の前提条件

次の前提条件を完了してから、Oracle Access Manager 10gサーバーとAccess Manager 11.1.2.2.0サーバーの共存に必要なタスクの実行を開始する必要があります。

1. システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

2. 使用しているOracle Access Manager 10gのリリースが共存をサポートしていることを確認します。Oracle Access Manager 10gとAccess Manager 11.1.2.2.0の共存がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。

3. Oracle Access Manager 10gおよびAccess Manager 11.1.2.2.0サーバーが起動して動作していることを確認します。

4. Access Manager 11.1.2.2.0でユーザー・アイデンティティ・ストアを構成します。ユーザー・アイデンティティ・ストアの構成の詳細は、第8.5.1項「Access Manager 11.1.2.2.0でのユーザー・アイデンティティ・ストアの構成」を参照してください。

5. Oracle Access Manager 10gサーバーと共存モードで実行するすべてのAccess Manager 11.1.2.2.0サーバーにJDK 6またはJDK 7をインストールします。

6. Oracle Technology Network Webサイト(http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html)からJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7をダウンロードして、jre/lib/securityフォルダにUS_export_policy.jarおよびlocal_policy.jarファイルを配置します。

8.5.1 Access Manager 11.1.2.2.0でのユーザー・アイデンティティ・ストアの構成

Access Manager 11.1.2.2.0にユーザー・アイデンティティ・ストアを構成する場合、次のタスクを完了する必要があります。

- Access Manager 11.1.2.2.0サーバーをデフォルトのストアとして設定します。

- Oracle Access Manager 10gおよびAccess Manager 11.1.2.2.0サーバーが同じユーザー・ストアを共有していることを確認します。

- 共有されているデータ・ストアをデフォルトのデータ・ストアとしてマークします。

- LDAP認証モジュールで共有されているデータ・ストアを選択します。

これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Managerコンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「構成」で、「ユーザー・アイデンティティ・ストア」をクリックします。

3. 場所またはホスト情報がAccess Manager 11.1.2.2.0サーバーを指すユーザー・アイデンティティ・ストアを作成します。ユーザー・アイデンティティ・ストアの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の新しいユーザー・アイデンティティ・ストアの登録に関する説明を参照してください。

4. 「ユーザー・アイデンティティ・ストア」ページで、「デフォルトとシステム・ストア」ストアから、作成したユーザー・アイデンティティ・ストアを選択します。

5. 「適用」をクリックします。

6. Oracle Access Managementの「起動パッド」で、Access Managerの「認証モジュール」をクリックします。認証モジュールのリストが表示されます。

7. 「LDAP」をクリックして、作成したユーザー・アイデンティティ・ストアを指すようにユーザー・アイデンティティ・ストアを更新します。

8. 「適用」をクリックします。

8.6 オプション: Oracle HTTP Server 11g (OHS-1)のインストールと構成

Oracle HTTP Server 11g(図8-1に示されているOHS-1)をインストールして構成します。あるいは、Oracle Access Manager 10gからAccess Manager 11.1.2.2.0への移行後に存在するOracle HTTP Serverインスタンスを使用できます。

詳細は、『Oracle Fusion Middleware WebGate for Oracle Access Managerのインストール』のOracle HTTP Server 11gのインストールと構成に関する項を参照してください。

Webサーバー: Oracle HTTP Server (OHS)、Oracle Traffic DirectorおよびApache 2に、11g WebGateをインストールできます。この章で検討するサンプル・トポロジでは、すべてのWebGateがOHSにインストールされているものとします。

8.7 オプション: WebGate 11g-1のインストールと構成

11g WebGateを共存モードで動作するように有効化するには、11g Resource WebGateを、個別のDCCおよびリソースWebGateとしてDCC対応の11g WebGateと連携するように構成する必要があります。

- リソースを保護する11g WebGateをインストールして、DCCと連携するように構成します。このWebGateは、リソースWebGateと呼ばれます。Access Manager 11.1.2.2.0サーバーは、リソースWebGateから受信する認証リクエストをDCCにリダイレクトして、認証を収集し処理します。図8-1に示すように、Oracle HTTP Server 11g (OHS-1)に11g WebGateの新しいインスタンスをインストールし、それをAccess Manager 11.1.2.2.0サーバーで構成します。11g WebGateのインストールとAccess Manager 11.1.2.2.0サーバーでの構成の詳細は、『Oracle Fusion Middleware WebGate for Oracle Access Managerのインストール』のOracle HTTP Server 11g WebGate for OAMのインストールと構成に関する説明を参照してください。

- 11g WebGateをインストールして、外部資格証明コレクタ(DCC)として機能するように構成します。このWebGateは、認証WebGateとも呼ばれます。11g WebGateを別々のDCCおよびリソースWebGateとして構成する方法の詳細は、『Oracle Fusion Middleware Oracle Access Management管理ガイド』のDCCのための11g WebGateおよび認証ポリシーの構成に関する説明を参照してください。

注意:

DCCは、ObSSOCookieを両方のWebGateに渡すことができるように、Oracle Access Manager 10gサーバーの認証WebGateと同じドメインにある必要があります。

8.8 オプション: WebGate 10gのインストールと構成

共存環境を設定するための既存の10g WebGateインスタンスを使用するか、新しい10g WebGateインスタンスをインストールできます。

新しいWebGateインスタンス(WebGate 10g-1とWebGate 10g-2)をインストールする場合、それらを次のように構成する必要があります。

- WebGate 10g-1: 図8-1に示すように、10g WebGateをOracle HTTP Server 11g (OHS-2)にインストールして、Access Manager 11.1.2.2.0サーバーで構成する必要があります。
10g WebGateのインストールとAccess Manager 11.1.2.2.0サーバーでの構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Manager 11gに対する最新の10g WebGateの検索とインストールに関する説明を参照してください。

10g WebGateとAccess Manager 11.1.2.2.0サーバーを使用すると、10g WebGateはリソースWebGateとして動作し、必ず認証WebGateとして機能する11g資格証明コレクタにリダイレクトします。10g WebGateを、Access Manager 11.1.2.2.0サーバーまたは外部資格証明コレクタ(DCC)として構成されている11g WebGateにインストールされているデフォルトの埋込み資格証明コレクタ(ECC)と連携するように構成できます。ECCおよびDCCの詳細は、『Oracle Fusion Middleware Oracle Access Manager管理者ガイド』のAccess Managerの資格証明コレクションとログインの概要に関する説明を参照してください。

- WebGate 10g-2: 図8-1に示すように、10g WebGateをOracle HTTP Server 11g (OHS-2)にインストールして、Oracle Access Manager 10gサーバーで構成する必要があります。
10g WebGateのインストールとOracle Access Manager 10gサーバーによる構成の詳細は、Oracle Access Managerインストレーション・ガイド(リリース10g (10.1.4.3))のWebGateのインストールに関する説明を参照してください。

Access Manager 11.1.2.2.0による10g WebGateの管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Manager 11gによる10g WebGateの管理に関する説明を参照してください。

注意:

Oracle Access Manager 10gサーバーまたはAccess Manager 11.1.2.2.0サーバーで構成されているすべての10g WebGateは、同じCookieドメインを持つ必要があり、同じドメインを持っていない場合は、WebGateから別のWebGateにObSSOCookieを渡すことができません。

8.9 Access Manager 11.1.2.2.0サーバーの共存モードの有効化

次のWebLogic Scripting Toolコマンドを実行して、Access Manager 11.1.2.2.0サーバーの各インスタンスを、Oracle Access Manager 10gサーバーで共存モードで実行するように構成します。

1. IAM_HOME/common/binから次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:

./wlst.sh

Windowsの場合:

wlst.cmd

2. 次のコマンドを実行して、WLSTをWebLogic Serverインスタンスに接続します。

connect('wls_admin_username','wls_admin_password','t3://hostname:port');

このコマンドでは、次のように指定します。

wls_admin_usernameは、WebLogic管理サーバーのユーザー名です。

wls_admin_passwordは、WebLogic管理サーバーのパスワードです。

hostnameは、WebLogic管理サーバーが動作しているマシンです。

portは、管理サーバーのポートです。

3. 次のコマンドを実行して、Oracle Access Manager 10gサーバーのユーザー・アイデンティティ・ストアの情報を指定し、ObSSOCookieドメインを設定します。

setCoexistenceConfigWith10G(ldapUrl="ldap://<hostname>:<port>/" , ldapPrinciple="cn=oamadmin" , ldapConfigBase="dc=com,dc=oracle,dc=us" , coexCookieDomain="");

このコマンドでは、次のように指定します。

ldapUrlは、Oracle Access Manager 10gデプロイメントで使用される構成ストアのLDAPホストおよびポートです。

ldapPrincipleは、構成ストアの管理者のLDAP DNです。

ldapConfigBaseは、Oracle Access Manager 10gデプロイメントの構成ストア用のLDAP検索ベースです。

coexCookieDomainは、10g認証WebGateのWebサーバーまたはWebGateドメインです。DCCによって設定されているObSSOCookieは、Oracle Access Manager 10gサーバーにフローする必要があるため、10g WebGateの認証ドメインを知っておくことが重要です。

例: setLdapConfigForCoexistenceWith10G(ldapUrl="ldap://<hostname>:<port>" , ldapPrinciple="cn=oamadmin", ldapPolicybase="dc=com,dc=oracle,dc=us", coexCookieDomain="")

LDAP管理者のパスワードを入力するように求められます。

4. LDAP管理者のパスワードを入力します。

5. 次のコマンドを実行して、Access Manager 11.1.2.2.0サーバーを、Oracle Access Manager 10gで共存モードで実行できるように構成します。

enableOamAgentCoexistWith10G()

6. Access Manager 11.1.2.2.0サーバーを再起動します。

7. 前述の手順を繰り返して、Access Manager 11.1.2.2.0サーバーの各インスタンスを、Oracle Access Manager 10gサーバーで共存モードで実行するように構成します。

8.10 ログアウト設定の構成

WebGate 10gは、logout.htmlファイルを使用してセッションをクリアします。WebGate 10g-1をAccess Manager 11.1.2.2.0サーバーで登録するときに生成されるlogout.htmlファイルを変更して、ファイルのSERVER_LOGOUTURLパラメータがAccess Manager 11.1.2.2.0サーバーのログアウトURLに指すように更新します。共存モードで構成されているAccess Manager 11.1.2.2.0サーバーは、リクエスト・ヘッダーから両方のCookie (OAMAuthnCookieおよびObSSOCookie)を削除します。

次の手順を実行して、WebGate 10g-1をAccess Manager 11.1.2.2.0サーバーで登録するときに生成されるlogout.htmlファイルを変更します。

1. logout.htmlファイルの変数SERVER_LOGOUTURLを、ログアウトURLに設定します。これは、次の例に示すように、OHS-2のホストとポートを指し示します。

var SERVER_LOGOUTURL="http://OHS-2_host:OHS-2_port/oam/server/logout"

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

OHS-2_hostは、OHS-2が動作しているホストです。

OHS-2_portはOHS-2のポートです。

2. オプション: ユーザーにログアウトURLへのアクセスを許可する場合、Oracle Access Manager 10gでポリシーを構成します。Oracle Access Manager 10gポリシーの作成の詳細は、Oracle Access Managerアクセス管理ガイド(リリース10g (10.1.4.3))のポリシー・ドメインによるリソースの保護に関する項を参照してください。

logout.htmlファイルを変更した後、WebGateおよびAccess Manager 11.1.2.2.0サーバーの両方でログアウトが機能することを確認してください。これを行うには、次の手順を実行します。

- 次のURLを使用して、リソースWebGate (WebGate 10g-1)からのログアウトを開始して確認します。

http://OHS-2_host:OHS-2_port/logout.html

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

OHS-2_hostは、OHS-2が動作しているホストです。

OHS-2_portはOHS-2のポートです。

WebGate 10g-1は、Access Manager 11.1.2.2.0サーバーのログアウトURLにリダイレクトします。そのため、WebGate 10g-1は、リクエストをAccess Manager 11.1.2.2.0サーバーに転送します。Access Manager 11.1.2.2.0サーバーは、すべてのセッションを消去します。

8.11 構成の確認

構成を確認するには、次の手順を実行します。

1. WebGate 10g-1によって保護されているリソースにログインしてアクセスします。

2. WebGate 10g-2またはWebGate 11g-1で保護されているリソースへのアクセスを試みます。サーバーが正常に共存モードで動作するように構成されると、ユーザー資格証明を再度入力しなくても、これらのWebGateで保護されているリソースにアクセスできるようになります。

3. ログアウトを開始し、リソースにアクセスして、すべてのWebGateからログアウトされるかどうかを確認します。リソースにアクセスする場合、ユーザー資格証明を再度入力するよう求められます。

8.12 共存の機能の無効化

Oracle Access Manager 10gサーバーのすべてのアーティファクトをAccess Manager 11.1.2.2.0サーバーに移行すると、Oracle Access Manager 10gサーバーを廃止して、共存モードのAccess Manager 11.1.2.2.0サーバーの実行を停止できます。Oracle Access Manager 10gアーティファクトの移行の詳細は、第2章「Oracle Access Manager 10g環境の移行」を参照してください。

1. IAM_HOME/common/binから次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:

./wlst.sh

Windowsの場合:

wlst.cmd

2. Access Manager 11.1.2.2.0サーバーで次のWLSTコマンドを実行して、Oracle Access Manager 10gによる共存モードのAccess Manager 11.1.2.2.0サーバーの実行を停止します。

disableOamAgentCoexistWith10G()

3. Access Manager 11.1.2.2.0サーバーを再起動します。

8.13 既知の問題

64ビットAESキーを使用するOracle Access Manager 10gサーバーは共存モードをサポートしていません。

共存モードでは、Access Manager 11.1.2.2.0サーバーは128ビット、192ビットまたは256ビットのAES鍵(JVMでサポートされている)を必要とします。Oracle Access Manager 10gサーバーをインストールする場合、暗号化のための256ビットAESキーがデフォルトで生成されます。アクセス・システム・コンソールでこのキーを再生成すると、64ビット・キーが生成されます。JVMは64ビットAESキーをサポートしていないため、Access Manager 11.1.2.2.0サーバーは、64ビットAESキーを使用するOracle Access Manager 10gサーバーで共存モードで動作することはできません。

この問題を回避するには、このAES鍵をLDAPから削除し、Oracle Access Manager 10gサーバーで256ビット鍵を再生成します。

AES鍵を削除するには、次の手順を実行します。

1. Oracle Access Manager 10gサーバーのLDAP構成を、LDAPブラウザで開きます。

2. 「Oblix」 > 「encryptionKey」 > 「cookieEncryptionKeyノード」 に移動します。

3. 「cookieEncryptionKeyノード」を右クリックし、「削除」をクリックします。鍵が削除されます。

256ビット鍵をOracle Access Manager 10gサーバーで再生成するには、次の手順を実行します。

1. Oracle Access Manager 10gサーバーおよびアイデンティティ・サーバーを再起動します。

2. 次のURLのリンクをクリックします。
http://host:port/identity/oblix

鍵が生成されます。生成された鍵をLDAPブラウザで表示できます。

3. Access Manager 11.1.2.2.0サーバーを再起動して共存モードを構成します。

9 Sun OpenSSO Enterprise 8.0とOracle Access Management Access Manager 11.1.2.2.0の共存

この章では、Sun OpenSSO Enterprise 8.0からOracle Access Management Access Manager 11.1.2.2.0に移行した後、Sun OpenSSO Enterprise 8.0 (OpenSSO Enterprise)とOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.2.0)のデプロイメントが共存する環境の設定方法について説明します。

この章には次の項が含まれます:

- 第9.1項「共存の概要」

- 第9.2項「共存のトポロジ」

- 第9.3項「タスク・ロードマップ」

- 第9.4項「共存の前提条件」

- 第9.5項「Agent-2を使用したAccess Manager 11.1.2.2.0サーバーのエンドポイントURLの保護」

- 第9.6項「Access Manager 11.1.2.2.0のデータ・ソースの構成」

- 第9.7項「Access Manager 11.1.2.2.0でのLDAPNoPasswordAuthModuleの更新」

- 第9.8項「Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成」

- 第9.9項「Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成」

- 第9.10項「Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更」

- 第9.11項「OpenSSO Enterprise 8.0サーバーでのAgent-2のプロファイルの更新」

- 第9.12項「ログアウト設定の構成」

- 第9.13項「構成の確認」

9.1 共存の概要

OpenSSO Enterprise 8.0からOracle Access Manager 11.1.2.2.0への移行プロセス時に、一部のアプリケーションはOpenSSO Enterprise 8.0で保護され、その他のアプリケーションはAccess Manager 11.1.2.2.0で保護されるようにOpenSSO Enterprise 8.0とAccess Manager 11.1.2.2.0の両方のデプロイメントを共存できます。エンドユーザーがこれらのアプリケーション間を移動する場合、シームレスなシングル・サインオンの経験があることが望まれます。これを共存モードと言います。

このモードでは、Access Manager 11.1.2.2.0は、移行したアプリケーションや、Access Manager 11gに登録された新しいアプリケーションを保護し、OpenSSO Enterprise 8.0は、Access Manager 11.1.2.2.0に移行されないアプリケーションを引き続き保護します。

この共存モードでは、OpenSSO Enterprise 8.0は、Access Manager 11.1.2.2.0で保護されるすべてのリソースの認証を行います。

9.2 共存のトポロジ

図9-1は、保護されたリソースへのアクセスをユーザーがリクエストした際にOpenSSO Enterprise 8.0サーバーで行われる認証を示しています。

図9-1 OpenSSO Enterprise 8.0とAccess Manager 11.1.2.2.0の共存

トポロジは、OpenSSO Enterprise 8.0とAccess Manager 11.1.2.2.0の非結合環境で構成されます。トポロジ内の数字1-8は、共存環境でリクエストがフローする順序を示しています。リクエスト・フローについては、「表9-2」を参照してください。

トポロジの説明

- Agent-1: Access Manager 11.1.2.2.0に登録されるOpenSSOエージェント(ポリシー・エージェント3.0)です。これはResource-1を保護します。

- Agent-2: OpenSSO Enterprise 8.0サーバーに登録されるOpenSSOエージェント(ポリシー・エージェント3.0)です。これは、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護します。このエージェントは、OpenSSO Enterprise 8.0サーバーで構成する必要があります。OpenSSO Enterprise 8.0サーバーでこのエージェント用のプロファイルを作成し、新しいポリシー・エージェント(3.0)を新規でインストールする必要があります。

- Agent-3およびAgent-4: OpenSSO Enterprise 8.0サーバーに登録されるOpenSSOエージェント(ポリシー・エージェント3.0)です。

- Resource-1: Access Manager 11.1.2.2.0サーバーと通信するAgent-1で保護されるリソースです。

- Policy-1: Resource-1を保護するためにAccess Manager 11.1.2.2.0サーバーで作成される認証ポリシーです。このポリシーは、「Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成」タスクの一環として作成されます。

- Policy-2: Agent-2で保護されるAccess ManagerのOpenSSOプロキシ・エンドポイント用にOpenSSO Enterprise 8.0サーバーで作成される認証ポリシーです。このポリシーは、「Agent-2を使用したAccess Manager 11.1.2.2.0サーバーのエンドポイントURLの保護」タスクの一環として作成されます。

表9-2は、リクエスト・フローの説明です。手順列の数字は、図9-1の数字と対応しています。

表9-1 リクエスト・フロー

手順

説明

1

Access Manager 11.1.2.2.0サーバーと通信するAgent-1で保護されるResource-1へのアクセスをリクエストします。

2

Agent-1は、Policy-1により、認証スキームOAM10gAuthSchemeを使用して、認証を行うためにユーザーをAccess Manager 11.1.2.2.0サーバー(…./opensso/UI/Login.....?goto=resource1)にリダイレクトします。OpenSSO Enterpriseサーバーで認証されたユーザーは、OpenSSOエージェントによってOAM_REMOTE_USERヘッダーで設定されます。したがって、Agent-1は認証スキームOAM10gAuthSchemeを使用して、ヘッダーOAM_REMOTE_USERからユーザーをアサートします。

3

Access Manager 11.1.2.2.0サーバーのエンドポイントは、OpenSSO Enterprise 8.0サーバーと通信するAgent-2で保護されます。

したがって、Agent-2は、Policy-2により、LDAP認証を行うためにユーザーをOpenSSO Enterprise 8.0サーバー(...opensso/UI/Login?goto=<…./oam/server/.....?goto=resource1>)にリダイレクトします。

4

OpenSSO Enterprise 8.0サーバーのLDAP認証モジュールによって、LDAPのユーザー名とパスワードの入力が求められます。ユーザーはLDAPの有効な資格証明を入力する必要があります。

5

OpenSSO Enterprise 8.0サーバーは、認証ストアと照らし合せてユーザーの資格証明を検証し、ユーザー・セッションをOpenSSO Enterprise 8.0セッションとして作成して、OpenSSO Enterprise 8.0のSSO cookie1をこのセッションIDで設定します。

6

OpenSSO Enterprise 8.0サーバーは、ユーザーをAccess Manager 11.1.2.2.0サーバー(…./opensso/UI/Login/.....?goto=resource1)にリダイレクトします。

7

Agent-2は、OpenSSOのセッションcookie1があるかどうかを確認することで、ユーザー・セッションとポリシー評価を検証します。セッション属性マッピングでヘッダーOAM_REMOTE_USERをuserIDに設定すると、Access Manager 11.1.2.2.0サーバー(…./opensso/UI/Login/.....?goto=resource1)へのアクセスが提供されます。

Access Manager 11.1.2.2.0サーバーは、手順2 (Policy-1)により、認証スキーム(OAM10gAuthScheme)を呼び出し、Resource-1に構成されるOAM10gSchemeを使用してヘッダーOAM_REMOTE_USERでユーザーをアサートします。

8

Access Manager 11.1.2.2.0サーバーは、Access Managerのセッションを作成してヘッダーを設定します。また、OAM_IDのCookieとOpenSSOのSSO cookie2 (OpenSSOプロキシ経由)も設定し、ユーザーをResource-1にリダイレクトします。OpenSSO Enterprise 8.0のSSO cookie2には、関連するOAM_ID Cookieへのリンクがあります。

Agent-1が、OpenSSOセッションcookie2とOAM_ID Cookieがあるかどうかを確認することでユーザー・セッションおよびポリシー評価を検証すると、ユーザーはResource-1にアクセスできます。

9.3 タスク・ロードマップ

表9-2に、共存環境の構成手順を示します。

表9-2 完了するタスク

タスク番号

タスク

参照先

1

構成プロセスを開始する前に、共存トポロジを理解して精通しておきます。

「共存のトポロジ」を参照してください。

2

前提条件を満たします。

「共存の前提条件」を参照してください。

3

OpenSSO Enterprise 8.0サーバーでAgent-2プロファイルを作成し、Agent-2をインストールします。oam-server.earファイルでWebアプリケーションngsso-web.warおよびopenssoproxy-urlmapper.warを更新します。

また、OpenSSO Enterprise 8.0で、Agent-2を使用してAccess Manager 11.1.2.2.0サーバーのエンドポイントURLを保護する認証ポリシーを作成します。

「Agent-2を使用したAccess Manager 11.1.2.2.0サーバーのエンドポイントURLの保護」を参照してください。

4

Access Manager 11.1.2.2.0のデータ・ソースを構成します。

「Access Manager 11.1.2.2.0のデータ・ソースの構成」を参照してください。

5

Access Manager 11.1.2.2.0で認証モジュールを更新し、第9.6項で構成されるデータ・ソースを示すようにユーザー・アイデンティティ・ストアを指定します。

「Access Manager 11.1.2.2.0でのLDAPNoPasswordAuthModuleの更新」を参照してください。

6

Access Manager 11.1.2.2.0でAgent-1のプロファイルを作成し、Access Manager 11.1.2.2.0サーバーを指す新しいポリシー・エージェント3.0 (Agent-1)をインストールします。

「Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成」を参照してください。

7

Access Manager 11.1.2.2.0サーバーで、Resource-1を保護する認証ポリシーを作成します。

「Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成」を参照してください。

8

Access Manager 11.1.2.2.0とOpenSSO Enterprise 8.0のCookie名が異なるように、Access Manager 11.1.2.2.0のデフォルトのCookie名を変更します。

「Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更」を参照してください。

9

OpenSSO Enterprise 8.0サーバーで、Agent-2のプロファイルを正しいセッション属性マッピングで更新します。

「OpenSSO Enterprise 8.0サーバーでのAgent-2のプロファイルの更新」を参照してください。

10

OpenSSO Enterprise 8.0サーバーとAccess Manager 11.1.2.2.0サーバーの両方からログアウトを開始するように、ログアウト設定を構成します。

「ログアウト設定の構成」を参照してください。

11

構成を確認します。

「構成の確認」を参照してください。

9.4 共存の前提条件

この章で説明するタスクの実行を開始する前に、次の前提条件を満たします。

- システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

- 使用しているOpenSSO Enterpriseのリリースが共存でサポートされていることを確認します。OpenSSO Enterprise 8.0の共存がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。

- Sun OpenSSO Enterprise 8.0とOracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)のインストールが完了し、サーバーが動作していることを確認します。
Oracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)のインストールと構成を行っていない場合、次のタスクを開始する前にこれらの作業を行う必要があります。Oracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)のインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.2.0)のインストールに関する説明およびOracle Access Managementの構成に関する説明を参照してください。

- OpenSSO Enterprise 8.0およびAccess Manager 11.1.2.2.0が同じユーザー・ストアを共有することを確認します。

- OpenSSO Enterprise 8.0サーバーおよびAccess Manager 11.1.2.2.0サーバーが異なるマシンで動作している場合は、これらのマシンの時刻が同期するようにします。

9.5 Agent-2を使用したAccess Manager 11.1.2.2.0サーバーのエンドポイントURLの保護

OpenSSO Enterprise 8.0でAgent-2のプロファイルを作成し、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護するポリシー・エージェント3.0を新規でインストールする必要があります。また、OpenSSO Enterprise 8.0サーバーでAccess Manager 11.1.2.2.0サーバーのエンドポイントURLを保護するためのポリシーも作成する必要があります。このためには、次のタスクを実行します。

1. OpenSSO Enterprise 8.0サーバーでのAccess Manager 11.1.2.2.0のAgent-2プロファイルの作成

2. Agent-2(ポリシー・エージェント3.0)のインストール

3. エージェント・フィルタ構成を含めるWebアプリケーションの更新

4. OpenSSO Enterprise 8.0サーバーでのAccess Manager 11.1.2.2.0の認証ポリシーの作成

9.5.1 OpenSSO Enterprise 8.0サーバーでのAccess Manager 11.1.2.2.0のAgent-2プロファイルの作成

(図9-1に示されているように)OpenSSO Enterprise 8.0サーバーでAgent-2プロファイルを作成します。手順は次のとおりです。

1. 次のURLを使用してOpenSSO Enterprise 8.0サーバーの管理コンソールにログインします。

http://host:port/opensso

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

- hostは、OpenSSO Enterprise 8.0コンソールをホストするマシンの完全修飾ドメイン名を表します。

- portは、OpenSSO Enterprise 8.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「アクセス制御」タブに移動します。

3. 「レルム」表で、「レルム名」列の一番上のレルムをクリックします。

4. 「エージェント」タブをクリックします。

5. OpenSSO Enterprise 8.0サーバーで作成および構成するエージェントのタイプに応じて、「Web」または「J2EE」タブをクリックします。

6. 「新規」をクリックして新しいAgent-2を作成し、「名前」、「パスワード」、「構成」、「サーバーURL」およびエージェントURLなどの必要な情報を入力します。

7. 「作成」をクリックします。

9.5.2 Agent-2(ポリシー・エージェント3.0)のインストール

Access Manager 11.1.2.2.0サーバーの前にAgent-2(ポリシー・エージェント3.0)をインストールします。これはWebLogicのJ2EEエージェントになります。

ポリシー・エージェント3.0の詳細は、Sun OpenSSO Enterpriseポリシー・エージェント3.0ガイド(Oracle WebLogic Server/Portal 10)を参照してください。

9.5.3 エージェント・フィルタ構成を含めるWebアプリケーションの更新

Access Manager 11.1.2.2.0サーバーをAgent-2で保護するには、Webアプリケーションngsso-web.warおよびopenssoproxy-urlapper.warを更新して、エージェント・フィルタ構成をweb.xmlファイルに含める必要があります。これを行うには、次の手順を実行します。

1. IAM_HOME/oam/server/apps/oam-server.earディレクトリからoam-server.earファイルを解凍して、内容を一時ディレクトリに抽出します。

2. ngsso-web.warファイル、web.xmlファイルの順に内容を抽出します。Access Manager 11.1.2.2.0サーバーをAgent-2で保護するには、web.xmlファイルを適切なエージェント・フィルタ構成で更新します。フィルタ定義をurl-patternのURL /server/opensso/login/*で更新します。
次に例を示します。

<filter>
<filter-name>Agent</filter-name>
<filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Agent</filter-name>
<url-pattern>/server/opensso/login/*</url-pattern>
</filter-mapping>

3. 同じ場所IAM_HOME/oam/server/apps/oam-server.earでopenssoproxy-urlmapper.warファイルの内容を抽出します。Access Manager 11.1.2.2.0サーバーをAgent-2で保護するには、web.xmlファイルを適切なエージェント・フィルタ構成で更新します。フィルタ定義をurl-patternのURL /UI/*で更新します。
次に例を示します。

<filter>
<filter-name>Agent</filter-name>
<filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Agent</filter-name>
<url-pattern>/UI/*</url-pattern>
</filter-mapping>

4. META-INF/MANIFEST.MFファイルは、oam-server.earファイルを再パッケージするコマンドの一部である必要があるため、oam-server.earファイルに元のMETA-INF/MANIFEST.MFファイルを再バンドルします。この手順を実行しない場合、標準MANIFEST.MFファイルが作成され、次の情報が失われます。

Manifest-Version: 1.0
Created-By: 2010-b01 (Sun Microsystems Inc.)
Release-Name: Oracle Access Manager 11g
Release Version: 11.1.2.0.0
Release-Label: NGAM_11.1.2.2.0_GENERIC_131223.0720
Specification-Version: 11.1.2.0.0
Implementation-Version: 11.1.2.0.0
Weblogic-Application-Version: 11.1.2.0.0
Extension-List: ipf
ipf_Extension-Name: oracle.idm.ipf

oam-server.earファイルを再バンドルするには、アーティファクトを変更する前にoam-server.earファイルを最初に解凍した場所から次のコマンドを実行します。

jar -cvfm oam-server.ear META-INF/MANIFEST.MF

注意:

元のoam-server.earファイルが上位ディレクトリに存在しないことを確認してください。再バンドルoam-server.earファイルを使用してファイルを再パッケージするとき、予期しない結果になる可能性があります。

5. com.sun.identity.agents.filter.AmAgentFilterクラスが含まれているjarファイルをWebLogic CLASSPATHに含めます。
9.5.2項「Agent-2 (ポリシー・エージェント3.0)のインストール」のWebLogic J2EEポリシー・エージェント3.0のインストール時に、一部のエージェントとともにダウンロードしたagent.jarファイルを使用できます。agent.jarファイルは、<directory_where_policy_agent_file_was_unzipped>/j2ee_agents/appserver_v9_agent/libにあります。

Weblogic Serverの開始引数 - CLASSPATH変数を変更して、oam-server.earファイルのデプロイ先サーバーにagents.jarファイルをロードします。CLASSPATHの変更の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンスのクラスパスの変更に関する項を参照してください。

6. 更新したngsso-web.warファイルとopenssoproxy-urlapper.warファイルを含めるようにoam-server.earファイルを再パッケージします。

7. 更新したoam-server.earファイルを再デプロイします。

9.5.4 OpenSSO Enterprise 8.0サーバーでのAccess Manager 11.1.2.2.0の認証ポリシーの作成

OpenSSO Enterprise 8.0サーバーで、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護する認証ポリシー(Policy-1)を作成する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOpenSSO Enterprise 8.0サーバーの管理コンソールにログインします。

http://host:port/opensso

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

- hostは、OpenSSO Enterprise 8.0コンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、OpenSSO Enterprise 8.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「アクセス制御」タブに移動します。

3. 「レルム」表で、「レルム名」列の一番上のレルムをクリックします。

4. 「ポリシー」タブをクリックします。

5. 新規ポリシーをクリックして、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護するための新しいポリシーの詳細を入力します。この場合、「ルール」はOAM_server_protocol://OAM_managed_server_host:OAM_managed_server_port/opensso/UI/Login*?*およびOAM_server_protocol://OAM_managed_server_host:OAM_managed_server_port/oam/server/opensso/login*にして、「サブジェクト」は認証されたユーザーにします。

6. 「OK」をクリックします。

9.6 Access Manager 11.1.2.2.0のデータ・ソースの構成

Access Manager 11.1.2.2.0のデータ・ソースを構成するには、次の手順を完了します。

1. 次のURLを使用してOracle Access Manager 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Managerコンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Managerコンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「システム構成」タブに移動します。

3. 「共通構成」を選択します。

4. 「データソース」を開き、「ユーザー・アイデンティティ・ストア」を選択します。

5. 「ユーザー・アイデンティティ・ストア」で、左パネルの上部にある「作成」アイコンをクリックして新しいデータ・ソースを作成します。このデータ・ソースのタイプは、「オープンLDAP」(OUD)にします。この新しいデータ・ソースに対してOpenSSO Enterprise 8.0のOpenDSのユーザー・ストアの詳細を指定する必要があります。

9.7 Access Manager 11.1.2.2.0でのLDAPNoPasswordAuthModuleの更新

LDAPNoPasswordAuthModuleは、Resource-1を保護するOAM10gSchemeで使用される認証モジュールです。

第9.6項でその「ユーザー・アイデンティティ・ストア」として作成したデータ・ソースを指し示すように認証モジュールLDAPNoPasswordAuthModuleを更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Managerコンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「システム構成」タブに移動します。

3. 「Access Manager」→「認証モジュール」を開きます。

4. 「LDAP認証モジュール」を開きます。

5. LDAPNoPasswordAuthModuleをクリックし、第9.6項で作成したデータ・ソースを指し示すように「ユーザー・アイデンティティ・ストア」を更新します。

9.8 Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成

Access Manager 11.1.2.2.0でAgent-1のプロファイルを作成し、Access Manager 11.1.2.2.0サーバーを指す新しいポリシー・エージェント3.0 (Agent-1)をインストールする必要があります。

Access Manager 11.1.2.2.0でのエージェントのプロファイルの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のコンソールを使用したOpenSSOポリシー・エージェントの登録と管理に関する項を参照してください。

ポリシー・エージェント3.0の詳細は、Sun OpenSSO Enterprise 8.0ドキュメント・ライブラリの各ガイドを参照してください。

9.9 Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成

Resource-1を保護する認証ポリシー(Policy-2)を、OAM10gSchemeという認証スキームで適切なアプリケーション・ドメインに作成します。

また、条件TRUEを指定してResource-1の認可ポリシーを作成します。構成されているリソースURLは、/および/.../*である必要があります。

認証および認可ポリシーの作成と管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のリソースの保護とSSOの有効化のためのポリシーの管理に関する項を参照してください。

9.10 Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更

Access Manager 11.1.2.2.0サーバーとOpenSSO Enterprise 8.0サーバー間でCookie名の競合が発生しないように、Access Manager 11.1.2.2.0サーバーでOpenSSO CookieのデフォルトのCookie名を変更する必要があります。これを行うには、次の手順を実行します。

1. Access Manager 11.1.2.2.0管理サーバーおよび管理対象サーバーを停止します。
管理サーバーおよび管理対象サーバーの停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の管理サーバーの起動と停止に関する項および管理対象サーバーの起動と停止に関する項を参照してください。

2. IAM_HOME/user_projects/domains/base_domain/config/fmwconfig/oam-config.xmlからoam-config.xmlファイルを開きます。

3. oam-config.xmlファイルでVersionパラメータの値を1増やします。

4. セクションopenssoproxyで、openssoCookieNameの値を、デフォルトのCookie名iPlanetDirectoryProから別の値(OAMOpenSSOCookieなど)に変更します。

5. Access Manager 11.1.2.2.0管理サーバーおよび管理対象サーバーを起動します。
管理サーバーおよび管理対象サーバーの起動の詳細は、『Oracle Fusion Middleware管理者ガイド』の管理サーバーの起動と停止に関する項および管理対象サーバーの起動と停止に関する項を参照してください。

6. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Managerコンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

7. 「システム構成」タブに移動します。

8. 「Access Manager」→「SSOエージェント」を開きます。

9. 「OpenSSOエージェント」を開きます。

10. 目的のAgent-1を選択し、手順4で使用した新しいCookie名(OAMOpenSSOCookieなど)を「Cookie名」フィールドで指定します。

11. Access Manager 11.1.2.2.0サーバーを再起動します。

9.11 OpenSSO Enterprise 8.0サーバーでのAgent-2のプロファイルの更新

Access Manager 11.1.2.2.0のポリシーをOpenSSO Enterprise 8.0サーバーで作成した後、Agent-2のプロファイル(タスク6で作成)をOpenSSO Enterprise 8.0サーバーで更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOpenSSO Enterprise 8.0サーバーの管理コンソールにログインします。

http://host:port/opensso

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

- <host>は、OpenSSO Enterprise 8.0コンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- <port>は、OpenSSO Enterprise 8.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「アクセス制御」タブに移動します。

3. 「レルム」表で、「レルム名」列の/(最上位のレルム)をクリックします。

4. 「エージェント」タブをクリックします。

5. Agent-2のタイプに応じて、「Web」または「J2EE」タブをクリックします。

6. Agent-2をクリックします。

7. 「アプリケーション」タブをクリックします。

8. セッション属性処理をクリックします。

9. セッション属性フェッチ・モードにHTTP_HEADERを選択します。

10. OAM_REMOTE_USERヘッダーの値をUserTokenに設定して、このエージェントのセッション属性をマップします。これを行うには、セッション属性マップで、マップ・キーにUserToken、対応するマップの値にOAM_REMOTE_USERを入力します。

9.12 ログアウト設定の構成

共存モードでOpenSSO Enterprise 8.0とAccess Manager 11.1.2.2.0間のシングル・ログアウトが行われるように、ログアウト設定を構成する必要があります。これを実行するには、次の2つの項で説明する手順に従ってください。

- OpenSSO Enterprise 8.0サーバーからログアウトを開始する設定

- Access Manager 11.1.2.2.0サーバーからログアウトを開始する設定

9.12.1 OpenSSO Enterprise 8.0サーバーからログアウトを開始する設定

OpenSSO Enterprise 8.0サーバーからログアウトを開始するには、認証後プラグインを作成し、onLogout()メソッドを実装して、問合せパラメータgotoをリダイレクトURL <OAM_server_protocol>://<OAM_server_host>:<OAM_managed_server_port>/opensso/UI/Logoutに設定する必要があります。このURLは、ユーザーをAccess Manager 11.1.2.2.0サーバーのエンドポイントURLにリダイレクトします。

9.12.2 Access Manager 11.1.2.2.0サーバーからログアウトを開始する設定

Access Manager 11.1.2.2.0サーバーからログアウトを開始するには、OpenSSO Enterprise 8.0サーバーのログアウト・エンドポイントにリダイレクトするように、Access Manager 11.1.2.2.0サーバーで構成されるそれぞれのポリシー・エージェント3.0 (Agent-1)で「ログアウトURL」を更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

2. 「システム構成」タブに移動します。

3. 「Access Manager」→「SSOエージェント」を開きます。

4. 「OpenSSOエージェント」を開きます。

5. Agent-1 (Access Manager 11.1.2.2.0で構成され、Resource-1を保護しているエージェント)を選択し、OpenSSO Enterprise 8.0サーバーのログアウト・エンドポイント(OpenSSO8.x_server_protocol://OpenSSO8.x_server_host:OpenSSO8.x_managed_server_port/opensso/UI/Logout)にリダイレクトするように「ログアウトURL」を設定します。goto問合せパラメータは、Agent-1について構成されたリダイレクトURLに設定します。

9.13 構成の確認

構成を確認するには、次の手順を実行します。

1. Resource-1にアクセスします。認証を受けるためにOpenSSO Enterprise 8.0サーバーにリダイレクトされるかどうかを観察します。認証後、Resource-1にアクセスできます。

2. (図9-1に示されているように)Agent-3で保護されるリソースにアクセスし、リソースに正常にアクセスするために明示的なログインが必要であることを確認します。

3. OpenSSO Enterprise 8.0サーバーとAccess Manager 11.1.2.2.0サーバーの両方からのログアウトを開始し、3つのCookie(cookie1、cookie2およびOAM_ID Cookie)がすべて消去されていることを確認します。

10 Sun Java System Access Manager 7.1とOracle Access Management Access Manager 11.1.2.2.0の共存

この章では、Sun Java System Access Manager 7.1からOracle Access Management Access Manager 11.1.2.2.0に移行した後、Sun Java System Access Manager 7.1とOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.2.0)のデプロイメントが共存する環境の設定方法について説明します。

この章には次の項が含まれます:

- 第10.1項「共存の概要」

- 第10.2項「共存のトポロジ」

- 第10.3項「タスク・ロードマップ」

- 第10.4項「共存の前提条件」

- 第10.5項「Agent-2によるAccess Manager 11gサーバーのエンドポイントURLの保護」

- 第10.6項「Access Manager 11.1.2.2.0のデータ・ソースの構成」

- 第10.7項「Access Manager 11gでのLDAPNoPasswordAuthModuleの更新」

- 第10.8項「Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成」

- 第10.9項「Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成」

- 第10.10項「Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更」

- 第10.11項「Sun Java System Access Manager 7.1サーバーでのAgent-2のプロファイルの更新」

- 第10.12項「ログアウト設定の構成」

- 第10.13項「構成の確認」

10.1 共存の概要

Sun Java System Access Manager 7.1からOracle Access Manager 11.1.2.2.0への移行プロセス時に、一部のアプリケーションはSun Java System Access Manager 7.1で保護され、その他のアプリケーションはAccess Manager 11.1.2.2.0で保護されるようにSun Java System Access Manager 7.1とAccess Manager 11gの両方のデプロイメントを共存できます。エンドユーザーがこれらのアプリケーション間を移動する場合、シームレスなシングル・サインオンの経験があることが望まれます。これを共存モードと言います。

このモードでは、Access Manager 11.1.2.2.0は、移行したアプリケーションや、Access Manager 11.1.2.2.0に登録された新しいアプリケーションを保護し、Sun Java System Access Manager 7.1は、Access Manager 11.1.2.2.0に移行されないアプリケーションを引き続き保護します。

この共存モードでは、Sun Java System Access Manager 7.1は、Access Manager 11.1.2.2.0で保護されるすべてのリソースの認証を行います。

10.2 共存のトポロジ

図10-1は、保護されたリソースへのアクセスをユーザーがリクエストした際にSun Java System Access Manager 7.1サーバーで行われる認証を示しています。

図10-1 Sun Java System Access Manager 7.1とAccess Manager 11.1.2.2.0の共存

トポロジは、Sun Java System Access Manager 7.1とAccess Manager 11.1.2.2.0の非結合環境で構成されます。トポロジ内の数字1-8は、共存環境でリクエストがフローする順序を示しています。リクエスト・フローについては、「表10-1」を参照してください。

トポロジの説明

- Agent-1: Resource-1を保護するポリシー・エージェント2.2です。このエージェントは、Access Manager 11.1.2.2.0サーバーと通信する必要があります。リモート登録ツールを使用すると、2.2エージェントをAccess Manager 11.1.2.2.0サーバーに直接登録できます。

- Agent-2: Sun Java System Access Manager 7.1に登録されるポリシー・エージェント2.2です。これは、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護します。Sun Java System Access Manager 7.1サーバーでこのエージェント用のプロファイルを作成し、新しいポリシー・エージェント(2.2)をインストールする必要があります。

- Agent-3およびAgent-4: Sun Java System Access Manager 7.1に登録されるポリシー・エージェント(2.2)です。

- Resource-1: Access Manager 11.1.2.2.0サーバーと通信するAgent-1で保護されるリソースです。

- Policy-1: Resource-1を保護するためにAccess Manager 11.1.2.2.0サーバーで作成されるポリシーです。このポリシーは、「Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成」タスクの一環として作成されます。

- Policy-2: Agent-2で保護されるAccess Manager 11.1.2.2.0のOpenSSOプロキシ・エンドポイント用にSun Java System Access Manager 7.1サーバーで作成されるポリシーです。このポリシーは、「Agent-2によるAccess Manager 11gサーバーのエンドポイントURLの保護」タスクの一環で作成されます。

表10-1は、リクエスト・フローの説明です。手順列の数字は、図10-1のトポロジに示される数字と対応しています。

表10-1 リクエスト・フロー

手順

説明

1

Access Manager 11.1.2.2.0サーバーと通信するAgent-1で保護されるResource-1へのアクセスをリクエストします。

2

Agent-1は、Policy-1により、認証スキームOAM10gAuthSchemeを使用して、認証を行うためにユーザーをAccess Manager 11gサーバー(…./opensso/UI/Login.....?goto=resource1)にリダイレクトします。Sun Java System Access Managerサーバーで認証されたユーザーは、OpenSSOエージェントによってOAM_REMOTE_USERヘッダーで設定されます。したがって、Agent-1は認証スキームOAM10gAuthSchemeを使用して、ヘッダーOAM_REMOTE_USERからユーザーをアサートします。

3

Access Manager 11.1.2.2.0サーバーのエンドポイントは、Sun Java System Access Manager 7.1サーバーと通信するAgent-2で保護されます。

したがって、Agent-2は、Policy-2により、LDAP認証を行うためにユーザーをSun Java System Access Manager 7.1サーバー(...opensso/UI/Login?goto=<…./oam/server/.....?goto=resource1>)にリダイレクトします。

4

Sun Java System Access Manager 7.1サーバーのLDAP認証モジュールによって、LDAPのユーザー名とパスワードの入力が求められます。ユーザーはLDAPの有効な資格証明を入力する必要があります。

5

Sun Java System Access Manager 7.1サーバーは、ユーザーの資格証明を検証し、ユーザー・セッションをOpenSSO Enterprise 8.0セッションとして作成して、OpenSSO Enterprise 8.0のSSO cookie1をこのセッションIDで設定します。

6

Sun Java System Access Manager 7.1サーバーは、ユーザーをAccess Manager 11.1.2.2.0サーバー(…./opensso/UI/Login/.....?goto=resource1)にリダイレクトします。

7

Agent-2は、Sun Java System Access Manager 7.1のセッションcookie1があるかどうかを確認することで、ユーザー・セッションとポリシー評価を検証します。セッション属性マッピングでヘッダーOAM_REMOTE_USERをuserIDに設定すると、Access Manager 11.1.2.2.0サーバー(…./opensso/UI/Login/.....?goto=resource1)へのアクセスが提供されます。

Access Manager 11.1.2.2.0サーバーは、手順2 (Policy-1)により、OAM 10gの認証スキーム(OAM10gAUthScheme)を呼び出し、Resource-1について構成されたOAM10gSchemeを使用して、ヘッダーOAM_REMOTE_USERでユーザーをアサートします。

8

Access Manager 11.1.2.2.0サーバーは、Access Managerのセッションを作成してヘッダーを設定します。また、OAM_IDのCookieとSun Java System Access ManagerのSSO cookie2 (OpenSSOプロキシ経由)も設定し、ユーザーをResource-1にリダイレクトします。Sun Java System Access Manager 7.1のSSO cookie2には、関連するOAM_ID Cookieとのリンクがあります。

Agent-1が、Sun Java System Access Managerセッションcookie2とOAM_ID Cookieがあるかどうかを確認することでユーザー・セッションおよびポリシー評価を検証すると、ユーザーはResource-1にアクセスできるようになります。

10.3 タスク・ロードマップ

表10-2に、共存環境の構成手順を示します。

表10-2 完了するタスク

タスク番号

タスク

参照先

1

構成プロセスを開始する前に、共存トポロジを理解して精通しておきます。

「共存のトポロジ」を参照してください。

2

前提条件を満たします。

「共存の前提条件」を参照してください。

3

Sun Java System Access Manager 7.1サーバーでAgent-2プロファイルを作成し、Agent-2をインストールします。oam-server.earファイルでWebアプリケーションngsso-web.warおよびopenssoproxy-urlmapper.warを更新します。

また、Sun Java System Access Manager 7.1で、Agent-2によってAccess Manager 11.1.2.2.0サーバーのエンドポイントURLを保護するポリシーを作成します。

「Agent-2によるAccess Manager 11gサーバーのエンドポイントURLの保護」を参照してください。

4

Access Manager 11.1.2.2.0のデータ・ソースを構成します。

「Access Manager 11.1.2.2.0のデータ・ソースの構成」を参照してください。

5

Access Manager 11gで認証モジュールを更新し、第10.6項で構成されるデータ・ソースを示すようにユーザー・アイデンティティ・ストアを指定します。

「Access Manager 11gでのLDAPNoPasswordAuthModuleの更新」を参照してください。

6

Access Manager 11.1.2.1.0でAgent-1のプロファイルを作成し、Access Manager 11.1.2.1.0サーバーを指す新しいポリシー・エージェント2.2 (Agent-1)をインストールします。

「Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成」を参照してください。

7

Access Manager 11.1.2.2.0サーバーで、Resource-1を保護する認証ポリシーを作成します。

「Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成」を参照してください。

8

Access Manager 11gとSun Java System Access Manager 7.1のCookie名が異なるように、Access Manager 11.1.2.2.0のデフォルトのCookie名を変更します。

「Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更」を参照してください。

9

Sun Java System Access Manager 7.1サーバーで、Agent-2のプロファイルを正しいセッション属性マッピングで更新します。

「Sun Java System Access Manager 7.1サーバーでのAgent-2のプロファイルの更新」を参照してください。

10

Sun Java System Access Manager 7.1サーバーとAccess Manager 11.1.2.2.0サーバーの両方からログアウトを開始するように、ログアウト設定を構成します。

「ログアウト設定の構成」を参照してください。

11

構成を確認します。

「構成の確認」を参照してください。

10.4 共存の前提条件

この章で説明するタスクの実行を開始する前に、次の前提条件を満たします。

- システム要件および動作保証のドキュメントを読み、環境がインストールする製品の最小要件を満たしていることを確認します。

- Oracle Fusion Middlewareのシステム要件と仕様
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。

- Oracle Fusion Middlewareのサポートされるシステム構成
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。

- インストール時に発生する可能性がある相互運用性および互換性の問題については、『Oracle Fusion Middleware相互運用および互換性ガイド』を参照してください。
Oracle Fusion Middleware製品が旧バージョンの他のOracle Fusion Middleware、Oracleまたはサード・パーティ製品と機能するために重要な情報がこのドキュメントに記載されています。この情報は、既存の環境をアップグレードする既存ユーザーと新しいOracle Fusion Middlewareユーザーの両方に適用されます。

注意:

Oracle Fusion Middlewareの概念とディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』のOracle Fusion Middlewareの概念とディレクトリ構造の理解に関する項を参照してください。

- 使用しているSun Java System Access Managerのリリースが共存でサポートされていることを確認します。OpenSSOの共存がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。

- Sun Java System Access Manager 7.1とOracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)のインストールが完了し、サーバーが動作していることを確認します。
Oracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)のインストールと構成を行っていない場合、次のタスクを開始する前にこれらの作業を行う必要があります。Oracle Access Management Access Manager 11gリリース2 (11.1.2.2.0)のインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.2.0)のインストールに関する説明およびOracle Access Managementの構成に関する説明を参照してください。

- Sun Java System Access Manager 7.1およびAccess Manager 11.1.2.2.0が同じユーザー・ストアを共有することを確認します。

- Sun Java System Access Manager 7.1サーバーおよびAccess Manager 11.1.2.2.0サーバーが異なるマシンで動作している場合は、これらのマシンの時刻が同期するようにします。

10.5 Agent-2によるAccess Manager 11gサーバーのエンドポイントURLの保護

Sun Java System Access Manager 7.1でAgent-2のプロファイルを作成し、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護するポリシー・エージェント2.2を新規でインストールする必要があります。また、Sun Java System Access Manager 7.1サーバーでAccess Manager 11gサーバーのエンドポイントURLを保護するためのポリシーも作成する必要があります。そのためには、次のタスクを実行します。

1. Sun Java System Access Manager 7.1サーバーでのAccess ManagerのAgent-2プロファイルの作成

2. Agent-2(ポリシー・エージェント2.2)のインストール

3. エージェント・フィルタ構成を含めるWebアプリケーションの更新

4. Sun Java System Access Manager 7.1サーバーでのAccess Managerのポリシーの作成

10.5.1 Sun Java System Access Manager 7.1サーバーでのAccess ManagerのAgent-2プロファイルの作成

(図10-1に示されているように)Sun Java System Access Manager 7.1サーバーでAgent-2プロファイルを作成します。手順は次のとおりです。

1. 次のURLを使用してSun Java System Access Manager 7.1サーバーのコンソールにログインします。

http://host:port/amserver

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

- hostは、Sun Java System Access Manager 7.1コンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、Sun Java System Access Manager 7.1コンソールに指定されたバインド・ポートを表します。

2. 「アクセス制御」タブに移動します。

3. 「レルム」表で、「レルム名」列の一番上のレルムをクリックします。

4. 「サブジェクト」タブに移動して、「エージェント」タブをクリックします。

5. 「新規」をクリックして新しいAgent-2を作成し、そのエージェントに関する必要な詳細を指定します。

6. 「OK」をクリックします。

10.5.2 Agent-2(ポリシー・エージェント2.2)のインストール

Access Managerの前にAgent-2(ポリシー・エージェント2.2)をインストールします。

ポリシー・エージェント2.2のインストールの詳細は、Sun Java System Access Managerポリシー・エージェント2.2ガイド(BEA WebLogic Server/ポータル10)のWebLogic Server/ポータル10のポリシー・エージェントのインストールに関する項を参照してください。

10.5.3 エージェント・フィルタ構成を含めるWebアプリケーションの更新

Access Manager 11.1.2.2.0サーバーをAgent-2で保護するには、Webアプリケーションngsso-web.warおよびopenssoproxy-urlapper.warを更新して、エージェント・フィルタ構成をweb.xmlファイルに含めます。これを行うには、次の手順を実行します。

1. IAM_HOME/oam/server/apps/oam-server.earからoam-server.earファイルを解凍して、内容を一時ディレクトリに抽出します。

2. ngsso-web.warファイル、web.xmlファイルの順に内容を抽出します。Access Manager 11.1.2.2.0サーバーをAgent-2で保護するには、web.xmlファイルを適切なエージェント・フィルタ構成で更新します。フィルタ定義をurl-patternのURL /server/opensso/login/*で更新します。
次に例を示します。

<filter>
<filter-name>Agent</filter-name>
<filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Agent</filter-name>
<url-pattern>/server/opensso/login/*</url-pattern>
</filter-mapping>

3. 同じ場所IAM_HOME/oam/server/apps/oam-server.earでopenssoproxy-urlmapper.warファイルの内容を抽出します。Access Manager 11.1.2.2.0サーバーをAgent-2で保護するには、web.xmlファイルを適切なエージェント・フィルタ構成で更新します。フィルタ定義をurl-patternのURL /UI/*で更新します。
次に例を示します。

<filter>
<filter-name>Agent</filter-name>
<filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Agent</filter-name>
<url-pattern>/UI/*</url-pattern>
</filter-mapping>

4. 更新したngsso-web.warファイルとopenssoproxy-urlapper.warファイルを含めるようにoam-server.earファイルを再パッケージします。

5. 更新したoam-server.earファイルを再デプロイします。

10.5.4 Sun Java System Access Manager 7.1サーバーでのAccess Managerのポリシーの作成

Sun Java System Access Manager 7.1サーバーで、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護するポリシー(Policy-1)を作成する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してSun Java System Access Manager 7.1サーバーのコンソールにログインします。

http://host:port/amserver

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

- hostは、Sun Java System Access Manager 7.1コンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、Sun Java System Access Manager 7.1コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「アクセス制御」タブをクリックします。

3. 「レルム」表で、「レルム名」列の一番上のレルムをクリックします。

4. 「ポリシー」タブをクリックします。

5. 新規ポリシーをクリックして、Access Manager 11.1.2.2.0サーバーのエンドポイントURLを保護するための新しいポリシーの詳細を入力します。この場合は、「ルール」はOAM_server_protocol://OAM_managed_server_host:OAM_managed_server_port/opensso/UI/Login*?*およびOAM_server_protocol://OAM_managed_server_host:OAM_managed_server_port/oam/server/opensso/login*にして、「サブジェクト」は認証されたユーザーにします。

6. 「OK」をクリックします。

10.6 Access Manager 11.1.2.2.0のデータ・ソースの構成

Access Manager 11.1.2.2.0のデータ・ソースを構成するには、次の手順を完了します。

1. 次のURLを使用してOracle Access Manager 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

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

- hostは、Oracle Access Managerコンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。

- portは、Oracle Access Management 11.1.2.2.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。

2. 「起動パッド」タブに移動します。

3. 構成セクションで、「ユーザー・アイデンティティ・ストア」をクリックします。

4. 「ユーザー・アイデンティティ・ストア」タブで、「OAM IDストア」の「作成」ボタンをクリックします。このデータ・ソースのタイプは、ODSEEにします。構成およびユーザー・ストアとしてSun Java System Access Manager 7.1で使用されるSun Java System Directory Serverの詳細を提供する必要があります。

10.7 Access Manager 11gでのLDAPNoPasswordAuthModuleの更新

第10.6項で「ユーザー・アイデンティティ・ストア」として作成したデータ・ソースを指すように、OAM10gSchemeで使用される認証モジュールを更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

2. 「システム構成」タブに移動します。

3. 「Access Manager」→「認証モジュール」を開きます。

4. 「LDAP認証モジュール」を開きます。

5. LDAPNoPasswordAuthModuleをクリックし、第10.6項で作成したデータ・ソースを指し示すように「ユーザー・アイデンティティ・ストア」を更新します。

10.8 Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成

リモート登録ツールを使用してAccess Manager 11.1.2.2.0でAgent-1のプロファイルを作成し、Access Manager 11.1.2.2.0サーバーを指す新しいポリシー・エージェント2.2 (Agent-1)をインストールする必要があります。

Access Manager 11.1.2.2.0でのAgent-1のプロファイルの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOpenSSOエージェントのリモート登録の実行に関する項を参照してください。

注意:

Access Manager 11.1.2.2.0でポリシー・エージェント2.2のプロファイルを作成するには、リモート登録ツールを使用する必要があります。

次に、Access Manager 11.1.2.2.0でAgent-1のプロファイルを作成するプロセスで使用するOpenSSORequest.xmlファイルの例を示します。

<OpenSSORegRequest>

<serverAddress>oam_admin_server_host:oam_admin_server_port</serverAddress>
<hostIdentifier>2.2_Agent_Name</hostIdentifier>
<agentName>2.2_Agent_Name</agentName>
<agentBaseUrl>web_server_host:web_server_port</agentBaseUrl>
<applicationDomain>2.2_Agent_Name</applicationDomain>
<autoCreatePolicy>true</autoCreatePolicy>
<agentType>WEB</agentType>
<agentVersion>2.2</agentVersion>
<agentDebugDir></agentDebugDir>
<agentAuditDir></agentAuditDir>
<agentAuditFileName></agentAuditFileName>
<protectedAuthnScheme></protectedAuthnScheme>

</OpenSSORegRequest>

ポリシー・エージェント2.2の詳細は、Sun OpenSSO Enterprise 8.0ドキュメント・ライブラリの各ガイドを参照してください。

10.9 Access Manager 11.1.2.2.0でのResource-1を保護する認証ポリシーの作成

Resource-1を保護する認証ポリシー(Policy-2)を、OAM10gSchemeという認証スキームで適切なアプリケーション・ドメインに作成します。

また、条件TRUEを指定してResource-1の認可ポリシーを作成します。構成されているリソースURLは、/および/.../*である必要があります。

認証および認可ポリシーの作成と管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のリソースの保護とSSOの有効化のためのポリシーの管理に関する項を参照してください。

10.10 Access Manager 11.1.2.2.0でのOpenSSO Cookie名の変更

Access Manager 11.1.2.2.0サーバーとSun Java System Access Manager 7.1サーバーでCookie名の競合が発生しないように、Access Manager 11.1.2.2.0サーバーのデフォルトのCookie名を新しい名前に変更する必要があります。これを行うには、次の手順を実行します。

1. Access Manager 11.1.2.2.0管理サーバーおよび管理対象サーバーを停止します。
管理サーバーおよび管理対象サーバーの停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の管理サーバーの起動と停止に関する項および管理対象サーバーの起動と停止に関する項を参照してください。

2. IAM_HOME/user_projects/domains/base_domain/config/fmwconfig/oam-config.xmlからoam-config.xmlファイルを開きます。

3. oam-config.xmlファイルでVersionパラメータの値を1増やします。

4. openssoproxyセクションで、openssoCookieNameの値を、デフォルトのCookie名iPlanetDirectoryProから別の値(OAMSAMCookieなど)に変更します。

5. Access Manager 11.1.2.2.0管理サーバーおよび管理対象サーバーを起動します。
管理サーバーおよび管理対象サーバーの起動の詳細は、『Oracle Fusion Middleware管理者ガイド』の管理サーバーの起動と停止に関する項および管理対象サーバーの起動と停止に関する項を参照してください。

6. Agent-1をインストールした場所からAMAgent.propertiesファイルを開き、Agent-1のタイプに基づいて次の手順を実行します。

- Agent-1が2.2 J2EEエージェントの場合、com.iplanet.am.cookie.nameプロパティの値を、手順4で使用した新しいCookie名(OAMSAMCookieなど)に変更します。

- Agent-1が2.2 Webエージェントの場合、com.sun.am.cookie.nameプロパティの値を、手順4で使用した新しいCookie名(OAMSAMCookieなど)に変更します。

7. Access Manager 11.1.2.2.0サーバーを再起動します。

10.11 Sun Java System Access Manager 7.1サーバーでのAgent-2のプロファイルの更新

Agent-2のセッション属性マッピングを更新して、AMAgent.propertiesファイルでヘッダーOAM_REMOTE_USERを値UserTokenに設定します。これを行うには、次の手順を実行します。

1. Agent-2をインストールした場所からAMAgent.propertiesファイルを開きます。

2. プロパティ・ファイルで次の値を設定します。

- com.sun.identity.agents.config.session.attribute.fetch.mode=HTTP_HEADER

- com.sun.identity.agents.config.session.attribute.mapping[UserToken]=OAM_REMOTE_USER

3. Agent-2のWebコンテナ・インスタンスを再起動します。

10.12 ログアウト設定の構成

共存モードでSun Java System Access Manager 7.1とAccess Manager 11.1.2.2.0間のシングル・ログアウトが行われるように、ログアウト設定を構成する必要があります。これを実行するには、次の2つの項で説明する手順に従ってください。

- Sun Java System Access Manager 7.1サーバーからログアウトを開始する設定

- Access Manager 11gサーバーからログアウトを開始する設定

10.12.1 Sun Java System Access Manager 7.1サーバーからログアウトを開始する設定

Sun Java System Access Manager 7.1サーバーからログアウトを開始するには、認証後プラグインを作成し、onLogout()メソッドを実装して、問合せパラメータgotoをリダイレクトURL <OAM_server_protocol>://<OAM_server_host>:<OAM_managed_server_port>/opensso/UI/Logoutに設定する必要があります。これは、Access Manager 11.1.2.2.0サーバーのエンドポイントURLにユーザーをリダイレクトします。

10.12.2 Access Manager 11gサーバーからログアウトを開始する設定

Access Manager 11.1.2.2.0サーバーからログアウトを開始するには、Access Manager 11.1.2.2.0サーバーで構成されるそれぞれのポリシー・エージェント2.2 (Agent-1)で、Sun Java System Access Manager 7.1サーバーのログアウト・エンドポイントにリダイレクトするように「ログアウトURL」を更新する必要があります。これを行うには、次の手順を実行します。

1. 次のURLを使用してOracle Access Management 11.1.2.2.0コンソールにログインします。

http://host:port/oamconsole

2. 「起動パッド」タブに移動します。

3. 「Access Manager」セクションから、「SSOエージェント」をクリックします。

4. 「OpenSSOエージェント」タブをクリックします。

5. Agent-1 (Access Manager 11gで構成され、Resource-1を保護しているエージェント)を選択し、「ログアウトURL」をSun Java System Access Manager 7.1サーバーのログアウト・エンドポイント(SAM7.1_server_protocol://SAM7.1_server_host:SAM7.1_managed_server_port/amserver/UI/Logout)にリダイレクトするように設定します。goto問合せパラメータは、Agent-1に構成されるリダイレクトURLに設定されます。
たとえば、すでに構成されている「ログアウトURL」がprotocol://OAMHOST:OAMPORT/opensso/UI/Logoutの場合、これをprotocol://OAMHOST:OAMPORT/opensso/UI/Logout?goto=SAM7.1_server_protocol://SAM7.1_server_host:SAM7.1_server_port/amserver/UI/Logout?goto=any url agent wants to be redirected to after logoutに変更する必要があります。

10.13 構成の確認

構成を確認するには、次の手順を実行します。

1. Resource-1にアクセスします。認証を受けるためにSun Java System Access Manager 7.1サーバーにリダイレクトされるかどうかを観察します。認証後、Resource-1にアクセスできます。

2. (図10-1に示されているように)Agent-3で保護されるリソースにアクセスし、リソースへのアクセスに明示的なログインが必要であることを確認します。

3. Sun Java System Access Manager 7.1サーバーとAccess Manager 11.1.2.2.0サーバーの両方からのログアウトを開始し、3つのCookie(cookie1、cookie2およびOAM_ID Cookie)がすべて消去されていることを確認します。

A 一般的な移行タスク

この付録は、アップグレード・プロセスの一環として実行する必要のある一般的な移行タスクを示しています。

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

- 付録A「サーバーの停止」

- 付録A「サーバーの起動」

A.1 サーバーの停止

WebLogic管理サーバーおよび管理対象サーバーを停止するには、次の項を参照してください。

- 管理対象サーバーの停止

- WebLogic管理サーバーの停止

管理対象サーバーを停止してから、WebLogic管理対象サーバーを停止する必要があります。

A.1.1 管理対象サーバーの停止

管理対象サーバーを停止するには、次の手順を実行します。

UNIXの場合:

1. コマンド行で次のコマンドを実行して、現在の作業ディレクトリからMW_HOME/user_projects/domains/domain_name/binディレクトリに移動します。
cd MW_HOME/user_projects/domains/domain_name/bin

2. 次のコマンドを実行してサーバーを停止します。
./stopManagedWebLogic.sh managed_server_name admin_url admin_username password

各項目は次のとおりです。

managed_server_nameは、管理対象サーバーの名前です。

admin_urlは、WebLogic管理コンソールのURLです。http://host:port/consoleという形式で指定します。WebLogic管理サーバーが異なるコンピュータ上にある場合にのみ指定します。

admin_usernameは、WebLogic管理サーバーのユーザー名です。

passwordはWebLogic管理サーバーのパスワードです。

Windowsの場合:

1. コマンド行で次のコマンドを実行して、現在の作業ディレクトリからMW_HOME\user_projects\domains\domain_name\binディレクトリに移動します。
cd MW_HOME\user_projects\domains\domain_name\bin

2. 次のコマンドを実行して管理対象サーバーを停止します。
stopManagedWebLogic.cmd managed_server_name admin_url admin_username password

各項目は次のとおりです。

managed_server_nameは、管理対象サーバーの名前です。

admin_urlは、WebLogic管理コンソールのURLです。http://host:port/consoleの形式でこれを指定します。また、WebLogic管理サーバーが別のマシン上にある場合にのみ指定します。

admin_usernameは、WebLogic管理サーバーのユーザー名です。

passwordはWebLogic管理サーバーのパスワードです。

詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のスタックの停止に関する項を参照してください。

A.1.2 WebLogic管理サーバーの停止

WebLogic管理サーバーに停止するには、次の手順を実行します。

UNIXの場合:

次のコマンドを実行します:

cd MW_HOME/user_projects/domains/domain_name/bin

./stopWebLogic.sh

Windowsの場合:

次のコマンドを実行します:

cd MW_HOME\user_projects\domains\domain_name\bin

stopWebLogic.cmd

A.2 サーバーの起動

WebLogic管理サーバーおよび管理対象サーバーを起動するには、次の項を参照してください。

- WebLogic管理サーバーの起動

- 管理対象サーバーの起動

A.2.1 WebLogic管理サーバーの起動

WebLogic管理サーバーを起動するには、次の手順を実行します。

UNIXの場合:

次のコマンドを実行します:

cd MW_HOME/user_projects/domains/domain_name/bin

./startWebLogic.sh

Windowsの場合:

次のコマンドを実行します:

cd MW_HOME\user_projects\domains\domain_name\bin

startWebLogic.cmd

A.2.2 管理対象サーバーの起動

管理対象サーバーを起動するには、次の手順を実行します。

UNIXの場合:

1. コマンド行で次のコマンドを実行して、現在の作業ディレクトリからMW_HOME/user_projects/domains/domain_name/binディレクトリに移動します。
cd MW_HOME/user_projects/domains/domain_name/bin

2. 次のコマンドを実行して管理対象サーバーを起動します。
./startManagedWebLogic.sh managed_server_name admin_url admin_username password

各項目は次のとおりです。

managed_server_nameは、管理対象サーバーの名前です。

admin_urlは管理コンソールのURLです。http://host:port/consoleという形式で指定します。WebLogic管理サーバーが異なるコンピュータ上にある場合にのみ指定します。

admin_usernameは、WebLogic管理サーバーのユーザー名です。

passwordはWebLogic管理サーバーのパスワードです。

Windowsの場合:

1. コマンド行で次のコマンドを実行して、現在の作業ディレクトリからMW_HOME\user_projects\domains\domain_name\binディレクトリに移動します。
cd MW_HOME\user_projects\domains\domain_name\bin

2. 次のコマンドを実行して管理対象サーバーを起動します。
startManagedWebLogic.cmd managed_server_name admin_url admin_username password

各項目は次のとおりです。

managed_server_nameは、管理対象サーバーの名前です。

admin_urlは管理コンソールのURLです。http://host:port/consoleという形式で指定します。WebLogic管理サーバーが異なるコンピュータ上にある場合にのみ指定します。

admin_usernameは、WebLogic管理サーバーのユーザー名です。

passwordはWebLogic管理サーバーのパスワードです。

詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のスタックの起動に関する項を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。