| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.3.0) E61956-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.3.0) E61956-03 |
|
前 |
次 |
この章では、コモディティ・ハードウェアでのOracle Identity and Access Managementデプロイメント・トポロジについて概説します。これらのトポロジは、第1章「標準的なエンタープライズ・デプロイメントの理解」で説明した概念の具体的な参照用実装です。
この章のトピックは、次のとおりです:
このガイドでは、Oracle Identity and Access Managementの2つのプライマリ参照用トポロジを中心に説明しています。各トポロジにインストールされるコンポーネントは同じです。異なる点は、1つのデプロイメントは少数の特定サーバーに集中しており、もう1つのデプロイメントは多数の小規模マシンに分散されていることです。
組織でインストールおよび構成するOracle Identity and Access Managementトポロジは、正確にはこの2つのプライマリ・トポロジと異なる可能性がありますが、このガイドでは、これらのトポロジをインストールして構成するための詳細な手順を説明します。インストールおよび構成プロセスを単純にするために、このガイドではIAMデプロイメント・ウィザードを使用します。ウィザードでトポロジのレイアウト方法を設定すると、トポロジが自動的に構成されます。
デプロイメントの作成後、このガイドでは、デプロイメントを拡張して使用を希望するIAM製品を追加する方法を説明します。このドキュメントで説明する手順は、すべてのIAM製品に該当するわけではありません。このガイドで説明する手順は、追加を希望する他のIAM製品に簡単に適用できます。
次の項では、2つのプライマリOracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジのダイアグラムを示します。
図2-1は、Oracle HTTP Serverを含む4ノードのトポロジのダイアグラムを示しています。
このトポロジでは、限定された数のホスト(Web層に2台、アプリケーション層に2台)でソフトウェアが統合されています。アプリケーション層の各ホストに、Oracle Access ManagementとOracle Identity Managerの両方をデプロイします。
このトポロジは、比較的強力な物理ホスト・コンピュータを使用している場合に標準的なデプロイメントです。各ホストのシステム要件の詳細は、第5.1.2項「ホスト・コンピュータのハードウェア要件」を参照してください。
図2-2は、8ノードの分散トポロジのダイアグラムを示しています。
このトポロジでは、ソフトウェアが8つのホスト(Web層に2つ、アプリケーション層に4つ、ディレクトリ・サービスに2つ)の間で分散されています。
このトポロジは、比較的性能が低いが作成や管理が容易な仮想マシン(VM)を使用している場合に標準的なデプロイメントです。独自の専用ホストに、Oracle Access Manager、Oracle Identity Manager、ディレクトリ・サービスなどの主要コンポーネントをデプロイします。
各ホストのシステム要件の詳細は、第5.1.2項「ホスト・コンピュータのハードウェア要件」を参照してください。
この項では、プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて説明します。
この項では、次の項目について説明します。
IAMデプロイメントは、複数のコンポーネントから構成されています。次のコンポーネントが含まれます。
Webサーバー
WebLogic
LDAP
データベース
図2-1および図2-2は、各コンポーネント間の分離を示しています。Oracle Identity and Access Managementのコンポーネントは、IAMAccessDomainおよびIAMGovernanceDomainの2つのドメインに分割されています。製品は次のように配置されています。
IAMAccessDomainには、Oracle Access Manager、Oracle Mobile Security Suite、Oracle Adaptive Access Managerが含まれます。
IAMGovernanceDomainには、Oracle Identity Manager、Oracle Business Intelligence、Oracle Privileged Account Mangerが含まれます。
このように分割されているのは、各コンポーネントで要求される操作要件および可用性要件が異なるためです。通常、IAMAccessDomain内のコンポーネントの可用性要件は、IAMGovernanceDomain内のコンポーネントより高くなります。これらのコンポーネントを分離することによって、可用性要件を別々に管理できます。アクセス・コンポーネントとは関係なくガバナンス・コンポーネントにパッチを適用でき、アクセス・コンポーネントに影響を与えずにガバナンス・インスタンスを停止できます。
この分離は、多くの場合Web層およびアプリケーション層のコンポーネントとは別の時点にリリースされるディレクトリ層にも拡張できます。ディレクトリの分離によって、ドメインの分割と同様の利点(独立したアップグレードやパッチ適用など)を得られます。
この分離による更なる利点は、トポロジをモジュラ形式で構築できることです。ディレクトリから開始してアクセス・コンポーネントに拡張し、後でガバナンス・コンポーネントに拡張すると、これらを接続しないかぎり、デプロイされているソフトウェア、または既存のコンポーネントの構成に影響を与えません。
ディレクトリ層は、LDAP対応ディレクトリがインストールされている2つの物理ホスト・コンピュータで構成されています。通常、これはOracle Internet Directory (OID)またはOracle Unified Directory (OUD)です。
多くの場合、ディレクトリ層はデータ層に結合されています。
このリリースのエンタープライズ・デプロイメント・ガイドでは、3つの異なるLDAPディレクトリをサポートしています。これらのディレクトリを最初に作成するか、または組織内の既存のディレクトリを使用できます。サポートされているディレクトリは次のとおりです。
Oracle Unified Directory (OUD)
Oracle Internet Directory(OID)
Microsoft Active Directory (AD)
選択するディレクトリは組織によって異なります。
Oracle Unified Directoryサーバー・インスタンスは、本来、レプリケーションを使用して、埋込みデータベースの同期状態を保持します。デフォルトでは、レプリケーションは、操作結果がアプリケーションに戻った後に更新をレプリカにレプリケーションするゆるやかな一貫性モデルを使用します。したがってこのモデルでは、データをレプリカに書き込んでから、書込みの少し後に古い情報を別のレプリカから読み取ってしまう可能性があります。レプリケーション・プロセスが高速で1ミリ秒の桁で達成できるように、Oracle Unified Directoryレプリケーションで多くの作業が行われました。
レプリカ内のデータの一貫性を保証するように開発された保証レプリケーション・モデルを使用するようにOracle Unified Directoryを構成できます。保証レプリケーションの安全読取りモードを使用すると、アプリケーションは、レプリケーション・プロセスが書込み操作の結果を返す前に完了することを保証します。
保証レプリケーションを使用すると、書込み操作の応答時間に悪影響があります。これは、保証レプリケーションではリモート・レプリカとの通信の後に操作結果を返す必要があるためです。遅延時間は、使用するネットワークおよびOracle Unified Directoryをホストしているサーバーの容量によって異なります。保証レプリケーションを使用しても、読取り操作への影響はほとんどありません。
ディレクトリへの大量の書込みを定期的に実行することが予想される場合、ロード・バランサを構成して、アクティブ/パッシブ・モードでOracle Unified Directoryインスタンスにリクエストを分散することを検討してください。こうすることによって、レプリカから古いデータ読み取る機会がなくなりますが、使用しているOracle Unified Directoryホストがすべてのリクエストを処理する能力がない場合、全体のパフォーマンスが低下する可能性があります。
このガイドの目的のために、複数のサーバーにリクエストを処理させる機能の方が保証モードでのリクエストの書込みによって生じる追加のオーバーヘッドより重要であると想定されます。この目的のために、このガイドでは、保証レプリケーションを使用したOracle Unified Directoryの構成を示します。ただし、次のOracle Unified Directoryの構成は両方ともサポートされます。
保証構成のアクティブ/アクティブ
非保証構成のアクティブ/パッシブ
詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドの保証レプリケーションに関する項を参照してください。
サーバー上のロードをバランシングして高可用性を実現するには、ハードウェア・ロード・バランサが必要です。可用性を最大化するために、このハードウェア・ロード・バランサは冗長ハードウェアに存在する必要があります。ハードウェア・ロード・バランサは、一連の仮想サーバー名を認識するように構成する必要があります。
Oracle Identity and Access Managementデプロイメントのハードウェア・ロード・バランサは、次の仮想サーバー名を認識する必要があります。
login.example.com - この仮想サーバー名はすべての受信アクセス・トラフィックに使用されます。これは、ランタイムAccess ManagementコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。
login.example.com:443
prov.example.com - この仮想サーバー名はすべての受信ガバナンス・トラフィックに使用されます。これは、ランタイム・ガバナンス・コンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。
prov.example.com:443
以前のリリースのエンタープライズ・デプロイメント・ガイドでは、login.example.comおよびprov.example.comは同じエントリ・ポイントであったことに注意してください。このリリースではこれらを分離できます。これによって、ロード・バランサからのルーティング機能が向上し、モジュラ・デプロイメントが実現して、将来のマルチ・データ・センター・デプロイメントが容易になります。必要な場合は、これら2つのエントリ・ポイントを結合して、IAMデプロイメントへの単一エントリ・ポイントにすることも可能です。
msas.example.com - この仮想サーバー名はすべての受信モバイル・セキュリティ・トラフィックに使用されます。これは、ランタイム・モバイル・セキュリティ・アクセス・サービスへのすべてのHTTPSトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。
msas.example.com:9002
iadadmin.example.com - この仮想サーバー名は、ロード・バランサ上で有効です。これは、IAMAccessDomain内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。したがって、クライアントは、次のアドレスを使用してこのサービスにアクセスします。
iadadmin.example.com:80
これは、WEBHOST1およびWEBHOST2のポート7777に転送されます。
この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Controlなどがあります。
ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがiadadmin.example.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
igdadmin.example.com - この仮想サーバー名は、ロード・バランサ上で有効です。これは、IAMGovernanceDomain内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。したがって、クライアントは、次のアドレスを使用してこのサービスにアクセスします。
igdadmin.example.com:80
これは、WEBHOST1およびWEBHOST2のポート7777に転送されます。
この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Controlなどがあります。
ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがigdadmin.example.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
iadinternal.example.com - この仮想サーバー名は、アクセス・ドメイン内のアプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。この仮想サーバーの主な用途は、Oracleモバイル・セキュリティ・マネージャへのリクエストの配信に使用されるOracle HTTP Serverとモバイル・セキュリティ・アクセス・サービスを通信可能にすること、または、この仮想サーバーを使用して、モバイル・セキュリティ・マネージャをホストするWebLogic管理対象サーバーにリクエストを直接送信することです。
クライアントからこの仮想サーバーへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。
iadinternal.example.com:7777
igdinternal.example.com - この仮想サーバー名は、カバナンス・ドメイン内のアプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。この仮想サーバーは、Oracle OIM SuiteおよびOracle SOA Suiteの両方の内部通信で使用されます。
クライアントからこの仮想サーバーへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。
igdinternal.example.com:80
idstore.example.com - この仮想サーバー名はすべての受信アイデンティティ・ストア・トラフィックに使用されます。これは、LDAPディレクトリ・インスタンスへのアクセス・ポイントとして機能します。この仮想サーバーは、インターネットには公開されません。
クライアントからこの仮想サーバーへのトラフィックは、使用するLDAPディレクトリのタイプに応じて、SSL対応の場合とそうでない場合があります。通常、Oracle Unified DirectoryおよびOracle Internet Directoryの場合はSSL対応ではなく、Microsoft Active Directoryの場合はSSL対応です。クライアントはこの仮想サーバー名を使用してこのサービスにアクセスし、リクエストがLDAPインスタンスに転送されます。
アプリケーション層は、Oracle WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをホストします。
選択したコンポーネントに応じて、Oracle Identity and Access Management用のOracle WebLogic Serverドメインは、表2-1に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。
表2-1 ドメインのクラスタおよび管理対象サーバー
| ドメイン | クラスタ | 管理対象サーバー |
|---|---|---|
|
IAMAccessDomain |
Oracle Access Manager |
wls_oam1、wls_oam2 |
|
Oracle Policy Manager |
wls_ama1、wls_ama2 |
|
|
Oracleモバイル・セキュリティ・マネージャ |
wls_msm1、wls_msm2 |
|
|
IAMGovernanceDomain |
Oracle Identity Manager |
wls_oim1、wls_oim2 |
|
Oracle SOA Suite |
wls_soa1、wls_soa2 |
|
|
Oracle Business Intelligence |
wls_bi1、wls_bi2 |
モバイル・セキュリティ・アクセス・サーバーを使用して、モバイル・セキュリティ・クライアントからのリクエストを管理します。
モバイル・クライアントは、HTTPSプロトコルを使用してロード・バランサにアクセスします。ロード・バランサは、HTTPSを使用して、それらのリクエストをモバイル・セキュリティ・アクセス・サーバーに転送します。次に、モバイル・セキュリティ・サーバーは、Oracle HTTP Serverを介してOracleモバイル・セキュリティ管理対象サーバーと相互作用します。これらのリクエストはHTTPを使用して送信されます。
図1-1「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラム」は、メインのOracle HTTP Serverに送信されるこれらのリクエストを示しています。リクエストを専用のOracle HTTP Server (Webゲートが構成されていない)に送信するか、別のロード・バランサを介してモバイル・セキュリティ管理対象サーバーに直接送信することによって、パフォーマンスを向上させることができます。
MSMが停止している間、MSASは操作を続行できます。これは、操作の切断モードと呼ばれています。このモードでは、MSASはMSMのUIまたはWLSTを介して行った管理/アーティファクト変更をプルしませんが、セキュリティは継続して強制されます。
|
注意: configMSASを実行してインスタンスを作成するとき、MSASではMSMが起動して実行中である必要があります。したがって、MSASはMSMに少なくとも1回は接続する必要があります。 |
MSASには、ローカル・ファイル・ベースの永続的なキャッシュがあります。したがって、MSASを停止して再度起動しても操作を続行できます。
認証(KINIT/PKINIT/OAuth)時には、セキュア・モバイル・コンテナとMSASを介して多数のメッセージ交換があります。認証プロセスの最終結果として、セッション・トークン(STOKEN)が作成されます。認証プロセス時はロード・バランサ・セッションがスティッキーである必要がありますが(通常は1 SSL接続)、後続のリクエストではその必要はありません。
MSASには専用の認証URLがあるため、MSAS認証URLをスティッキーに構成する必要があります。
|
注意: 認証プロセス時にロード・バランサ・セッションがスティッキーでない場合、認証が成功する保証はありません。 |
MSAS物理インスタンス全体でセッション同期が実行されます。したがって、ホスト1で実行されているMSASインスタンスで最初にSTOKEN (セッション・トークン)が作成され、後続のロード・バランシングによってモバイル・トラフィックがホスト2にルーティングされた場合、ホスト2で実行されているMSASインスタンスはSTOKENのホスト1に自動的に接続します。
|
注意: ホスト2はホスト1に少なくとも1回は接続する必要があるため(当初のSTOKENがホスト1で作成された場合)、その時点でホスト1は起動して実行中である必要があります。ただし、ホスト2がホスト1に接続した後、ホスト1は停止できます。 |
セッション同期を実行すると、再度ログインする必要があります。複数のMSAS物理インスタンスを使用したセッション同期は、HTTP(S)経由で発生します。
認証シナリオの中には、モバイル・セキュア・コネクタおよびMSASを使用する一方向SSLまたは双方向SSLが必要な場合があります。複数のMSAS物理インスタンスが同じMSASインスタンスIDを使用して構成されているかぎり(単一の論理インスタンス)、MSASでは常に、SSL証明書とキーがすべての物理インスタンスに自動的にレプリケートされます。
MSASは、MSAS物理インスタンス・レベルで障害からの自動リカバリをサポートします。MSASインスタンス(物理)を作成して実行すると、作成されたハートビート・プロセスが開始して、バックグラウンドで実行されます。このハートビート・プロセスはインスタンスに対してローカルで、MSASインスタンスを監視/pingしてインスタンスがアライブかどうかをチェックします。そうでない場合は、MSASインスタンスの再起動を試みます。MSASインスタンスを再起動する試行回数は構成可能です。ハートビート・プロセスではUDPを使用してMSASをpingします。
このガイドでは、新しいIdentity and Access Managementデプロイメント・ツールを使用します。デプロイメントを手動で作成することも可能です。デプロイメント・ツールを使用する利点は次のとおりです。
ウィザード・ドリブンのデプロイメントが容易。
EDGベスト・プラクティスがツールに組み込まれている。
エンタープライズ・デプロイメント・トポロジの高速でより信頼性のあるデプロイメント。
デプロイメント後のライフ・サイクル管理ツール(単純なパッチ適用など)へのアクセス。
デプロイメント・ツールはすべてのデプロイメントを構築するわけではありませんが、処理対象となるデプロイメントの各部分の構築を高速化できます。デプロイメント・ツールに含まれる製品の機能を超えてデプロイメントを拡張する場合は手動タスクになり、このガイドでも説明します。
表2-2に、コモディティ・ハードウェアでのプライマリIAM Suiteトポロジの実装のロードマップを示します。
表2-2 コモディティ・ハードウェアでのプライマリIAM Suiteトポロジの実装のロードマップ
| シナリオ | タスク | 詳細の参照先 |
|---|---|---|
|
コモディティ・ハードウェアでのIAMエンタープライズ・デプロイメントの手動作成 |
標準的なエンタープライズ・デプロイメントの理解、およびプライマリ・デプロイメント・トポロジの確認。 |
第2.2項「プライマリOracle Identity and Access Managementトポロジのダイアグラム」 第2.3項「プライマリOracle Identity and Access Managementトポロジ・ダイアグラムの理解」 |
|
ハードウェアおよびソフトウェアの要件の確認、およびエンタープライズ・デプロイメント用のリソースの取得。 |
第5章「エンタープライズ・デプロイメント用のリソースの取得」 |
|
|
ロード・バランサとファイアウォールの準備。 |
第6章「エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備」 |
|
|
記憶域の準備、およびディレクトリ構造の理解。 |
|
|
|
ホスト・コンピュータの構成。 |
第9章「エンタープライズ・デプロイメント用のホスト・コンピュータの構成」 |
|
|
データベースの準備。 |
第10章「エンタープライズ・デプロイメント用のデータベースの準備」 |
|
|
必要なソフトウェアのインストール。 |
第11章「エンタープライズ・デプロイメントの準備におけるOracle Fusion Middlewareのインストール」 |
|
|
Oracle LDAPの構成。 |
第12章「Identity and Access Managerエンタープライズ・デプロイメント用のOracle LDAPの構成」 |
|
|
アイデンティティ・ストアの準備。 |
|
|
|
Oracle Web Tierの構成。 |
|
|
|
WebLogicドメインの作成。 |
第15章「エンタープライズ・デプロイメント用のドメインの作成」 |
|
|
ノード・マネージャの設定。 |
第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」 |
|
|
Oracle Access Management (OAM)の構成。 |
第17章「Oracle Access Managementの構成」 |
|
|
Oracleモバイル・セキュリティ・サービス(OMSS)の構成。 |
第18章「Oracleモバイル・セキュリティ・サービスの構成」 |
|
|
Oracle Identity Manager (OIM)の構成。 |
第19章「Oracle Identity Managerの構成」 |
|
|
Oracle BI Publisher (BIP)の構成。 |
|
|
|
サーバー移行設定の構成。 |
第21章「エンタープライズ・デプロイメント用のサーバー移行の構成」 |
|
|
シングル・サインオン(SSO)の構成。 |
|
|
|
ライフ・サイクル管理ツール(IDMLCM)を使用した、コモディティ・ハードウェアでのIAMエンタープライズ・デプロイメントの作成 |
自動デプロイメント・プロセスの理解。 |
|
|
Oracle Identity and Access Managementライフ・サイクル管理ツールのインストール。 |
第24章「Oracle Identity and Access Managementライフ・サイクル管理ツールのインストール」 |
|
|
デプロイするトポロジ用デプロイメント・レスポンス・ファイルの作成。 |
|
|
|
Identity and Access Managementのデプロイ |
第26章「Identity and Access Managementのデプロイ」 |
|
|
必要なデプロイメント後のタスクの実行。 |
|
このドキュメントでは、Oracle Identity and Access Managementの2つのプライマリ・エンタープライズ・トポロジを構成する手順を説明しています。
ただし、お客様が購入するOracle Fusion Middleware製品セットやデプロイするアプリケーションのタイプによって、組織の要件が異なる場合があります。
多くの場合、代替トポロジ(追加コンポーネントを含むトポロジ、またはプライマリ・トポロジ・ダイアグラムに示したOracle SOA Suite製品の一部を含まないトポロジ)のインストールおよび構成が可能です。
次の項では、実装可能ないくつかの代替Oracle Identity and Access Managementトポロジについて、このガイドに示した手順に多少の変更を加えて説明します。詳細は、Oracle Maximum Availability Architecture (MAA)のWebサイトで入手可能なリソースを参照してください。
既存のディレクトリのみを含むOAM
OAAMのみを含むOAM
既存のディレクトリのみを含むOIM
OPAMのみを含むOIM
モジュラ・デプロイメントに統合されたOAM/OIM
既存のディレクトリと統合されたOAM/OIM
OAAMを含むOAM/OIM
OPAMを含むOAM/OIM
Oracle Identity and Access Management Suite製品およびコンポーネントの高可用性を実現するために、このガイドでは、参照用トポロジの一部として作成するOracle Identity Manager、Oracle SOA SuiteおよびOracle Business Intelligenceのクラスタに対してOracle WebLogic Serverのサーバー全体の移行を有効にすることをお薦めします。
サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。
詳細は、第21章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。
