1. Kubernetesクラスタ内のOracle Identity and Access Managementのためのエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントについて
  3. IAMエンタープライズ・デプロイメントについて

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

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

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

親トピック: エンタープライズ・デプロイメントについて

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

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

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

各トポロジにインストールされるコンポーネントは同じです。違いは、一方のデプロイメントでは、すべてのアイデンティティ管理アプリケーション層がコンテナにインストールされるのに対し、もう一方では、従来のオンプレミス・デプロイメントとコンテナにデプロイされた新しいマイクロサービスが混在する点です。

このデプロイメントで示すトポロジは、オラクル社が推奨するベストプラクティスのデプロイメントで、最大限のセキュリティと可用性が実現されます。これらのトポロジは、オラクル社が検証しています。

コンテナ化された環境にOracleをデプロイする方法はこれだけではありませんが、オラクル社が本番システムのデプロイメントに推奨する方法です。

セキュリティを最大化するため、非武装地帯(DMZ)の実装をお薦めします。

親トピック: IAMエンタープライズ・デプロイメントについて

非武装地帯の使用

非武装地帯(DMZ)を使用して、お客様の組織のセキュリティを最大化することを強くお薦めします。「非武装地帯について」を参照してください。

Kubernetesは、アプリケーションの中間層として使用すると最も強力になります。それでも、Kubernetesネットワークへのアクセスを厳密に制御するにはDMZが必要です。外部トラフィックは必ずDMZ経由でルーティングされるようにすると、悪意のある人物が内部ネットワークに侵入する可能性が低くなります。DMZ内でKubernetesネットワークの外にWebサーバーを配置することで、ネットワーク・セキュリティが最大化されます。Oracle HTTP ServerをKubernetesの内部に配置すると、Kubernetesネットワークに望ましいところより1段階、外部に近くなります。

ノート:

エンタープライズ・デプロイメントの場合、Web層は、ビジネス・アプリケーションが含まれるKubernetesクラスタ内ではなく、専用の非武装地帯の中に配置することを強くお薦めします。

Web層の非武装地帯に、別のKubernetesクラスタを作成することが可能です。ただし、高可用性Kubernetesコントロール・プレーンと複数のKubernetesワーカー・ノードが必要になるため、不要なオーバーヘッドが発生します。

オラクル社では、この方法を推奨していないため、このガイドでは、Kubernetes内にOracle Web層を組み込むシナリオについては説明しません。

親トピック: IAMエンタープライズ・デプロイメントについて

Oracle Identity and Access Managementのデプロイメントのトポロジ・ダイアグラム

Oracle Identity and Access Managementには、2種類のデプロイメント・シナリオがあります。1つは、マイクロサービスを既存のエンタープライズ・デプロイメントに追加するデプロイメントで、もう1つは、アプリケーション層全体をKubernetesクラスタ内に配置するデプロイメントです。

親トピック: IAMエンタープライズ・デプロイメントについて

追加のマイクロサービスを使用した従来のIAMデプロイメントのトポロジ・ダイアグラム

これは、スタンドアロンのオンプレミス・ハードウェアでの従来のIdentity and Access Managementデプロイメントです。このトポロジでは、ソフトウェアが8つのホスト(Web層に2つ、アプリケーション層に4つ、ディレクトリ・サービスに2つ)の間で分散されています。新しいOracle IDMマイクロサービスはKubernetesクラスタ内にデプロイされ、従来のデプロイメントでコアIDMコンポーネントと対話します。

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

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

Oracle 12c (12.2.1.4)では、マイクロサービスを使用して配信されるOracle Identity Management機能が導入されています。この機能は、従来のデプロイメント・プラットフォームの一部である既存のアイデンティティ管理機能に加えて配信されます。新しいマイクロサービスをKubernetesクラスタ内にデプロイする必要があります。従来のアイデンティティ管理コンポーネントは、Oracle Identity and Access Managementのためのエンタープライズ・デプロイメント・ガイドの説明に従って、Kubernetesクラスタまたは従来のデプロイメントのいずれかに配信できます。

このガイドでは、すべてのOracle Identity and Access ManagementコンポーネントをKubernetesクラスタ内にデプロイする方法について説明します。

Kubernetesを使い始めたばかりで、既存のエンタープライズ・デプロイメントを維持しつつ、新しいマイクロサービスでデプロイメントを拡張しようとする場合は、このガイドの手順に従って、これらのマイクロサービスのみをデプロイできます。この手順に従うことにした場合は、次の2つのオプションがあります:
  • 新しいマイクロサービスをデプロイし、既存のOracle HTTP Serverデプロイメントに統合します。

    このデプロイメント方法に従う場合は、「Oracle HTTP Serverのインストールと構成」に示されている手順を使用します。この章では、マイクロサービスを既存の仮想ホストに組み込むために追加する必要があるエントリを示します。

  • 専用のイングレス・コントローラを使用して、新しいマイクロサービスを完全にスタンドアロンでデプロイします。

    このデプロイメント方法に従う場合は、マイクロサービスごとに異なる仮想ホストを定義する必要があります。これらは、使用されているイングレス・コントローラに解決されます。

図4-1 マイクロサービスを使用したOracle Identity and Access Managementの従来のデプロイメント(Kubernetesクラスタ内)

マイクロサービスを使用したOracle Identity and Access Managementの従来のデプロイメント(Kubernetesクラスタ内)

親トピック: Oracle Identity and Access Managementのデプロイメントのトポロジ・ダイアグラム

KubernetesへのOracle Identity and Access Managementのデプロイメントのトポロジ・ダイアグラム

これは、Identity and Access Managementのすべてのコンポーネント(マイクロサービスを含む)がKubernetesクラスタ内にデプロイされた、Identity and Access Managementのデプロイメントです。

次の図は、Kubernetes内のOracle Identity and Access Managementトポロジを示しています。ダイアグラムではコンポーネントが完全に分離して示されます。このトポロジでは、適切なサイズのKubernetesクラスタを使用する必要があります。

このガイドでは、すべてのOracle Identity and Access ManagementコンポーネントをKubernetesクラスタ内にデプロイする方法について説明します。

図4-2 KubernetesクラスタへのOracle Identity and Access Managementのデプロイメント


KubernetesクラスタへのOracle Identity and Access Managementのデプロイメント

