3 IAMエンタープライズ・デプロイメントについて

コモディティ・ハードウェアへのOracle Identity and Access Managementトポロジのデプロイについて学習します。これらのトポロジは、標準的なエンタープライズ・デプロイメントについてで説明した概念の具体的な参照用実装です。

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

プライマリおよび独自構築のエンタープライズ・デプロイメント・トポロジについて

Oracle Identity and Access Managementには、2つのプライマリ参照用トポロジがあります。各トポロジにインストールされるコンポーネントは同じですが、組織に対してインストールおよび構成するOracle Identity and Access Managementトポロジは厳密には異なる場合があります。

このガイドには、これらのトポロジをインストールおよび構成する方法が、順を追って記載されています。

各トポロジにインストールされるコンポーネントは同じです。異なる点は、1つのデプロイメントは少数の特定サーバーに集中しており、もう1つのデプロイメントは多数の小規模マシンに分散されていることです。

インストールおよび構成プロセスを単純にするために、このガイドではIAMデプロイメント・ウィザードを使用します。ウィザードでトポロジのレイアウト方法を設定すると、トポロジが自動的に構成されます。

デプロイメントの作成後、このガイドでは、デプロイメントを拡張して、使用するIAM製品を追加する方法を説明します。このドキュメントで説明する手順は、すべてのIAM製品に該当するわけではありません。このガイドで説明するステップは、追加を希望する他のIAM製品に簡単に適用できます。

分散ハードウェアでのOracle Identity and Access Managementのダイアグラム

この項のトポロジの例は、8ノードの分散トポロジを表しています。

このトポロジでは、ソフトウェアが8つのホスト(Web層に2つ、アプリケーション層に4つ、ディレクトリ・サービスに2つ)の間で分散されています。

このトポロジは、比較的性能が低いが作成や管理が容易な仮想マシン(VM)を使用している場合に標準的なデプロイメントです。独自の専用ホストに、Oracle Access Management、Oracle Identity Governance、ディレクトリ・サービスなどの主要コンポーネントをデプロイします。

次の図は、Oracle Identity and Access Managementトポロジを示しています。ダイアグラムではコンポーネントが完全に分離して示されます。使用するハードウェアを少なくする場合は、必要に応じてコンポーネントをまとめて配置できます。各ホストのシステム要件の詳細は、「ホスト・コンピュータのハードウェア要件」を参照してください。

図3-1 Oracle Identity and Access Managementトポロジ

図3-1の説明が続く
「図3-1 Oracle Identity and Access Managementトポロジ」の説明

プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

プライマリ・エンタープライズ・デプロイメント・トポロジは、Oracle Identity and Access Managementの主要なOracle参照トポロジです。これは、高可用性と拡張性の両方を備えたソリューションを提供します。

製品の分離

IAMデプロイメントは、複数のコンポーネントから構成されています。次のコンポーネントが含まれます。

  • Webサーバー
  • WebLogicアプリケーション・サーバー
  • LDAP
  • データベース

Oracle Identity and Access Managementのコンポーネントは、IAMAccessDomainおよびIAMGovernanceDomainの2つのドメインに分割されています。製品は次のように配置されています。

  • IAMAccessDomainには、Oracle Access Management (OAM)が含まれます。
  • IAMGovernanceDomainには、Oracle Identity Governanceが含まれます。
  • OHSDomainがOracle HTTPサーバーのホストに使用されます。
  • OUDSMのデプロイ時にOUDSMDomainが使用されます。

このように分割されているのは、各コンポーネントで要求される操作要件および可用性要件が異なるためです。通常、IAMAccessDomain内のコンポーネントの可用性要件は、IAMGovernanceDomain内のコンポーネントより高くなります。これらのコンポーネントを分離することによって、可用性要件を別々に管理できます。アクセス・コンポーネントとは関係なくガバナンス・コンポーネントにパッチを適用でき、アクセス・コンポーネントに影響を与えずにガバナンス・インスタンスを停止できます。Oracle Identity and Access Management 12cから、Oracle Access ManagerとOracle Identity Governanceを同じドメイン内に保持することはできません。

前述のドメインに加えて、Oracle Unified Directoryはドメインなしでデプロイされます。

この分離による更なる利点は、トポロジをモジュラ形式で構築できることです。ディレクトリから開始してアクセス・コンポーネントに拡張し、後でガバナンス・コンポーネントに拡張すると、これらを接続しないかぎり、デプロイされているソフトウェア、または既存のコンポーネントの構成に影響を与えません。

