| Oracle® Fusion Middleware Oracle Identity and Access Management移行ガイド 11gリリース2 (11.1.2.3.0) E67359-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Management移行ガイド 11gリリース2 (11.1.2.3.0) E67359-01 |
|
前 |
次 |
この章では、Oracle Access Manager 10gをOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.3.0)のデプロイメントが共存する環境を設定する方法について説明します。
この章には次の項が含まれます:
一部のアプリケーションはOracle Access Manager 10gで保護され、その他のアプリケーションはAccess Manager 11.1.2.3.0で保護されるように、Oracle Access Manager 10gおよびAccess Manager 11.1.2.3.0の両方のデプロイメントを共存させることができます。これを共存モードと呼び、Oracle Access Manager 10gおよびAccess Manager 11.1.2.3.0の両方のデプロイメントが共存します。
共存モードでは、Access Manager 11.1.2.3.0は、移行されたアプリケーション、およびAccess Manager 11.1.2.3.0に登録された新しいアプリケーションを保護し、Oracle Access Manager 10gは、Access Manager 11.1.2.3.0に移行されていないアプリケーションを引き続き保護します。
エンドユーザーは、Oracle Access Manager 10gで保護されるアプリケーションとAccess Manager 11.1.2.3.0で保護されるアプリケーションの間を移動する際に、シームレスなシングル・サインオン(SSO)を利用できます。
図9-1は、Oracle Access Manager 10gサーバーとAccess Manager 11.1.2.3.0サーバーの共存を示しています。Resource Aは、Access Manager 11g WebGateで保護され、他のリソースは、Oracle Access Manager 10g WebGateで保護されます。Oracle Access Manager 10gサーバーまたはAccess Manager 11.1.2.3.0サーバーのいずれかと連携するようにOracle Access Manager 10g WebGateを構成したり、Access Manager 11.1.2.3.0サーバーのみと連携するようにAccess Manager 11g WebGateを構成することができます。
図9-1 Oracle Access Manager 10gとAccess Manager 11.1.2.3.0の共存
Oracle Access Manager 10gとAccess Manager 11.1.2.3.0サーバーは、それらにルーティングされるすべての認証リクエストと認可リクエストを、相互に依存せず独立して処理できます。
共存している間、すべての認証スキームとポリシーは維持されます。これは、Oracle Access Manager 10gで保護されている既存のアプリケーションおよびAccess Manager 11.1.2.3.0プラットフォームで保護されている移行されたアプリケーションのいずれにも適用されます。たとえば、アプリケーションがX509認証スキームで保護されている場合、これは、共存している間Access Manager 11.1.2.3.0プラットフォームのX509認証スキームでも保護されます。
Access Manager 11.1.2.3.0サーバーで認証されているユーザーは、Oracle Access Manager 10gサーバーで保護されている各リソースにアクセスする場合、資格証明を再度入力する必要がなく、その逆も同様です。これにより、ユーザーにシームレスなシングル・サインオン(SSO)が提供されます。ユーザーは、Oracle Access Manager 10gで保護されているResource Bにアクセスすると、Access Manager 11.1.2.3.0で保護されているResource Aに、再度ユーザー資格証明を入力せずにアクセスできます。
ユーザーがいずれかのサーバーからログアウトした場合、セッションは終了し、ユーザーはAccess Manager 11.1.2.3.0とOracle Access Manager 10gサーバーの両方からログアウトされます。ユーザーは、再認証した場合のみ、保護されているリソースにアクセスできます。
共存モードでは、ユーザーは、Access Manager 11.1.2.3.0の認証に関連するすべての機能および拡張機能を利用できます。Oracle Access Manager 11.1.2.3.0の機能拡張の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management 11.1.2.3.0の製品拡張機能に関する項を参照してください。
Oracle Access Managerサーバー構成で共存とマルチデータ・センター(MDC)が有効化されている場合、SessionDataRetrivalOnDemandフラグはfalseに設定される必要があります。有効なcookieがリクエストに指定されていれば、セッションは必ずOracle Access Managerサーバーで作成されます。ユーザー認証のソースとして、Access Manager 11gサーバーとOracle Access Manager 10gサーバーの両方で生成されるObSSOCookieが使用されます。Cookieの検証のみが、有効なユーザー・セッションの条件である共存モードでは、プレーン10g MDCモードがサポートされています。ユーザー・セッションが任意のデータ・センターにない場合、それ以外のデータ・センターに既存のセッションがあるかどうかに関係なく新しいセッションが作成されます。
MDCデプロイの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のマルチデータ・センターの理解に関する項を参照してください。
Access Manager 11.1.2.3.0 Serverでは、次の資格証明コレクションのメカニズムがサポートされます。
埋込み資格証明コレクタ(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を使用したログイン処理に関する説明を参照してください。
DCCトンネリングおよびリソースWebgate: これは、アプリケーションを保護するWebGateが、トンネルとして一元化されたDCCとは別に独立的に管理されている分散デプロイメントです。
DCCトンネリングの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Protocolを介したDCCからAccess Managerへのトンネリングに関する項を参照してください。
表9-1は、Access Manager 11.1.2.3.0サーバーに登録されているWebGate 11gおよびWebGate 10gが共存モードの資格証明コレクションに使用するメカニズムの比較を示しています。
表9-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が必要です。 |
表9-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のインストールの比較を参照してください。
表9-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フォームを使用できます。 |
図9-1は、Oracle Access Manager 10gサーバーとAccess Manager 11.1.2.3.0サーバーの共存を示しています。
トポロジは、Oracle Access Manager 10gとAccess Manager 11.1.2.3.0の非結合設定で構成され、ここでは、リソース、WebGateおよびサーバーが同じドメインにあります。
この共存設定の内容は次のとおりです。
Access Manager 11.1.2.3.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.3.0サーバーに対して登録されたAccess Manager 11gのWebGateパートナ。
トポロジの説明
WebGate 11g-1: Access Manager 11.1.2.3.0サーバーに登録された11gのWebGateパートナを表します。これは、OHS-1というOracle HTTP Server 11gにデプロイされます。WebGate 11g-1は、Resource A (Access Manager 11.1.2.3.0サーバーにインストールされているアプリケーション)を保護し、11g WebGateは、Access Manager 11.1.2.3.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.3.0サーバーと直接通信しません。Access Manager 11.1.2.3.0サーバーは、リソースWebGateからリクエストを受信し、認証リクエストをDCCにリダイレクトします。DCCは、セッションのObSSOCookieを設定し、これは、Access Manager 11.1.2.3.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.3.0サーバーに登録されたOracle Access Manager 10gのWebGateパートナを表します。これは、OHS-2というOracle HTTP Server 11gにデプロイされます。WebGate 10g-1は、Resource C (Access Manager 11.1.2.3.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.3.0サーバーおよびOracle Access Manager 10gサーバーを、同じユーザー・アイデンティティ・ストアを共有するように構成すると、いずれのサーバーも、ユーザー・リクエストに存在するObSSOCookieを確認して更新できます。
次のシナリオは、ユーザーがAccess Manager 11.1.2.3.0サーバーおよびOracle Access Manager 10gサーバーで保護されているリソースにアクセスするときの、共存モードのSSOの動作について説明しています。
共存モードでは、ユーザーがすでにOracle Access Manager 10gサーバーで認証されている場合、Access Manager 11.1.2.3.0サーバーは、Access Manager 10gサーバーで設定されているObSSOCookieを使用し、統合セッションを作成します。そのため、ユーザーは資格証明を再度入力する必要はありません。
図9-2は、ユーザーが、Oracle Access Manager 10gサーバーに対して登録されているWebGate 10g-2で保護されているResource Bにアクセスし、次にAccess Manager 11.1.2.3.0サーバーに対して登録されているWebGate 10g-1で保護されているResource Cにアクセスするときの、SSOの共存モードでの動作を示しています。
図9-2 ユーザーが、10g WebGateおよびOracle Access Manager 10gで保護されているResource Bにアクセスし、次に10g WebGateおよびAccess Manager 11gで保護されているResource Cにアクセスを試みる
表9-3は、リクエスト・フローの説明です。手順列の数字は、図9-2のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。
表9-3 リクエスト・フロー
| 手順 | 説明 |
|---|---|
|
1 |
次のURLで、Oracle Access Manager 10
|
|
2 |
|
|
3 |
|
|
4および5 |
ユーザーが資格証明を入力すると、 |
|
6 |
次のURLで、Access Manager 11.1.2.3.0サーバーによって保護される
リクエストには、 |
|
7-8 |
Access Manager 11.1.2.3.0サーバーは、ポリシー構成に従って、ObSSOCookieを確認し、ユーザーを認可し、統合セッションを作成し、 |
図9-3は、ユーザーが、Access Manager 11.1.2.3.0サーバーで保護されているResource Aにアクセスし、次にOracle Access Manager 10gサーバーで保護されているResource Bにアクセスするときの、SSOの共存モードでの動作を示しています。
図9-3 ユーザーが、11g WebGateおよびOracle Access Manager 11gサーバーで保護されているResource Aにアクセスし、次に10g WebGateおよびOracle Access Manager 10gサーバーで保護されているResource Cにアクセスを試みる
表9-4は、リクエスト・フローの説明です。手順列の数字は、図9-3のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。
表9-4 リクエスト・フロー
| 手順 | 説明 |
|---|---|
|
1 |
次のURLで、Access Manager 11.1.2.3.0サーバーによって保護される
|
|
2 |
|
|
3 |
Access Manager 11.1.2.3.0サーバーは、外部資格証明コレクタ(DCC)にリクエストをリダイレクトし、これによりログイン・ページにスローされます。DCCは、ユーザーが認証のために入力した資格証明を収集して処理します。 |
|
4-5 |
ユーザーが資格証明を入力すると、外部資格証明コレクタはAccess Manager 11.1.2.3.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.3.0サーバーは、ポリシー構成に従って、関連するすべてのヘッダーとObSSOCookieを |
|
6 |
次のURLで、Oracle Access Manager 10
リクエストには、 |
|
7-8 |
Oracle Access Manager 10gサーバーは、ポリシー構成に従ってObSSOCookieを復号化して検証し、ユーザーを認可して、 |
共存モードでは、Access Manager 11.1.2.3.0サーバーはユーザー・リクエストを資格証明コレクタにリダイレクトし、10gおよび11g WebGateの両方の資格証明を収集します。WebGate 11gおよびWebGate 10gが共存モードで資格証明を収集するために使用されるメカニズムの比較は、第9.3項「サポートされる資格証明コレクションのメカニズム」を参照してください。
図9-4は、ユーザーが、Oracle Access Manager 10gサーバーで保護されているResource Bにアクセスし、次にAccess Manager 11.1.2.3.0サーバーで保護されているResource Aにアクセスするときの、SSOの共存モードでの動作を示しています。
図9-4 ユーザーが、10g WebGateおよびAccess Manager 10gサーバーで保護されているResource Bにアクセスし、次に11g WebGateおよびAccess Manager 11gサーバーで保護されているResource Aにアクセスを試みる
表9-5は、リクエスト・フローの説明です。手順列の数字は、図9-4のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。
表9-5 リクエスト・フロー
| 手順 | 説明 |
|---|---|
|
1 |
次のURLで、Oracle Access Manager 10
|
|
2 |
|
|
3 |
|
|
4および5 |
ユーザーが資格証明を入力すると、 |
|
6 |
次のURLで、Access Manager 11.1.2.3.0サーバーによって保護される
リクエストには、 |
|
7 |
|
|
8 |
Access Manager 11.1.2.3.0サーバーは、リクエストを |
|
9-10 |
DCCはAccess Manager 11.1.2.3.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.3.0サーバーは、ポリシー構成に従って、更新されたObSSOCookieを |
図9-5は、ユーザーが、Access Manager 11.1.2.3.0サーバーで保護されているResource Cにアクセスし、次にAccess Manager 11.1.2.3.0サーバーで保護されているResource Aにアクセスするときの、SSOの共存モードでの動作を示しています。
図9-5 ユーザーが、10g WebGateおよびAccess Manager 11gサーバーで保護されているResource Cにアクセスし、次に11g WebGateおよびAccess Manager 11gサーバーで保護されているResource Aにアクセスを試みる
表9-6は、リクエスト・フローの説明です。手順列の数字は、図9-5のトポロジ内の数字に対応し、共存環境でリクエストがフローする順序を示しています。
表9-6 リクエスト・フロー
| 手順 | 説明 |
|---|---|
|
1 |
次のURLで、Access Manager 11.1.2.3.0サーバーによって保護される
|
|
2 |
|
|
3 |
Access Manager 11.1.2.3.0サーバーは、ECCまたはDCCにリクエストをリダイレクトし、これによりログイン・ページにスローされます。ECCまたはDCCは、ユーザーが認証のために入力した資格証明を収集して処理します。 |
|
4-5 |
ユーザーが資格証明を入力すると、ECCまたはDCCはAccess Manager 11.1.2.3.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.3.0サーバーは、ポリシー構成に従って、関連するすべてのヘッダーとObSSOCookieを |
|
6 |
次のURLで、Access Manager 11.1.2.3.0サーバーによって保護される
リクエストには、 |
|
7 |
|
|
8 |
Access Manager 11.1.2.3.0サーバーは、リクエストを |
|
9 |
DCCはAccess Manager 11.1.2.3.0サーバーと通信し、認証に続いて認可を行います。認可が終わると、Access Manager 11.1.2.3.0サーバーは、ポリシー構成に従って、更新されたObSSOCookieを |
次に、サーバーの共存の制限を示します。
サーバーの共存は10g ObSSOCookieに基づいて動作するので、特定の11gサーバー側セッションの機能は適用されません。1つの統合セッションのみが11gで作成されます。
ユーザーに対する最大セッション制限を設定することはできず、管理者がユーザーのセッションをパージすることはできません。ユーザーは有効なObSSOCookieを持っているかぎり、認証されたままでいることができます。
認証レベルおよびセッションのアイドル・タイム・アウトは、11gサーバーではなく、ObSSOCookieの値により導出されます。
マルチデータ・センター(MDC)デプロイメントは共存時にサポートされますが、セッション・データは1つのデータ・センターから別のデータ・センターへと取得できません。
次のセッション管理機能は共存が有効化された状態ではサポートされません。
アプリケーション・ドメイン・レベルのタイムアウト: Oracle Access Management 11gでは、アプリケーション・ドメイン・レベルのタイムアウトがサポートされ、セッション内で保持されます。共存では、すべてのアプリケーションに対し、ユーザー・ログインごとに1つのセッションのみ存在します。そのため、アプリケーション・ドメインのタイムアウトは統合セッションでは上書きされます。
ログインごとにいつでも1つのセッションのみが存在するので、ログインごとのセッションの最大数は常に1つのままです。
すべてのユーザーを削除ボタン: すべてのユーザーを削除ボタンによりすべてのユーザー・セッションが削除されます。しかし、Obssocookieが有効な場合は、セッションは再作成されます。ユーザーがブラウザからログアウトした後でのみ、Obssocookie cookieが削除され、現在のセッションがクリアされます。
有効なObssocookieがリクエストで検出されるとセッションが作成されます。共存モードでのOracle Access Management 11gセッションは、Obssocookieの有効性に完全に依存します。したがって、すべての10g WebGatesおよびDCC WebGatesの場合、アイドル・セッションのタイムアウトおよびcookieセッションのタイムアウトは、Oracle Access Manager 10g ServerとOracle Access Manager 11g Server間で同じにする必要があります。
表9-7は、図9-1に示されているトポロジの設定および構成手順を示しています。
表9-7 完了するタスク
| タスク番号 | タスク | 参照先 |
|---|---|---|
|
1 |
構成プロセスを開始する前に、共存の機能、サポートされる資格証明コレクタのメカニズム、共存のトポロジおよび共存の制限について理解し、精通しておいてください。 |
次の項を参照してください。 |
|
2 |
前提条件を満たします。 |
「共存の前提条件」を参照してください。 |
|
3 |
Oracle HTTP Server 11gの新しいインスタンス( Oracle HTTP Serverの新しいインスタンスをインストールしない場合、Oracle Access Manager 10g移行の一環で利用可能なOracle HTTP Serverインスタンスを使用できます。 |
|
|
4 |
新しい11g WebGateをインストールし、Access Manager 11.1.2.3.0サーバーおよびDCCまたはECCと連携するように構成します。
|
「オプション: WebGate 11g-1のインストールと構成」を参照してください。 |
|
5 |
既存の10g Webgatesを使用するか、3つのWebGate:
|
「オプション: WebGate 10gのインストールと構成」を参照してください。 |
|
6 |
Access Manager 11.1.2.3.0サーバーで共存モードを有効化します。 |
|
|
7 |
WebGateとAccess Manager 11.1.2.3.0サーバーの両方でログアウトが機能するようにログアウト設定を構成します。 |
「ログアウト設定の構成」を参照してください。 |
|
8 |
SSLおよび非SSLアプリケーションの混在を保護する追加の手順を実行します。 |
|
|
9 |
構成を確認します。 |
「構成の確認」を参照してください。 |
次の前提条件を完了してから、Oracle Access Manager 10gサーバーとAccess Manager 11.1.2.3.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 Access Manager 10gのリリースが共存をサポートしていることを確認します。Oracle Access Manager 10gとAccess Manager 11.1.2.3.0の共存がサポートされている開始ポイントの詳細は、第1.4項「移行および共存がサポートされている開始ポイント」を参照してください。
すべての保護されているリソースの認証レベルは、認証スキームに関係なく同じであることを確認します。たとえば、図9-1では、Resource A、BおよびCの認証レベルは同じである必要があり、同じでない場合、ユーザーは、異なる認証レベルを持つリソースへのアクセスを試みるときに、再度資格証明を入力する必要があります。
Oracle Access Manager 10gおよびAccess Manager 11.1.2.3.0サーバーが起動して動作していることを確認します。
Access Manager 11.1.2.3.0でユーザー・アイデンティティ・ストアを構成します。ユーザー・アイデンティティ・ストアの構成の詳細は、第9.7.1項「Access Manager 11.1.2.3.0でのユーザー・アイデンティティ・ストアの構成」を参照してください。
Oracle Access Manager 10gサーバーと共存モードで実行するすべてのAccess Manager 11.1.2.3.0サーバーにJDK 6またはJDK 7をインストールします。
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ファイルを配置します。
Access Manager 11.1.2.3.0にユーザー・アイデンティティ・ストアを構成する場合、次のタスクを完了する必要があります。
Oracle Access Manager 10gおよびAccess Manager 11.1.2.3.0サーバーが同じユーザー・ストアを共有していることを確認します。
共有されているデータ・ストアをデフォルトのデータ・ストアとしてマークします。
1つの認証モジュールと、認証モジュールに対応する1つの認証スキームを作成します。
これを行うには、次の手順を実行します。
次のURLを使用してOracle Access Management 11.1.2.3.0コンソールにログインします。
http://host:port/oamconsole
このURLの内容は、次のとおりです。
hostは、Oracle Access Managerコンソール(管理サーバー)をホストするマシンの完全修飾ドメイン名を表します。
portは、Oracle Access Management 11.1.2.3.0コンソールの指定されたバインド・ポートを表します。これは管理サーバーのバインド・ポートと同じです。
「構成」で、「ユーザー・アイデンティティ・ストア」をクリックします。
場所またはホスト情報がAccess Manager 11.1.2.3.0サーバーを指すユーザー・アイデンティティ・ストアを作成します。ユーザー・アイデンティティ・ストアの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の新しいユーザー・アイデンティティ・ストアの登録に関する説明を参照してください。
「ユーザー・アイデンティティ・ストア」ページで、「デフォルト・ストア」から、作成したユーザー・アイデンティティ・ストアを選択します。OAM10gユーザー・ストアをAccess Manager 11gのデフォルト・ストアとして設定することをお薦めします。
「適用」をクリックします。
Oracle Access Managementの「起動パッド」で、Access Managerの「認証モジュール」をクリックします。認証モジュールのリストが表示されます。
新しいLDAP認証モジュールを作成し、ユーザー・アイデンティティ・ストアを更新して、前の手順で作成したものを指すようにします。
認証モジュールに対応する新しい認証スキームを作成します。
認証スキームの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の認証スキームの作成に関する項を参照してください。
Oracle HTTP Server 11g (図9-1に示されているOHS-1)をインストールして構成します。あるいは、Oracle Access Manager 10gからAccess Manager 11.1.2.3.0への移行後に存在するOracle HTTP Serverインスタンスを使用できます。
Oracle HTTP Serverのインストールの詳細は、『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド 11gリリース1 (11.1.1.9.0)』を参照してください
Webサーバー: Oracle HTTP Server (OHS)、Oracle Traffic DirectorおよびApache 2に、11g WebGateをインストールできます。この章で検討するサンプル・トポロジでは、すべてのWebGateがOHSにインストールされているものとします。
11g WebGateを共存モードで動作するように有効化するには、11g Resource WebGateを、個別のDCCおよびリソースWebGateとしてDCC対応の11g WebGateと連携するように構成する必要があります。
リソースを保護する11g WebGateをインストールして、DCCと連携するように構成します。このWebGateは、リソースWebGateと呼ばれます。Access Manager 11.1.2.3.0サーバーは、リソースWebGateから受信する認証リクエストをDCCにリダイレクトして、認証を収集し処理します。図9-1に示すように、Oracle HTTP Server 11g (OHS-1)に11g WebGateの新しいインスタンスをインストールし、それをAccess Manager 11.1.2.3.0サーバーで構成します。11g WebGateのインストールとAccess Manager 11.1.2.3.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および認証ポリシーの構成に関する説明を参照してください。
|
注意:
|
共存環境を設定するための既存の10g WebGateインスタンスを使用するか、新しい10g WebGateインスタンスをインストールできます。
新しいWebGateインスタンス(WebGate 10g-1とWebGate 10g-2)をインストールする場合、それらを次のように構成する必要があります。
WebGate 10g-1: 図9-1に示すように、10g WebGateをOracle HTTP Server 11g (OHS-2)にインストールして、Access Manager 11.1.2.3.0サーバーで構成する必要があります。
10g WebGateのインストールとAccess Manager 11.1.2.3.0サーバーでの構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Manager 11gに対する最新の10g WebGateの検索とインストールに関する項を参照してください。
10g WebGateとAccess Manager 11.1.2.3.0サーバーを使用すると、10g WebGateはリソースWebGateとして動作し、必ず認証WebGateとして機能する11g資格証明コレクタにリダイレクトします。10g WebGateを、Access Manager 11.1.2.3.0サーバーまたは外部資格証明コレクタ(DCC)として構成されている11g WebGateにインストールされているデフォルトの埋込み資格証明コレクタ(ECC)と連携するように構成できます。ECCおよびDCCの詳細は、『Oracle Fusion Middleware Oracle Access Manager管理者ガイド』のAccess Managerの資格証明コレクションとログインの概要に関する説明を参照してください。
WebGate 10g-2: 図9-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.3.0による10g WebGateの管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のAccess Manager 11gによる10g WebGateの登録および管理に関する項を参照してください。
|
注意: Oracle Access Manager 10gサーバーまたはAccess Manager 11.1.2.2.0サーバーで構成されているすべての10g WebGateは、同じプライマリCookieドメインを持つ必要があります。プライマリcookieドメインが設定されていない、および11g WebGateのみで続行している場合、10gのホストベースのObSSOCookieがタイムアウトになる可能性があるので、保護されたリソースにアクセスするにはOracle Access Manager 10g Serverで再認証する必要がある場合があります。 |
次のWebLogic Scripting Toolコマンドを実行して、Access Manager 11.1.2.3.0サーバーの各インスタンスを、Oracle Access Manager 10gサーバーで共存モードで実行するように構成します。
ORACLE_HOME/common/binから次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合: ./wlst.sh
Windowsの場合: wlst.cmd
次のコマンドを実行して、WebLogic管理サーバーに接続します。
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')
次のコマンドを実行して、ドメイン・ランタイムMBean階層に移動します。
domainRuntime()
次のコマンドを実行して、Oracle Access Manager 10gサーバーの構成ストアの情報を指定し、ObSSOCookieドメインを設定します。
setCoexistenceConfigWith10G(ldapUrl="ldap_URL",ldapPrinciple="ldap_principle",ldapConfigBase="ldap_configbase",coexCookieDomain="coex_cookie_domain")
このコマンドでは、次のように指定します。
ldap_URLは、Oracle Access Manager 10gデプロイメントで使用される構成ストアのLDAPホストおよびポートです。
ldap_principleは、構成ストアの管理者のLDAP DNです。
ldap_configbaseは、Oracle Access Manager 10gデプロイメントの構成ストアのLDAP検索ベースです。
coex_cookie_domainは、10g認証WebGateのWebサーバーまたはWebGateドメインです。DCCによって設定されているObSSOCookieは、Oracle Access Manager 10gサーバーにフローする必要があるため、10g WebGateの認証ドメインを知っておくことが重要です。
例: setCoexistenceConfigWith10G(ldapUrl="ldap://oidhost.example.com:3689",ldapPrinciple="cn=oamadmin",ldapConfigBase="dc=com,dc=example,dc=abc",coexCookieDomain=".example.com")
要求された場合にはLDAP管理者のパスワードを入力します。
LDAP管理者のパスワードを入力します。
次のコマンドを実行して、Access Manager 11.1.2.3.0サーバーを、Oracle Access Manager 10gで共存モードで実行できるように構成します。
enableOamAgentCoexistWith10G()
Access Manager 11.1.2.3.0サーバーを再起動します。
前述の手順を繰り返して、Access Manager 11.1.2.3.0サーバーの各インスタンスを、Oracle Access Manager 10gサーバーで共存モードで実行するように構成します。
WebGate 10gは、logout.htmlファイルを使用してセッションをクリアします。WebGate 10g-1をAccess Manager 11.1.2.3.0サーバーで登録するときに生成されるlogout.htmlファイルを変更して、ファイルのSERVER_LOGOUTURLパラメータがAccess Manager 11.1.2.3.0サーバーのログアウトURLに指すように更新します。共存モードで構成されているAccess Manager 11.1.2.3.0サーバーは、リクエスト・ヘッダーから両方のCookie (OAMAuthnCookieおよびObSSOCookie)を削除します。
次の手順を実行して、WebGate 10g-1をAccess Manager 11.1.2.3.0サーバーで登録するときに生成されるlogout.htmlファイルを変更します。
次の例に示すように、logout.htmlファイルの変数SERVER_LOGOUTURLを、ログアウトURLに設定します。
ECCを使用した共存が有効な場合:
var SERVER_LOGOUTURL="http://OHS-2_host:OHS-2_port/oam/server/logout"
このURLの内容は、次のとおりです。
OHS-2_hostは、OHS-2が動作しているホストです。
OHS-2_portはOHS-2のポートです。
DCCを使用した共存が有効な場合:
var SERVER_LOGOUTURL="http://dcc_host:dcc_port/oamsso-bin/logout.pl
オプション: ユーザーにログアウト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.3.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.3.0サーバーのログアウトURLにリダイレクトします。そのため、WebGate 10g-1は、リクエストをAccess Manager 11.1.2.3.0サーバーに転送します。Access Manager 11.1.2.3.0サーバーは、すべてのセッションを消去します。
Oracle Access Manager 10gデプロイメントでは、一部がSSL (HTTPS)で、それ以外は非SSL (HTTP)を介する混在したアプリケーションを保護することができます。このようなデプロイメント・シナリオでは、シングル・サインオン(SSO)がSSLおよび非SSLアプリケーション間で壊されない方法で、共存がサポートされることが非常に重要です。そのため、このようなシナリオでは、ObSSOCookieがSSLおよび非SSLアプリケーションの両方で使用可能なことを保証するための、追加の構成が必要です。
DCCおよびDCCトンネリング・ベースのアプローチでは、共存のためのObSSOCookieセットがobssoCookieCoExConfigパラメータにより管理されます。ObSSOCookieをセキュアではないと設定するには、次の手順に従います。
Access Manager 11.1.2.3.0デプロイメントで共存のために使用するDCCまたはDCCトンネリングWebGateを探します。
この11g WebGateでは、ユーザー定義のパラメータ・セクションに、次の新しいユーザー定義のパラメータを追加します。
obssoCookieCoExConfig=disableSecure
変更を保存します。
ユーザー定義のWebGateパラメータの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のユーザー定義のWebGateパラメータに関する項を参照してください。
構成を確認するには、次の手順を実行します。
WebGate 10g-1によって保護されているリソースにログインしてアクセスします。
WebGate 10g-2またはWebGate 11g-1で保護されているリソースへのアクセスを試みます。サーバーが正常に共存モードで動作するように構成されると、ユーザー資格証明を再度入力しなくても、これらのWebGateで保護されているリソースにアクセスできるようになります。
ログアウトを開始し、リソースにアクセスして、すべてのWebGateからログアウトされるかどうかを確認します。リソースにアクセスする場合、ユーザー資格証明を再度入力するよう求められます。
Oracle Access Manager 10gサーバーのすべてのアーティファクトをAccess Manager 11.1.2.3.0サーバーに移行すると、Oracle Access Manager 10gサーバーを廃止して、共存モードのAccess Manager 11.1.2.3.0サーバーの実行を停止できます。Oracle Access Manager 10gアーティファクトの移行の詳細は、第2章「Oracle Access Manager 10g環境の移行」を参照してください。
IAM_HOME/common/binから次のコマンドを実行して、WebLogic Scripting Tool (WLST)を起動します。
UNIXの場合:
./wlst.sh
Windowsの場合:
wlst.cmd
Access Manager 11.1.2.3.0サーバーで次のWLSTコマンドを実行して、Oracle Access Manager 10gによる共存モードのAccess Manager 11.1.2.3.0サーバーの実行を停止します。
disableOamAgentCoexistWith10G()
Access Manager 11.1.2.3.0サーバーを再起動します。
64ビットAESキーを使用するOracle Access Manager 10gサーバーは共存モードをサポートしていません。
共存モードでは、Access Manager 11.1.2.3.0サーバーは128ビット、192ビットまたは256ビットのAES鍵(JVMでサポートされている)を必要とします。Oracle Access Manager 10gサーバーをインストールする場合、暗号化のための256ビットAESキーがデフォルトで生成されます。アクセス・システム・コンソールでこのキーを再生成すると、64ビット・キーが生成されます。JVMは64ビットAESキーをサポートしていないため、Access Manager 11.1.2.3.0サーバーは、64ビットAESキーを使用するOracle Access Manager 10gサーバーで共存モードで動作することはできません。
この問題を回避するには、このAES鍵をLDAPから削除し、Oracle Access Manager 10gサーバーで256ビット鍵を再生成します。
AES鍵を削除するには、次の手順を実行します。
Oracle Access Manager 10gサーバーのLDAP構成を、LDAPブラウザで開きます。
「Oblix」 > 「encryptionKey」 > 「cookieEncryptionKeyノード」 に移動します。
「cookieEncryptionKeyノード」を右クリックし、「削除」をクリックします。鍵が削除されます。
256ビット鍵をOracle Access Manager 10gサーバーで再生成するには、次の手順を実行します。
Oracle Access Manager 10gサーバーおよびアイデンティティ・サーバーを再起動します。
次のURLのリンクをクリックします。
http://host:port/identity/oblix
|
注意: /identity/oblixは保護されているとみなされます。 |
有効な資格証明を使用してログインします。
鍵が生成されます。生成された鍵をLDAPブラウザで表示できます。
Access Manager 11.1.2.3.0サーバーを再起動して共存モードを構成します。