親トピック: Oracle Identity and Access Managementのデプロイメントのトポロジ・ダイアグラム

KubernetesへのOracle Identity and Access Managementコンポーネントのデプロイメントのトポロジ・ダイアグラム

この項に示すサンプル・トポロジは、内部ルーティング用のイングレス・コントローラか、個々のNodePortサービスを使用した、KubernetesクラスタへのOracle Identity and Access Managementのデプロイメントを示しています。簡潔にするために、各製品を個別のダイアグラムに分けています。

コントロール・プレーンは、Kubernetes APIサーバーがデプロイされてロード・バランサがフロントエンドになった3つのノードで構成されます。ロード・バランサは、アイデンティティ管理スイートとコントロール・プレーン自体の両方に必要なVIPとVSを公開します。このURLは、ディザスタ・リカバリ構成に備えてサイト非依存である必要があります。コントロール・プレーン・ノードとワーカー・ノードは、この名前を正しく解決する必要があります。データベース層は、アプリケーション・スキーマ、JMS/JTA永続ストア、OPSSおよびMDS情報をホストする一意のRAC DBで構成されます。すべてのKubernetesワーカー・ノードを含めるために追加のロード・バランサ・エンド・ポイントが作成される場合もあります。その場合は、このロード・バランサを使用して、リクエストをワーカー・ノードの使用可能なプール全体にシームレスに分散できます。

この項では、次のコンポーネントのトポロジ・ダイアグラムを示します:

親トピック: IAMエンタープライズ・デプロイメントについて

プライマリ・デプロイメント・トポロジ

次のトポロジは、オラクル社推奨のアプローチです。

親トピック: KubernetesへのOracle Identity and Access Managementコンポーネントのデプロイメントのトポロジ・ダイアグラム

Oracle Unified Directory

図4-3に、Oracle Unified DirectoryおよびOracle Unified Directory Services Managerのデプロイメントを示します。通常、このダイアグラム内のサービスはいずれもインターネットに公開されません。

完全なKubernetesデプロイメントでは、通常、OUDとの対話はKubernetesクラスタ内に保持されます。この場合は、LDAPコールをクラスタに限定できます。

このデプロイメントでは、イングレス・コントローラを使用してOUDSMとの外部の対話を可能にします。イングレス・サービスを使用するのは、サード・パーティの電話帳アプリケーションなど、Kubernetesクラスタの外部でOUD LDAPサービスにアクセスする必要がある場合のみです。OUDSMに対して外部アクセスが必要になる場合もあります。

Oracle HTTP Serverを介してOUDSMにアクセスすることは可能ですが、これは管理機能であるため、イングレス・コントローラを介して直接OUDMにアクセスできます。

図4-3 イングレス・コントローラを使用するOUD

イングレス・コントローラを使用するOUD
Oracle Access ManagerおよびOracle Identity Governance

図4-4に、Oracle Access ManagerおよびOracle Identity Governanceのデプロイメントを示します。

ロード・バランサは、OAMおよびOIGランタイム機能への外部インターネット・アクセスを提供します。同じロード・バランサが、OAMおよびOIGの管理サービスへの内部アクセスのみを提供します。

外部リクエストはロード・バランサでSSL終端処理され、内部リクエストは標準のHTTPリクエストです。ロード・バランサはOracle HTTP Serverを使用して、これらのリクエストをOAMおよびOIGのサービスにプロキシします。Oracle HTTP Serverはアプリケーション・リクエストをイングレス・コントローラに渡し、イングレス・コントローラはそのリクエストをOAMおよびOIG Kubernetesサービスに転送します。

図4-4 イングレス・コントローラを使用するOAMおよびOIG


イングレス・コントローラを使用するOAMおよびOIG

Oracle Identity Role Intelligence

図4-5に示しているのは、Oracle Identity and Access Managementの完全なデプロイメントに統合されたOracle Identity Role Intelligenceのデプロイメントですが、ここでは、すべてのトラフィックがOracle HTTP Serverの後に、イングレス・コントローラを介してルーティングされます。

このタイプのデプロイメントでは、Kubernetesクラスタにその他のアイデンティティ・コンポーネントが存在するかどうかに関係なく、Oracle Identity Role Intelligenceを、完全なOracle Identity and Accessデプロイメントと統合できます。

ロード・バランサは、OIRIサービスへの内部専用アクセスを提供します。ロード・バランサはOracle HTTP Serverを使用して、これらのリクエストをOIRIにプロキシします。Oracle HTTP Serverは、完全に統合されたアイデンティティ管理デプロイメントが使用されている場所で使用され、すべてがOracle HTTP Serverを介してプロキシされます。

OIRIは、igdadmin.example.com仮想ホストを共有するか、独自の専用仮想ホストを使用できます。

OIRIは管理専用機能であり、インターネットとの直接的な対話はありません。

図4-5 イングレス・コントローラを使用する統合OIRI

イングレス・コントローラを使用する統合OIRI
Oracle Advanced Authentication、Oracle Adaptive Risk ManagementおよびOracle Universal Authenticator

図4-6に、Oracle Advanced Authenticationのデプロイメントを示します。OAAには、管理操作とランタイム操作の両方があります。

ロード・バランサは、OAA/OARMサービスへのアクセスを提供します。ロード・バランサにより、これらのリクエストがイングレス・コントローラに直接送信され、次に、適切なOAAマイクロサービスに送信されます。Oracle HTTP Serverは、完全に統合されたアイデンティティ管理デプロイメントが使用されている場所で使用され、すべてがOracle HTTP Serverを介してプロキシされます。

Oracle HTTP Serverはリクエストをイングレス・コントローラに送信し、イングレス・コントローラはこれらのリクエストを適切なOAA Kubernetesサービスに送信します。

OAAは、iadadmin/login仮想ホストを共有するか、独自の専用仮想ホストを使用できます。

外部リクエストはロード・バランサでSSL終端処理され、内部リクエストは標準のHTTPリクエストです。

図4-6 イングレス・コントローラを使用するOAA

イングレス・コントローラを使用するOAA

セカンダリ・デプロイメント・トポロジ

次に示すトポロジは、完全にサポートされている代替のデプロイメントで、使用を検討できます。