ディレクトリ層の理解

ディレクトリ層は、LDAP対応ディレクトリがインストールされている2つ以上の物理ホスト・コンピュータで構成されています。通常、これはOracle Unified Directory (OUD)です。

多くの場合、ディレクトリ層はデータ層に結合されています。

このリリースのエンタープライズ・デプロイメント・ガイドでは、3つの異なるLDAPディレクトリをサポートしています。このディレクトリを初めて作成するか、または組織内の既存のディレクトリを使用できます。Oracle Unified Directory (OUD)ディレクトリがサポートされます。

選択するディレクトリは組織によって異なります。

Oracle Unified Directory保証レプリケーションについて

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のロード・バランサ仮想サーバー名のサマリー

サーバー上のロードをバランシングして高可用性を実現するには、ハードウェア・ロード・バランサが必要です。可用性を最大化するために、このハードウェア・ロード・バランサは冗長ハードウェアに存在する必要があります。ハードウェア・ロード・バランサは、一連の仮想サーバー名を認識するように構成する必要があります。

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デプロイメントへの単一エントリ・ポイントにすることも可能です。

  • 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にアクセスできる必要があります。

  • igdinternal.example.com - この仮想サーバー名は、カバナンス・ドメイン内のアプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。この仮想サーバーは、Oracle OIM SuiteおよびOracle SOA Suiteの両方の内部通信で使用されます。

    クライアントからこの仮想サーバーへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

    igdinternal.example.com:7777

  • idstore.example.com - この仮想サーバー名はすべての受信アイデンティティ・ストア・トラフィックに使用されます。これは、LDAPディレクトリ・インスタンスへのアクセス・ポイントとして機能します。この仮想サーバーは、インターネットには公開されません。

    クライアントからこの仮想サーバーへのトラフィックは、使用するLDAPディレクトリのタイプに応じて、SSL対応の場合とそうでない場合があります。通常、これはOracle Unified Directoryに対してはSSL非対応になります。クライアントはこの仮想サーバー名を使用してこのサービスにアクセスし、リクエストがLDAPインスタンスに転送されます。

  • oam.example.com:5575 - これはマルチ・データセンター・デプロイメントでのみ使用される追加のロード・バランサ仮想ホストです。この仮想ホストはリクエストをOAM管理対象サーバー上のOracle Access Management (OAM)プロキシ・ポートにルーティングします。たとえば、5575です。

アプリケーション層ホストの管理対象サーバーとクラスタのサマリー

アプリケーション層は、Oracle WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをホストします。

選択したコンポーネントに応じて、Oracle Identity and Access Management用のOracle WebLogic Serverドメインは、表3-1に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。

表3-1 ドメインのクラスタおよび管理対象サーバー

ドメイン クラスタ 管理対象サーバー

IAMAccessDomain

Oracle Access Manager

oam_server1、oam_server2

Oracle Policy Manager

oam_policy_mgr1、oam_policy_mgr2

IAMGovernanceDomain

Oracle Identity Governance

oim_server1、oim_server2

Oracle SOA Suite

soa_server1、soa_server2

Oracle Web Services Manager

WLS_WSM1、WLS_WSM2

パスワードを忘れた場合の機能について

Oracle 11gでは、パスワードをリセットするメカニズムはOracle Identity Governanceから提供されていました。Oracle 12cでは、2つのオプションがあり、Oracle Access Management (OAM)とOracle Identity Governance (OIG)を統合するか、Oracle Access Managementを使用します。

  • Oracle Access Management (OAM)とOracle Identity Governance (OIG)の統合:

    このシナリオでは、ユーザーは初めてサインインするときに、OIGに格納される複数のチャレンジ質問を設定できます。ユーザーがパスワードを忘れた場合は、チャレンジ質問に回答できます。チャレンジ質問に正しく解答できれば、OIGを使用してパスワードをリセットするオプションが提供されます。

  • Oracle Access Management:

    このシナリオでは、OAMはOracle User Messaging Serviceに接続します。各ユーザーは、電話番号または電子メール・アドレスのいずれかに関連付けられます。ユーザーがパスワードを忘れた場合のリンクをリクエストすると、ワンタイムPINが送信され、これをアプリケーションに入力してパスワードをリセットできます。

