ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity and Access Management移行ガイド
11gリリース2 (11.1.2.2.0)
E53415-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

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 共存の概要

一部のアプリケーションは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の説明が続きます
「図8-1 Oracle Access Manager 10gとAccess Manager 11.1.2.2.0の共存」の説明

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サーバーで保護されているリソースにアクセスするときの、共存モードのSSOの動作について説明しています。

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の説明が続きます
「図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の説明が続きます
「図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の説明が続きます
「図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の説明が続きます
「図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-1OHS-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-1OHS-2にデプロイされ、Access Manager 11.1.2.2.0サーバーで構成されます。

WebGate 10g-2OHS-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と連携するように構成する必要があります。


注意:

DCCは、ObSSOCookieを両方のWebGateに渡すことができるように、Oracle Access Manager 10gサーバーの認証WebGateと同じドメインにある必要があります。


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

共存環境を設定するための既存の10g WebGateインスタンスを使用するか、新しい10g WebGateインスタンスをインストールできます。

新しいWebGateインスタンス(WebGate 10g-1WebGate 10g-2)をインストールする場合、それらを次のように構成する必要があります。

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_portOHS-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サーバーの両方でログアウトが機能することを確認してください。これを行うには、次の手順を実行します。

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サーバーを再起動して共存モードを構成します。