親トピック: KubernetesへのOracle Identity and Access Managementコンポーネントのデプロイメントのトポロジ・ダイアグラム

Oracle Unified Directory

図4-7に、Oracle Unified DirectoryおよびOracle Unified Directory Services Managerのデプロイメントを示します。通常、このダイアグラム内のサービスはいずれもインターネットに公開されません。

完全なKubernetesデプロイメントでは、通常、OUDとの対話はKubernetesクラスタ内に保持されます。この場合は、LDAPコールをクラスタに限定でき、NodePortサービスは必要ありません。NodePortサービスを使用するのは、サード・パーティの電話帳アプリケーションなど、Kubernetesクラスタの外部でOUD LDAPサービスにアクセスする必要がある場合のみです。OUDSMに対して外部アクセスが必要になる場合もあります。

Oracle HTTP Serverを介してOUDSMにアクセスすることは可能ですが、これは管理機能であるため、OUDSM用に公開されているNodePortサービスを使用して直接アクセスできます。

図4-7 NodePortサービスを使用するOUD


Kubernetesクラスタ内のOracle Unified Directory Services Manager

Oracle Access ManagerおよびOracle Identity Governance

図4-8に、Oracle Access ManagerおよびOracle Identity Governanceのデプロイメントを示します。

ロード・バランサは、OAMおよびOIGランタイム機能への外部インターネット・アクセスを提供します。同じロード・バランサが、OAMおよびOIGの管理サービスへの内部アクセスのみを提供します。外部リクエストはロード・バランサでSSL終端処理され、内部リクエストは標準のHTTPリクエストです。ロード・バランサはOracle HTTP Serverを使用して、これらのリクエストをOAMおよびOIGのサービスにプロキシします。OAMおよびOIGのサービスは、個々のNodePortサービスを使用してKubernetesクラスタの外部に公開されます。

図4-8 NodePortサービスを使用するOAMおよびOIG

Kubernetesクラスタ内のOracle Identity and Access Management
Oracle Identity Role Intelligence

図4-9に、トラフィックがイングレス・コントローラを介してルーティングされるOracle Identity Role Intelligenceのスタンドアロン・デプロイメントを示します。

イングレス・コントローラにより、適切なOIRI Kubernetesサービスにリクエストが送信されます。OIRIは、igdadmin.example.com仮想ホストを共有するか、独自の専用仮想ホストを使用できます。

OIRIは管理専用機能であり、インターネットとの直接的な対話はありません。

図4-9 イングレス・コントローラのみを使用するOIRI


イングレス・コントローラのみを使用するOIRI

図4-10に示しているのは、Oracle Identity and Access Managementの完全なデプロイメントに統合されたOracle Identity Role Intelligenceのデプロイメントですが、ここでは、すべてのトラフィックがOracle HTTP Serverを介してルーティングされ、次に、Kubernetes NodePortサービスを使用してOIRIマイクロサービスに直接送信されます。このタイプのデプロイメントでは、Kubernetesクラスタにその他のアイデンティティ・コンポーネントが存在するかどうかに関係なく、Oracle Identity Role Intelligenceを、完全なOracle Identity and Access Managementデプロイメントと統合できます。

ロード・バランサは、OIRIサービスへの内部専用アクセスを提供します。ロード・バランサはOracle HTTP Serverを使用して、これらのリクエストをOIRIにプロキシします。Oracle HTTP Serverは、完全に統合されたアイデンティティ管理デプロイメントが使用されている場所で使用され、すべてがOracle HTTP Serverを介してプロキシされます。

OIRIサービスは、個々のNodePortサービスを使用してKubernetesクラスタの外部に公開されます。OIRIはOracle HTTP Serverなしでデプロイできます。図4-10を参照してください。

OIRIは、igdadmin.example.com仮想ホストを共有するか、独自の専用仮想ホストを使用できます。

OIRIは管理専用機能であり、インターネットとの直接的な対話はありません。

図4-10 NodePortサービスを使用する統合OIRI


Kubernetesクラスタ内のOracle Identity Role Intelligence

Oracle Advanced Authentication、Oracle Adaptive Risk ManagementおよびOracle Universal Authenticator

図4-11に、完全に統合されたOracle Identity and Access ManagementデプロイメントでのOracle Advanced AuthenticationおよびRisk Managementのデプロイメントを示します。

ロード・バランサは、OAAおよびOARMランタイム機能への外部インターネット・アクセスを提供します。同じロード・バランサで、OAAおよびORAMの管理サービスへの内部アクセスのみが可能になります。

外部リクエストはロード・バランサでSSL終端処理され、内部リクエストは標準のHTTPリクエストです。ロード・バランサはOracle HTTP Serverを使用して、これらのリクエストをOAAおよびOARMのサービスにプロキシします。OAAおよびOARMのサービスは、個々のNodePortサービスを使用してKubernetesクラスタの外部に公開されます。

ノート:

OAAおよびOARMデプロイメントでは、OAAマイクロサービスでSSLが有効になっています。

図4-11 NodePortサービスを使用するOAA


NodePortサービスを使用するOAA

図4-12に、Oracle Advanced AuthenticationおよびRisk Managementのスタンドアロン・デプロイメントを示します。ロード・バランサは、OAAおよびOARM管理サービスへの外部インターネット・アクセスを提供します。イングレス・コントローラは、OAA Kubernetesサービスへのアクセスを提供します。このシナリオでは、OAAは独自の専用仮想ホストを使用します。

図4-12 Kubernetesでのイングレスを使用するスタンドアロンOAA


Kubernetesでのイングレスを使用するスタンドアロンOAA

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

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

親トピック: IAMエンタープライズ・デプロイメントについて

製品の分離

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

  • Webサーバー
  • WebLogicアプリケーション・サーバー
  • コンテナ上のデプロイ済マイクロサービス
  • LDAP
  • データベース

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

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

ノート:

Kubernetesデプロイメントでは、OHSおよびOUDSMのドメインはWebLogic Kubernetes Operatorで制御されません。

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

OHSDomainおよびOUDSMDomainは、それぞれOracle HTTP ServerおよびOracle Unified Directory Services Managerの管理に使用されます。

前述のドメインに加えて、次のコンポーネントはドメインなしでデプロイされます:
  • Oracle Unified Directory
  • マイクロサービス

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