このガイドでは、両方のシナリオを設定する方法について説明します。

Oracle LDAP、Oracle Access ManagerおよびOracle Identity Governanceの統合

Oracle Identity ManagerおよびOracle Access ManagerとLDAPディレクトリの統合は、LDAPコネクタを使用して行われます。

ユーザーの無効化または終了時にユーザー・セッションの終了を有効にするには、LDAPコネクタの12.2.1.3バージョンをダウンロードします。

この項では、LDAP用のOracleコネクタを取得、インストールおよび構成する方法について説明します。

Oracleコネクタについて

Oracleコネクタについて

LDAPコネクタは、Identity Connector Framework (ICF)を使用して実装されます。ICFは、すべてのOracle Identity Managerコネクタに共通の基本的なリコンシリエーションおよびプロビジョニング操作を提供するコンポーネントです。ICFは、Oracle Identity Managerに付属しています。したがって、ICFを構成したり変更する必要はありません。

LDAPコネクタはJNDIを使用してターゲット・システムにアクセスします。このコネクタは、次のモードのいずれかで実行されるように構成できます。

  • アイデンティティ・リコンシリエーション: アイデンティティ・リコンシリエーションは、認可ソースまたは信頼できるソースのリコンシリエーションとも呼ばれます。この形式のリコンシリエーションでは、ターゲット・システムでのユーザーの作成または更新に対応してOIMユーザーが作成または更新されます。

    ノート:

    アイデンティティ・リコンシリエーション・モードでは、ユーザー・オブジェクトのリコンシリエーションのみがサポートされます。
  • アカウント管理: アカウント管理は、ターゲット・リソース管理とも呼ばれます。このモードのコネクタでは、プロビジョニングとターゲット・リソースのリコンシリエーションが有効化されます。

プロビジョニング

プロビジョニングでは、Oracle Identity Managerを使用して、ターゲット・システムでユーザー、グループ、ロールおよび組織単位(OU)を作成、更新または削除します。

ターゲット・システム・リソースをOIMユーザーに割り当てる(プロビジョニングする)と、この操作によって、ターゲット・システムにそのユーザーのアカウントが作成されます。Oracle Identity Manager関連では、プロビジョニングという用語は、Oracle Identity Managerを使用したターゲット・システム・アカウントに対する更新(有効化または無効化など)を意味する場合にも使用されます。

ユーザーおよび組織は、ターゲット・システムで階層形式に編成されます。ターゲット・システムで必要な組織単位(OU)にユーザーをプロビジョニングする(ユーザーを作成する)には、ターゲット・システムで使用されるOUのリストをOracle Identity Managerにフェッチする必要があります。これは、参照同期のためのLDAP Connector OU Lookup Reconciliationスケジュール済ジョブを使用して行います。

同様に、ターゲット・グループの必須グループまたはロールにユーザーをプロビジョニングするには、事前にターゲット・システムで使用されるすべてのグループとロールのリストをOracle Identity Managerにフェッチする必要があります。これは、参照同期のためのLDAP Connector Group Lookup ReconciliationおよびLDAP Connector Role Lookup Reconスケジュール済ジョブを使用して行います。

ターゲット・リソースのリコンシリエーション

ターゲット・リソースのリコンシリエーションを実行するには、LDAP Connector User Search ReconciliationまたはLDAP Connector User Sync Reconciliationスケジュール済ジョブが使用されます。コネクタは、フィルタを適用してターゲット・システムからリコンサイルされるユーザーを検索し、それらのユーザーの属性値をフェッチします。

リコンサイルしようとするデータに応じて様々なスケジュール済ジョブを使用します。たとえば、LDAP Connector User Search Reconciliationスケジュール済ジョブを使用して、ターゲット・リソース・モードでユーザー・データをリコンサイルします。

Oracle LDAPコネクタは、Oracle Identity Managerにローカルにデプロイすることも、コネクタ・サーバーにリモートにデプロイすることもできます。コネクタ・サーバーを使用すると、アイデンティティ・コネクタをリモートで実行することができます。このガイドでは、コネクタをOracle Identity Managerにローカルにインストールおよび構成するステップを示します。

プライマリIAM Suiteトポロジの実装のロードマップ

表3-2に、コモディティ・ハードウェアでのプライマリIAM Suiteトポロジの実装のロードマップを示します。

表3-2 コモディティ・ハードウェアでのプライマリIAM Suiteトポロジの実装のロードマップ