Oracle Identity Role IntelligenceとOracle Advanced Authenticationは、専用のマイクロサービスとしてデプロイされます。

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

Web層について

Web層は、Oracle HTTP Serverがインストールされている2つ以上のホスト・コンピュータで構成されます。Web層は、アプリケーション層とは別のネットワーク/サブネット内の非武装地帯(DMZ)にあります。この場所では、最大限のネットワーク・セキュリティが確保されます。

Web層は2つのファイアウォールの間に配置されるため、インターネットからのトラフィックを制限しやすく、アプリケーション層を通過できるのがアプリケーション・トラフィックのみになります。

インターネットに直接接続するアプリケーションでは、管理タイプの機能が組織内部でのみ解決可能な仮想ホストに制約されるようにWeb層が定義されます。この機能により、誰かがプライベート・ネットワーク内に存在していないと管理操作を実行できないことが保証されます。

管理仮想ホストがプライベート・ネットワーク内でのみ解決可能であるということは、この仮想ホストを使用する通信でSSLが必要ないことを意味します。

インターネットとの通信は、SSLを使用するインターネット・クライアントとの間で行われる必要があります。ただし、アプリケーションでエンドツーエンドのSSLを使用すると、パフォーマンスに影響します。Web層をDMZに配置することで、SSLはWeb層の外部のロード・バランサで終端し、トポロジ内部の通信でははるかに高速の非SSLプロトコルが使用されます。この戦略には、すべてのインターネット・トラフィックでSSLが有効になっているのに、エンドツーエンドSSLのパフォーマンス・オーバーヘッドを回避できるというメリットがあります。

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

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 Role Intelligenceについて

ロールベースのアクセス制御(RBAC)には、次の課題があります:
  • 手動プロセスとしてロールを作成するのは時間がかかります。権限データは、ユーザーが分析および解釈するには困難で複雑なものです。
  • 権限は時間の経過とともに蓄積されます。ユーザーとアプリケーションのデータは絶えず変化します。
  • ロールは、再編、合併、買収などの企業活動に合せて維持および変更することが困難です。
  • 組織が様々なビジネス・ユニットにロールを採用する前に、What-If分析を提供するためのツールが不足しています。

これらの課題は、Oracle Identity Role Intelligence (OIRI)マイクロサービスによって解決されます。

Oracle Identity Role Intelligenceでは、従来のWebLogicデプロイメント・アーキテクチャではなく、マイクロサービス・アーキテクチャを使用します。つまり、Oracle Identity Role Intelligenceは、Kubernetesなどのコンテナ・ベースのアーキテクチャを使用してデプロイする必要があります。OIRIは、引き続き従来のOracle Identity and Access Managementデプロイメントと統合されます。ただし、OIRIコンポーネントはコンテナにデプロイする必要があります。

Oracle Identity Role Intelligenceは、Oracle Identity Governance (OIG)の拡張機能です。これは管理者によって使用されます。したがって、エンタープライズ・デプロイメントでは、管理アプリケーションURL igdadmin.example.comに関連付けられます。

ノート:

このリリースでは、OIRIはOracle Identity and Accessエンタープライズ・デプロイメント・アーキテクチャ全体に統合されていますが、Oracle Access Managerによるシングル・サインオンはサポートされていません。

データ・イングレス: OIGデータベースまたはフラット・ファイルからのOIRIへのデータ・インポートを完全モードおよび増分モードでサポートします。

データ・モデリング: ユーザー、アプリケーションおよび権限の属性の組合せに基づいて、ロール・マイニング・タスクを定義できます。

予測分析:: Oracle DatabaseのKMeanクラスタリングおよび監視対象外の機械学習(ML)アルゴリズムが使用されます。回帰モデルは、共通の権限属性に基づいてユーザー・データをグループ化し、関連する一致した候補ロールを予測します。

アシスタント: 候補ロールをシステム内の既存のロールと比較します。候補ロールをシステムに発行して、ロールの重複や急増を回避できます。

データ・エグレス: 候補ロールをOracle Identity Governanceに発行するための自動化を提供し、ワークフロー承認をトリガーします。

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

Oracle Advanced Authentication、Oracle Adaptive Risk ManagementおよびOracle Universal Authenticatorについて

Oracle Advanced Authentication (OAA)は、ユーザーのアイデンティティの確立とアサーションをサポートします。

OAAは、複数の認証ファクタ(MFA)を使用した強力な認証を提供します。ユーザーのアイデンティティを確立するために、様々な認証ファクタをすぐに利用できます。OAAは、マルチファクタ認証(MFA)機能を提供するために、Oracle Access Management (OAM)およびOracle Radius Agent (ORA)との統合をサポートしています。

OAAは、デプロイメント、構成、および他の製品との統合を容易にする独自の機能を備えています。

OAAには次の機能があります:
  • Kubernetesプラットフォーム上でスタンドアロンのマイクロサービスとして実行され、Helmチャートを使用してデプロイされます
  • マルチファクタ認証(MFA)を有効化するために、次のクライアントとの統合をサポートします:
    • Oracle Access Management (OAM)などのWebベースのユーザー・ログイン・フローを提供するクライアント: OAAは、Trusted Authentication Protocol (TAP)を介してOAMと統合されます。
    • Oracle Radius Agent (ORA)などのAPIベースのユーザー・ログイン・フローを提供するクライアント: OAAは、REST APIを介してORAと統合されます。このタイプの統合では、クライアントは独自のユーザー・フロー・オーケストレーションを管理できます。
  • OAMと統合するためのOAAAuthnPluginを提供します。このプラグインは、OAM上のアイデンティティ・ストアからOAAへのユーザー・データの移行も可能にします。
  • 管理者がクライアント登録、保証レベルおよびポリシーを作成および管理するためのWeb UI (管理UIコンソール)を提供します。管理者は、REST APIを使用してすべての管理タスクを実行することもできます。
  • ユーザーが各自のチャレンジ・ファクタを管理および登録するためのWeb UI (ユーザー・プリファレンスUI)を提供します。ユーザーの自己登録および管理は、REST APIを使用して実行することもできます。
  • Web UIは、OAM OAuthおよびOIDCによって保護されます。
  • すぐに利用できる次のチャレンジ・ファクタを提供します:
    • 時間ベースのワンタイム・パスワード(TOTP): (OMA、GoogleおよびMicrosoft)
    • OTP (電子メールおよびSMS)
    • Yubikey OTP
    • Fast Identity Online (FIDO2)

Oracle Advanced Authenticationは、スタンドアロン・サービスとして、または統合されたOracle Identity and Access Managementデプロイメントの一部としてデプロイできます。

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

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トラフィック用のアクセス・ポイントとして機能します。igdadminエントリ・ポイントは、Oracle Identity Role Intelligenceのエントリ・ポイントとしても使用されます。クライアントからの受信トラフィックはすべて非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に転送されます(これはKubernetes環境ではオプションです):

    igdinternal.example.com:7777

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

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

    ノート:

    LDAPディレクトリにアクセスするすべてのアプリケーションがKubernetesクラスタ内にある場合、LDAPアクセスのためにロード・バランサの仮想ホストではなくKubernetesサービス名を使用できます。

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

Kubernetes上のOracle Identity Managementについて

Kubernetes上のOracle Identity Managementのトポロジは従来のOracle Identity Managementデプロイメントのトポロジと似ていますが、次の点で重要な違いがいくつかあります:

  • 管理対象サーバー

    管理サーバーを含むOracle WebLogic管理対象サーバーは、コンテナにデプロイされます。各管理対象サーバーは、独自のコンテナに存在します。

  • 仮想IPアドレス

    従来のエンタープライズ・デプロイメントでは、仮想IPアドレスを使用して、管理フェイルオーバーとサーバー移行を容易にします。Kubernetesでは独自のIPアドレスが自動的に割り当てられるため、これはKubernetesデプロイメントでは必要ありません。

  • 管理対象サーバーとの対話

    従来のエンタープライズ・デプロイメントでは、管理対象サーバーの構成方法に応じて、管理対象サーバーのリスニング・アドレスに割り当てられた仮想ホスト名または管理対象サーバーが実行されている物理ホスト名を使用して、管理対象サーバーと対話します。

    Kubernetes環境では、Kubernetesサービスはクラスタ・レベルで定義されます。Kubernetesコンテナが追加または削除されると、それに応じてKubernetesサービスが更新されます。すべての通信はKubernetesサービスを介して行われます。

    Kubernetesサービスには、各Kubernetesワーカー・ホストからアクセスできます。

  • マイクロサービス

    マイクロサービスでは、従来のOracle Identity and Access Management機能を拡張します。マイクロサービスはそれぞれKubernetesコンテナにデプロイされます。管理対象サーバーと同様に、高可用性を実現するために、マイクロサービスにはクラスタ・レベルで定義されたKubernetesサービスが割り当てられます。マイクロサービスとの対話は、Oracle HTTP Serverを介して行われます。

  • 共有ストレージと永続性

    各コンテナは、永続ボリュームに関連付けられます。永続ボリュームは、ドメイン/インスタンス・ファイルが配置される場所です。永続ボリュームは、NFS共有にマップされるため、従来のバックアップおよびリカバリ技術を使用できます。

    永続ボリュームに格納されている情報のみが、再起動後も存続します。ORACLE_HOMEは、永続ボリュームには格納されません。そのため、行った変更は再起動後は存続しません。これにより、パッチ適用が容易になります。ただし、ORACLE_HOMEのファイルを直接編集することはできません。

    従来のエンタープライズ・デプロイメントとは異なり、DOMAIN_HOMEは、ASERVER_HOMEとMSERVER_HOMEに分割されません。

  • カスタマイズ

    特定のOracle製品ではカスタマイズが可能です。多くの場合、ORACLE_HOMEの.warファイルを変更/作成することで行われます。Kubernetesデプロイメントでは、この方法で行われた変更はコンテナの再起動後に失われます。カスタマイズを行う場合は、.warファイル(開発スタータ・パックを含む)を/u01/oracle/user_projectsにマウントされた永続ボリュームに配置します(できれば専用のディレクトリをお薦めします)。この方法により、再起動やイメージの変更(バンドル・パッチおよびアップグレード)を経てもカスタマイズが維持されます。

    .warファイルを永続ボリュームに配置した後で、その場所(/u01/oracle/user_projects)からドメインにデプロイします。

  • コンテナとホストの比較

    標準的なエンタープライズ・デプロイメントでは、各WebLogicドメイン、各LDAPインスタンス、各データベースおよび各Webサーバーが多数のホスト上で実行されています。

    Kubernetes環境では、WebLogic/マイクロサービス/LDAPコンポーネントがKubernetesクラスタに移動されます。Web層とデータベースはその対象外です。これにより、インターネットとWeb層間、Web層とKubernetesクラスタ間、およびKubernetes層とデータベース間にファイアウォールを設定できます。その結果、Kubernetesがアプリケーション層に提供する柔軟性を活用しながら、エンタープライズ・セキュリティを維持できます。

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

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

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

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

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

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

IAMAccessDomain

Oracle Access Manager

oam_server1、oam_server2

Oracle Policy Manager

oam_policy_mgr1、oam_policy_mgr2

IAMGovernanceDomain

Oracle Identity Governance

Oracle SOA Suite

oim_server1、oim_server2

soa_server1、soa_server2

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

エンタープライズ・デプロイメントの記憶域の要件

エンタープライズ・デプロイメント用のファイル・システムの準備では、ローカルおよび共有記憶域の要件や、エンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語を理解する必要があります。

親トピック: IAMエンタープライズ・デプロイメントについて

エンタープライズ・デプロイメント用の記憶域の準備について

記憶域は、エンタープライズ・デプロイメントがわかりやすくなり、構成および管理が容易になるように設定することが重要です。

この項では、エンタープライズ・デプロイメントの記憶域を準備するプロセスの概要を示します。この章の情報に従って記憶域を設定することをお薦めします。この章で定義されている用語は、このガイド内のダイアグラムおよび手順で使用されます。

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。

その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このガイドで採用するモデルは、可用性を最大化するために設計されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび障害時リカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

親トピック: エンタープライズ・デプロイメントの記憶域の要件

エンタープライズ・デプロイメント用の推奨ディレクトリ構造について

この項のダイアグラムは、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメント用のディレクトリ構造を示しています。