シナリオ タスク 詳細の参照先

コモディティ・ハードウェアでのIAMエンタープライズ・デプロイメントの手動作成

標準的なエンタープライズ・デプロイメントの理解、およびプライマリ・デプロイメント・トポロジの確認。

エンタープライズ・デプロイメントの概要

標準的なエンタープライズ・デプロイメントについて

IAMエンタープライズ・デプロイメントについて

マルチデータ・センター・デプロイメントについて

ハードウェアおよびソフトウェアの要件の確認、およびエンタープライズ・デプロイメント用のリソースの取得。

エンタープライズ・デプロイメント用のリソースの取得

ロード・バランサとファイアウォールの準備。

エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

記憶域の準備、およびディレクトリ構造の理解。

エンタープライズ・デプロイメント用のファイル・システムの準備

ホスト・コンピュータの構成。

エンタープライズ・デプロイメント用のホスト・コンピュータの準備

データベースを準備します。

エンタープライズ・デプロイメント用のデータベースの準備

Oracle LDAPを構成します。

エンタープライズ・デプロイメント用のOracle LDAPの構成

Oracle Access Management用のOracle Fusion Middleware Infrastructureの作成。

Oracle Access Managementのインフラストラクチャの作成

Oracle Identity Governance用のOracle Fusion Middleware Infrastructureの作成。

Oracle Identity Governanceのインフラストラクチャの作成

Oracle HTTP Serverの構成

エンタープライズ・デプロイメント用のOracle HTTP Serverの構成

Oracle Access Management (OAM)の構成。

Oracle Access Managementの構成

Oracle Identity Governance (OIG)または(OIM)の構成。

Oracle Identity Governanceの構成

サーバー移行設定の構成。

エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

シングル・サインオン(SSO)の構成。

エンタープライズ・デプロイメント用のシングル・サインオンの構成

独自のOracle Identity and Access Managementトポロジの構築

これらの段階的な手順は、Oracle Identity and Access Managementの2つのプライマリ・エンタープライズ・トポロジの構成に役立ちます。ただし、お客様が購入するOracle Fusion Middleware製品セットやデプロイするアプリケーションのタイプによって、組織の要件が異なる場合があります。

Oracle Identity and Access Managementのプライマリ・エンタープライズ・トポロジの詳細は、図3--1を参照してください。

多くの場合、代替トポロジ(追加コンポーネントを含むトポロジ、またはプライマリ・トポロジ・ダイアグラムに示したOracle Identity and Access Management製品の一部を含まないトポロジ)のインストールおよび構成が可能です。

このガイドのステップを使用して実装できるOracle Identity and Access Managementの参照トポロジのいくつかの代替トポロジは次のとおりです:

  • 既存のディレクトリのみを含むOAM

  • 既存のディレクトリのみを含むOIM

  • モジュラ・デプロイメントに統合されたOAM/OIM

  • 既存のディレクトリと統合されたOAM/OIM

サービスまたはサーバー移行によるエンタープライズ・トポロジの高可用性化について

Oracle Identity Governance製品およびコンポーネントの高可用性を実現するために、このガイドでは、参照用トポロジの一部として作成するOracle Identity ManagerおよびOracle SOA Suiteのクラスタに対してOracle WebLogic Serverのサーバー全体の移行を有効にすることをお薦めします。

静的クラスタの場合、構成ウィザードの「高可用性のオプション」画面を使用して自動サービス移行を構成できます。「自動サービス移行の有効化」オプションを選択すると、自動サービス移行に必要な移行可能ターゲットの定義が構成されます。同じ画面で「JTAトランザクション・ログ永続性」オプションと「JMSサーバー永続性」オプションを使用すると、自動的にJDBCストアとして構成することができます。OIMエンタープライズ・デプロイメントで静的クラスタを構成するときには、これらのオプションを有効にすることをお薦めします。

動的クラスタの場合、移行可能ターゲットは必要ありません。自動サービス移行の一部の機能は、動的クラスタに当初から用意されているからです。構成ウィザードの「高可用性のオプション」画面は、動的クラスタでは使用しませんが、リースと永続ストアの移行ポリシーを構成するには、追加のステップが必要です。OIMエンタープライズ・デプロイメントで動的クラスタを構成するときには、これらの事後のステップを実行することをお薦めします。

詳細は、「エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用」を参照してください。