ダイアグラムに示す各ディレクトリには、事前作成済のコンテナ・イメージの一部であるバイナリ・ファイル、ドメイン構成プロセスを通じて生成されるドメイン固有のファイルに加え、Oracle WebLogic Serverのpackコマンドとunpackコマンドによって様々なホスト・コンピュータに伝播されるドメイン構成ファイルが格納されます。

次のものを示すためにダイアグラムが使用されています。

  • 図4-13は、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で共有記憶域デバイスに作成されているディレクトリ構造を示しています。共有記憶域のディレクトリは、アプリケーション層のホスト・コンピュータからアクセス可能です。

  • 図4-16は、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で、標準的なWeb層ホスト用のローカル記憶域デバイスに作成されているディレクトリ構造を示しています。ソフトウェア・バイナリ(Oracleホーム内)は、Web層のホストごとのローカル記憶域デバイスにインストールされます。

該当する場合、ダイアグラムには、このガイドのインストールおよび構成手順でディレクトリ場所を表すために使用する標準変数も記載されています。

図4-13 エンタープライズ・デプロイメントで推奨される共有記憶域ディレクトリ構造

エンタープライズ・デプロイメントで推奨される共有記憶域ディレクトリ構造

「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

図4-14 Oracle Identity Role Intelligenceで推奨されるディレクトリ構造

Oracle Identity Role Intelligenceで推奨されるディレクトリ構造

図4-15 Oracle Advanced Authenticationで推奨されるディレクトリ構造

Oracle Advanced Authenticationで推奨されるディレクトリ構造

図4-16 エンタープライズ・デプロイメントで推奨されるWeb層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

エンタープライズ・デプロイメントで推奨されるWeb層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

親トピック: エンタープライズ・デプロイメントの記憶域の要件

コンテナの記憶域ファイル・システムと対応するマウント・ポイントのサマリー

Oracle Identity and Access Managementは、個々のKubernetesコンテナにマウントされた共有記憶域を使用します。これにより、コンテナが起動されると、常にそのファイル・システム・データにアクセスできます。

アプライアンスでエンタープライズ・デプロイメント・ソフトウェアを編成するには、多数のプロジェクトを作成します。その後、ファイル・システムの共有がアプライアンス上のこれらのプロジェクト内に作成されます。これらの共有は、Kubernetesコンテナに直接マウントできます。

管理を容易にするために、これらのファイル・システムは、デプロイメントおよび管理操作に使用する管理ホストにもマウントされます。管理ホストにマウントする場合、実行している管理タスクの期間中のみマウントする必要があります。Oracleでは、この時間を超えてファイル・システムをマウントしないことをお薦めします。

Oracle HTTP Serverのバイナリ・ファイルは、ローカル・ボリュームまたはWeb層ホストに排他的にマウントされた共有ボリューム上に作成できます。

図4-17は、共有記憶域デバイスで推奨される物理ディレクトリ構造を示しています。

表4-3は、記憶域デバイスの共有をKubernetesコンテナ内のマウント・ポイントにマップする方法を示しています。

図4-17 仮想デプロイメント用の共有ファイル・システムにおける共有の物理構造

ストレージ・アプライアンス上の共有の物理構造

図4-17は、共有アプライアンス上の共有の物理構造を示しています。

表4-2 仮想サーバー用の記憶域プロジェクトのサマリー

プロジェクト サイズ

IAMBINARIES

10 GB

IAMPVS

300GB

IMAGES

50GB

ノート: サイズは、バージョンを含め、格納する必要があるDockerイメージの数によって異なります。各イメージの少なくとも2つのバージョンに対して十分な領域を確保する必要があります。これにより、現在のバージョンと、パッチを適用するバージョンを保持できます。

コンテナ・レジストリを使用している場合、「イメージ」プロジェクトは必要ありません。

親トピック: エンタープライズ・デプロイメントの記憶域の要件

ファイル・システムのホストへのマッピング

この表は、ストレージ・アプライアンス上の物理ディレクトリが、各コンテナまたはホストのマウント・ポイントにどのようにマップされるのかをまとめたものです。

表4-3 アプライアンス上の共有の、各コンテナまたはホストのマウント・ポイントへのマッピング

プロジェクト 共有 マウント・ポイント コンテナ/ホスト マウント場所 ユーザー、グループおよびその他に割り当てる権限 実際のサイズ 説明および目的

IAMBINARIES1

webbinaries1

/exports/IAMBINARIES1/webbinaries1

WEBHOST1

/u02/private/oracle/products

読取り/書込み

10 GB

Oracle HTTP Serverソフトウェア・バイナリのローカル記憶域(Oracleホーム)。

IAMBINARIES2

webbinaries2

/exports/IAMBINARIES2/webbinaries2

WEBHOST2

/u02/private/oracle/products

読取り/書込み

10 GB

Oracle HTTP Serverソフトウェア・バイナリのローカル記憶域(Oracleホーム)。

IAMPVS

oampv

/exports/IAMPVS/oampv

OAM

/u01/oracle/user_projects

読取り/書込み

5GB

OAMドメインの共有記憶域。

IAMPVS

oigpv

/exports/IAMPVS/oigpv

OIG

/u01/oracle/user_projects

読取り/書込み

5GB

OIGドメインの共有記憶域。

IAMPVS

oudpv

/exports/IAMPVS/oudpv

LDAP

/u01/oracle/user_projects

読取り/書込み

10 GB

OUDインスタンスの共有記憶域。これはOracleホーム・ディレクトリと製品ディレクトリがインストールされる場所です。

IAMPVS

oudconfigpv

/exports/IAMPVS/oudconfigpv

LDAP

/u01/oracle/config-input

読取り/書込み

5GB

OUDの設定に必要な構成ファイルの共有記憶域。

IAMPVS

oudsmpv

/exports/IAMPVS/oudsmpv

OUDSM

/u01/oracle/user_projects

読取り/書込み

10 GB

OUDSMの共有記憶域。

IAMPVS

 oiripv /exports/IAMPVS/oiripv

OIRI

OIRI-CLI

 /app/oiri

読取り/書込み

10 GB

OIRIの共有記憶域。

IAMPVS

 dingpv /exports/IAMPVS/dingpv

SPARK-HISTORY (DING)

OIRI

OIRI-CLI

 /app

読取り/書込み

10 GB

Data Ingesterの共有記憶域。

IAMPVS

 workpv /exports/IAMPVS/workpv

OIRI-CLI

OIRI-DING-CLI

 /app/k8s

読取り/書込み

200 M

OIRIの構成/管理に使用される作業ディレクトリ。

IAMPVS

oaaconfigpv

/exports/IAMPVS/oaaconfigpv

oaa-mgmt

/u01/oracle/scripts/settings

読取り/書込み

  

OAAおよびOARMのインストール用にカスタマイズされた構成ファイルを格納するために使用されます。

IAMPVS

oaacredpv

/exports/IAMPVS/oaacredpv

oaa-mgmt

/u01/oracle/scripts/cred

読取り/書込み

  

k8sconfig、helmconfig、trust.p12、cert.p2などの資格証明ファイルを格納するために使用されます。

IAMPVS

oaalogpv

/exports/IAMPVS/oaalogpv

oaa-mgmt

/u01/oracle/logs

読取り/書込み

  

インストール・ログおよびステータスを格納するために使用されます。

IAMPVS

oaavaultpv

/exports/IAMPVS/oaavaultpv

oaa-mgmt

/u01/oracle/service/store/oaa

読取り/書込み

  

ファイルベースのボールトのボールト・アーティファクトを格納するために使用されます。

IAMCONFIG

webconfig1

/exports/IAMCONFIG/webconfig1

WEBHOST1

/u02/private/oracle/config

読取り/書込み

5GB

WEBHOST1によって使用されるドメイン構成ファイルのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

IAMCONFIG

webconfig2

/exports/IAMCONFIG/webconfig2

WEBHOST2

/u02/private/oracle/config

読取り/書込み

5GB

WEBHOST2によって使用されるドメイン構成ファイルのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

IMAGES

images

/exports/IMAGES/images

Kubernetesワーカー

/images

読取り/書込み

10 GB

コンテナ・イメージをローカルに格納するために使用されます。これはオプションです。

ノート:

必要に応じて、構成の完了後にbinaryディレクトリを読取り専用に変更できます。

親トピック: エンタープライズ・デプロイメントの記憶域の要件

このガイドで使用するファイル・システムとディレクトリ変数

ファイル・システムのディレクトリおよびこれらのディレクトリの参照に使用するディレクトリ変数を理解することは、エンタープライズ・デプロイメント・トポロジのインストールと構成に不可欠です。

表4-4は、ファイル・システムのディレクトリとアプリケーション層のディレクトリの参照に使用されるディレクトリ変数を示しています。表4-5は、ファイル・システムのディレクトリおよびWeb層のディレクトリの参照に使用される変数を示しています。

共有記憶域を使用している場合にこれらのディレクトリをマウントする方法の詳細は、「エンタープライズ・デプロイメント用のディレクトリの作成およびマウント」を参照してください。

このガイド全体を通して、トポロジのインストールおよび構成に関する手順では、ここに示す変数を使用してディレクトリの場所を参照します。

この項に列挙する各ディレクトリに対してオペレーティング・システム変数を定義することもできます。システム変数をご使用のUNIXシェルで定義しておくと、このドキュメントの記載どおりに変数を使用できるので、変数を実環境における実際の値と対応付ける必要がなくなります。

表4-4 アプリケーション層の主要なディレクトリ変数のサンプル値

ディレクトリ変数 説明 相対パス アプリケーション層のサンプル値

CONTAINER_ROOT

コンテナのホーム・ディレクトリ。このディレクトリには、Oracle製品バイナリおよびOUD設定ファイルがあります。

 該当なし /u01

ORACLE_HOME

製品バイナリ用の読取り専用場所。アプリケーション層のホスト・コンピュータの場合は、共有ディスク(PV)に格納されます。

Oracleホームは、コンテナのデプロイ時に作成されます。Kubernetesデプロイメントでは、ORACLE_HOMEはCONTAINER_HOMEと同じです。

CONTAINER_HOME/oracle

/u01/oracle

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle Fusion MiddlewareのOracleホーム内のディレクトリ。

 ORACLE_HOME/oracle_common

/u01/oracle/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

 ORACLE_HOME/wlserver /u01/oracle/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

 ORACLE_HOME/prod_dir /u01/oracle/prod_dir

製品は、エンタープライズ・デプロイメントに応じてsoa、wcc、idm、biまたはその他の値になります。

EM_DIR

Oracle Enterprise Manager Fusion Middleware Controlソフトウェア・バイナリの格納に使用される製品ディレクトリ。

 ORACLE_HOME/em /u01/oracle/em

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

 CONTAINER_ROOT/jdk /u01/jdk

SHARED_CONFIG_DIR

 ドメイン構成、キーストア、ランタイム・アーティファクト、アプリケーション・デプロイメントなど、共有環境構成ファイルのための共有親ディレクトリ CONTAINER_HOME/user_projects /u01/oracle/user_projects

DOMAIN_HOME

共有ディスクにインストールされるドメイン・ホーム。

 SHARED_CONFIG_DIR/domains/domain_name /u01/oracle/user_projects/domains/domain_name

この例では、domain_nameをWebLogic Serverドメイン名で置き換えます。

APPLICATION_HOME

アプリケーションのホーム・ディレクトリ。アプリケーション層のすべてのホスト・コンピュータからアクセスできるように、共有ディスクにインストールされます。

 SHARED_CONFIG_DIR/applications/domain_name /u01/oracle/user_projects/applications/domain_name

この例では、domain_nameをWebLogic Serverドメイン名で置き換えます。

KEYSTORE_HOME

カスタム証明書およびキーストアの共有場所。

 SHARED_CONFIG_DIR/keystores /u01/oracle/user_projects/keystores

表4-5 Web層の主要なディレクトリ変数のサンプル値

ディレクトリ変数 説明 Web層のサンプル値

WEB_ORACLE_HOME

Oracle HTTP Server製品バイナリ用の読取り専用場所。Web層のホスト・コンピュータの場合は、このディレクトリはローカル・ディスクに格納されます。

Oracleホームは、Oracle HTTP Serverソフトウェアのインストール時に作成されます。

/u02/private/oracle/products/web

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle HTTP ServerのOracleホーム内のディレクトリ。

/u02/private/oracle/products/web/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

 /u02/private/oracle/products/web/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

 /u02/private/oracle/products/web/ohs

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

 /u02/private/oracle/products/jdk

WEB_DOMAIN_HOME

Web層の各ホストのローカル・ディスク上にOracle HTTP Serverをインストールする際に作成される、スタンドアロンOracle HTTP Serverドメインのドメイン・ホーム。

/u02/private/oracle/config/domains/domain_name

この例では、domain_nameをWebLogic Serverドメイン名で置き換えます。

WEB_CONFIG_DIR

Oracle HTTP Server構成ファイル(httpd.confやmoduleconf/*.confなど)の編集を行う各Webホスト上の場所。

このディレクトリは、OHSステージング・ディレクトリとも呼ばれます。ここで行った変更は、OHS実行時ディレクトリに伝播されます。

『Oracle HTTP Serverの管理』のステージングおよびランタイム構成ディレクトリに関する項を参照してください。

/u02/private/oracle/config/domains/domain_name/config/fmwconfig/components/OHS/instance/instance_name

親トピック: エンタープライズ・デプロイメントの記憶域の要件

権限について

コンテナが作成されると、そのコンテナに所有されるファイルは、UID 1000のユーザーおよびグループ1000によって所有されます。

UID 1000のユーザーがすでにシステムに存在する場合、すべてのコンテナ・サービスがこのユーザーとして実行されます。

UID/GIDが1000のユーザー/グループが存在しない場合は、作成する必要があります。

コンテナで使用するためにNFS共有を作成するとき、UID:GIDが1000:1000のユーザー/グループに書込み権限があることを確認します。

親トピック: IAMエンタープライズ・デプロイメントについて

アプリケーション層のマイクロサービスおよびクラスタのサマリー

アプリケーション層は、Oracle Identity and Access ManagementのWebLogicコンポーネントをホストするだけでなく、マイクロサービス・コンポーネントもホストします。

選択したコンポーネントに応じて、Oracleマイクロサービスは、表4-6に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。

表4-6 Oracleマイクロサービス

コンポーネント 機能 マイクロサービス

OIRI

Oracle Role Intelligence

oiri

OIRI

Oracle Role Intelligence GUI

oiri-ui

OIRI

Oracle Data Ingester

spark-history-server

OAA

OAAおよびRiskのインストール

oaa-mgmt

OAA

主なOAA機能

oaa-svc

OAA + OARM

ポリシー管理API

oaa-policy

OAA + OARM

管理UI (OAA + OARM)

oaa-admin

OAA
  • ユーザー・プリファレンス・ユーザー・インタフェース
  • MFA認証UI
  • パスワードを忘れた場合のUI

oaa-spui

OAA

Fidoデバイス登録およびFidoベース認証

oaa-factor-fido

OAA

Oracle Mobile Authenticator (OMA) OTP認証のみ

oaa-factor-totp

OAA

SMS認証のみ

oaa-factor-sms

OAA

電子メール認証のみ

oaa-factor-email

OAA

Yubikeyベース認証のみ

oaa-factor-yotp

OAA

ナレッジベースのチャレンジ登録および認証

oaa-factor-kba

OAA

OMAプッシュ登録および認証

oaa-factor-push

OARM

カスタマ・ケアAPI

risk-cc

OARM

リスク評価API

risk-engine

親トピック: IAMエンタープライズ・デプロイメントについて

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

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が送信され、これをアプリケーションに入力してパスワードをリセットできます。

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

親トピック: IAMエンタープライズ・デプロイメントについて

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エンタープライズ・デプロイメントについて

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

このロードマップでは、KubernetesにプライマリIAM Suiteトポロジを実装するために実行する必要がある様々なタスクを示します。このガイドは、Oracle Kubernetes Engine (OKE)やOracle Cloud Native Environment上のデプロイメントおよびオンプレミス・ベースのKubernetesデプロイメントに対応しています。

選択したプラットフォームに関係なく、特に明記されていないかぎり、デプロイメントのステップは同じです。

表4-7 KubernetesでのプライマリIAM Suiteトポロジの実装のロードマップ

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

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

標準的なエンタープライズ・デプロイメントについて把握します。

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

Kubernetesデプロイメントについて

Kubernetes上のOracle Identity Managementについて

エンタープライズ・デプロイメント用のリソースを調達します。

オンプレミス・エンタープライズ・デプロイメント用のリソースの調達

Oracle Cloud Infrastructureデプロイメント用のリソースの調達

エンタープライズ・デプロイメント用の環境を準備します。

オンプレミス・エンタープライズ・デプロイメントの準備

エンタープライズ・デプロイメント用のOracle Cloud Infrastructureの準備

必要なソフトウェアを調達します。

エンタープライズ・デプロイメント用のソフトウェアの調達

デプロイメント用に既存のデータベースを準備します。

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

Oracle Unified Directoryの構成

Oracle Unified Directoryのインストールおよび構成

Oracle HTTP Server/Web層を構成します。

Oracle HTTP Serverのインストールと構成

WebLogic Operator for Kubernetesをインストールします。

WebLogic Kubernetes Operatorのインストール

Oracle Access Management用のOracle Fusion Middleware Infrastructureを作成して構成します。

WDTを使用したOracle Access Managerの構成

Oracle Identity Governance用のOracle Fusion Middleware Infrastructureを作成して構成します。

WDTを使用したOracle Identity Governanceの構成

Oracle Identity Role Intelligenceをインストールして構成します

Oracle Identity Role Intelligenceのインストールおよび構成

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

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

親トピック: IAMエンタープライズ・デプロイメントについて

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

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

Oracle Identity and Access Managementのプライマリ・エンタープライズ・トポロジの詳細は、iam-enterprise-deployment.html#GUID-6E3F9FD0-F706-4199-A144-6473AD320003__CHDFBIDEを参照してください。

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

Oracle Identity and Access Management参照トポロジのかわりに、このガイドで説明したステップを使用して実装できるいくつかの代替トポロジを次に示します:

  • 既存のディレクトリのみを含むOAM
  • 既存のディレクトリのみを含むOIM
  • モジュラ・デプロイメントに統合されたOAM/OIM
  • 既存のディレクトリと統合されたOAM/OIM
  • OIGと統合されたOIRI
  • OAMと統合されたOAA

親トピック: IAMエンタープライズ・デプロイメントについて