1 Oracle Identity and Access Management Suiteコンポーネントの統合の概要

この章では、Oracle Identity and Access Management Suiteの統合の概念について説明します。

内容は次のとおりです。

1.1 Oracle Identity Management Suiteコンポーネントの統合の前提条件

これらの手順を使用してIdentity Managementのコンポーネントを統合する前に、それらのコンポーネントをインストールおよびデプロイする必要があります。

この前提条件について、次の項で説明します。

Identity Managementコンポーネントのインストール方法の詳細は、『Oracle Identity and Access Managementのインストールおよび構成』「Oracle Identity and Access Managementのインストールについて」を参照してください。

1.1.1 インストール・ロードマップの理解

IdMデプロイメントでは次のいずれかの工程を使用します(すでに使用している可能性もあります)。

  • インストール、続いてコンポーネント統合、最後にスケールアウト(HA)

  • インストール、続いてスケールアウト、最後に統合

スケールアウトでは、ここで説明する統合手順の一部をすでに実行している場合があります。関連する項のノートによって、手順が必要かどうかを判断できます。

『Oracle Identity and Access Managementのインストールおよび構成』開始ポイントとしての標準インストール・トポロジの使用に関する項には、デプロイメント手順の基礎知識として、インストール・トポロジ、前提条件、およびインストールと構成のワークフローが記載されています。

『Oracle Identity and Access Managementのインストールおよび構成』Oracle Identity Governanceの高可用性の概念に関する項およびOracle Access Managerの高可用性の概念に関する項には、Oracle Fusion Middlewareの高可用性ソリューションに加え、様々な高可用性オプションのトポロジとアーキテクチャが記載されています。

Oracle Access ManagerとLDAPの統合の詳細は、「Oracle Access ManagerとLDAPの統合」を参照してください。

Oracle Access ManagerとOracle Identiy Governanceの統合の詳細は、「Oracle Identity GovernanceとOracle Access ManagerおよびLDAPコネクタとの統合」を参照してください。

1.1.2 デプロイメント・トポロジの理解

この統合を開始する前に、アイデンティティ管理のトポロジおよびそれらのコンポーネントが連動する環境についても理解する必要があります。

このドキュメントでサポートされているトポロジについてさらに学習するには、「Oracle Identity Managementの統合トポロジの理解」を参照してください。

1.1.3 アイデンティティ・ストアの理解

Oracle Identity Governanceには、LDAPベースのアイデンティティ・ストアをOracle Identity Governanceアーキテクチャに統合する機能があります。Oracle Identity Governanceから直接LDAPベースのアイデンティティ・ストアを接続および管理できます。この機能を使用すると、アイデンティティのリクエスト・ベースの作成および管理を含めたOracle Identity Governanceの高度なユーザー管理機能を使用して、企業のアイデンティティ・ストア内でアイデンティティを管理できます。

このデプロイメント・アーキテクチャでは、ユーザー・アイデンティティ情報が、LDAPストアに加えてOracle Identity Governanceデータベースにも格納されるため、Oracle Identity Governanceが機能するために必要なリレーショナル機能がサポートされます。すべてのデータは、プロビジョニング・アクションの実行やポリシーおよびルールの設定なしで、透過的に同期が維持されます。ユーザーの作成や変更など、Oracle Identity Governance内で開始されるアイデンティティ操作は、トランザクションの整合性を維持する形で両方のストアで実行されます。さらに、Oracle Identity Governance外部で行われたLDAPストアの変更は、Oracle Identity Governanceにプルされ、アイデンティティ・コンテキストの一部として使用できるようになります。

1.1.4 LDAPアイデンティティ・ストアとOracle Identity Governanceの統合の理解

Oracle Identity Governanceのユーザーおよびロールは、Oracle Identity Governanceデータベースに格納されます。ただし、Oracle Identity Governanceでユーザー、ロールまたはロール・メンバーシップの変更が発生した場合、この情報はLDAPアイデンティティ・ストアに伝播されます。ユーザー、ロールまたはロール・メンバーシップの変更がLDAPで直接発生した場合、これらの変更はOracle Identity Governanceに同期化されます。同期化の内容:

  • Oracle Identity Governanceで行われる変更: ユーザーの作成、変更、削除、有効/無効の状態とロック済/ロック解除済の状態における変更、およびパスワード変更が、LDAPに同期化されます。

  • ロールの作成、変更および削除アクションにより、LDAPグループがメンバーシップ変更も含めて更新されます。

  • ユーザー、ロールおよびロール・メンバーシップの初期ロードが同期化されます。

  • LDAPでのユーザー・プロファイルに対する直接変更がOracle Identity Governanceにリコンサイルされます。ただし、LDAPで行われたユーザー・パスワードへの変更はOracle Identity Governanceにリコンサイルされません。

  • LDAPでのロールおよびロール・メンバーシップに対する直接変更がOracle Identity Governanceにリコンサイルされます。

ユーザーおよびロール・データで変更が発生すると、実際の操作はカーネル・ハンドラを活用して実行されます。これらのハンドラは、検証、前処理、アクションおよび後処理など、オーケストレーション・ライフサイクルの様々な段階を通過します。

Oracle Identity GovernanceとLDAPとの同期化は、LDAPコネクタ・ライブラリによって実行されます。

図1-1に、Oracle Identity GovernanceとLDAP間の通信を示します。

図1-1 Oracle Identity GovernanceとLDAP

図1-1の説明が続きます
「図1-1 Oracle Identity GovernanceとLDAP」の説明
1.1.4.1 LDAPとの統合の構成

Oracle Identity GovernanceとLDAPの統合の構成は、Oracle Identity Governanceのインストール後に実行されます。OIG-OAM統合のためのスケジュールされたジョブを参照してください。

1.1.5 共通の環境変数

共通環境変数を示す短縮表記が使用されています。

たとえば、Oracle Middlewareホーム・ディレクトリはほとんどの場合、MW_HOMEと示されます。

1.1.6 オペレーティング・システム

現在、統合ではUNIXオペレーティング・システムのみがサポートされています。

詳細は、https://support.oracle.comにあるノートOracle Identity Governance(OIG)と統合されているOracle Access Manager(OAM)はWindowsオペレーティング・システム(OS)でサポートされていますか(ドキュメントID 2780529.1)を参照してください。

1.2 Oracle Identity Managementの統合トポロジの理解

Oracle Identity Managementは、個別または集合で使用できる多数のアプリケーションから構成されます。

Oracle Identity Managementで使用できる2つの基本的なタイプのトポロジは、次のとおりです。

  • 基本統合トポロジ

    このトポロジでは、各コンポーネントが別のノードで実行されている環境におけるスイート・コンポーネント間の統合がサポートされます。

  • エンタープライズ統合トポロジ

    このトポロジは、エンタープライズ環境におけるスイート・コンポーネント間の統合をサポートします。各コンポーネントは複数のノードで実行される場合があります。

このドキュメントでは、最初のタイプの、単一ノード統合トポロジについてのみ説明します。各コンポーネントが各自のノードで実行される環境にOracle Identity Managementをデプロイする場合は、このドキュメントで説明する手順を使用してください。この手順は、統合ツールおよび手法を理解するため、特定のアイデンティティ管理コンポーネントを統合することによる効果と利点について理解するためにも使用できます。

1.2.1 基本統合トポロジについて

基本統合トポロジでは、IdMコンポーネントのAccess ManagerとOracle Identity Governanceが別々のOracle WebLogicドメインで構成されています。

関連項目:

この項で使用する頭字語の定義は、表1-1を参照してください。

図1-2 複数の管理サーバーを含む基本統合トポロジ



上の図は、IdMコンポーネントのAccess ManagerとOracle Identity Governanceが別々のOracle WebLogicドメインで構成されている、基本統合トポロジを示しています。

注意点:

  • Access Managerサーバー(AMHOST)、Oracle Identity Governanceサーバー(OIGHOST)、およびOracle Internet Directory (OID)を含むすべてのIdMコンポーネントが別々のWebLogicドメインで構成され、それぞれが各自の管理サーバーで管理されています。

    このトポロジは各コンポーネントの管理性を高め、さらにパッチおよびアップグレードの適用時における柔軟性を保証します。各コンポーネントのパッチは単独で適用することが可能で、他のコンポーネントへのバージョン依存性はありません。

  • 簡潔にするため、OMSSトポロジの一部は省略されています。たとえば、DMZに存在するMSASサーバーは図に表示されていません。

  • BIPサーバーおよびSOA SuiteがOIGドメイン上に存在します。これらは図に表示されていません。

  • この図は、いくつかの代理ポートのみを示しています。

OIGで使用されるSOA Suiteは、OIGと同じドメイン内にインストールする必要があります。ただし、SOA Suiteを他の目的に使用する場合は、その目的のための固有サービス、コンポジットおよびその他のSOA機能を実行するために、別のSOA Suiteのインストールの設定を検討してください。

単一ドメイン・アーキテクチャでは、Oracle Access Management Access Manager、Oracle Identity Governance、およびOracle Mobile Security Access Serverは同じWebLogicドメイン上に構成されます。可能ではありますが、このようなトポロジは前述の理由のため現在のコンテキストで現実的ではなく、IdM統合に推奨されません。

関連項目:

各IdMコンポーネントの概要は、「統合で使用されるOracle Identity Managementコンポーネントの概要」を参照してください。

1.2.1.1 3層アーキテクチャについて

このアーキテクチャは、3つのレイヤーまたはゾーンで構成されているとみなすことができます。

  • Web層はHTTPサーバーで構成されており、受信Webトラフィックを処理します。

  • アプリケーション層には、Oracle Identity ManagementOracle Access Managerなど、アイデンティティおよびアクセスを管理するためのアイデンティティ管理アプリケーションが含まれています。

  • データ層(ここではディレクトリ・サーバーを含むとみなす)は、LDAPおよびデータベースをホストします。

1.2.1.2 Web層の理解

Web層はDMZパブリック・ゾーンにあります。HTTPサーバーはWeb層にデプロイされます。大部分のIdentity ManagementのコンポーネントはWeb層なしで動作できます。ただし、Access Managerなどの製品を使用して全社レベルのシングル・サインオンをサポートするには、Web層が必要です。

Web層は、単一ノード・トポロジでは次のような構造になります。

  • WEBHOSTには、Oracle HTTP Server、Webゲート(Access Managerコンポーネント)およびmod_wl_ohsプラグイン・モジュールがインストールされています。mod_wl_ohsプラグイン・モジュールによって、Oracle HTTP Serverからアプリケーション層で稼働するWebLogic Serverにリクエストをプロキシできます。Webゲート(Oracle HTTP ServerのAccess Managerコンポーネント)はOracle Access Protocol (OAP)を使用して、OAMHOSTで実行されているOracle Access Managerと通信します。WebゲートとAccess Managerは、ユーザー認証などの操作の実行に使用されます。

1.2.1.3 アプリケーション層の理解

アプリケーション層は、Java EEアプリケーションが配置される層です。Oracle Identity Governance、Oracle Mobile Security Suite、Oracle Access Management Identity FederationおよびOracle Enterprise Manager Fusion Middleware Controlなどの製品が、この層にデプロイされる主要なJava EEコンポーネントです。

アプリケーション層にあるアイデンティティ管理アプリケーションは、次に示すようにディレクトリ層と対話的に処理を行います。

  • エンタープライズ・アイデンティティ情報についてはディレクトリ層が活用されます。

  • アプリケーション・メタデータについてはディレクトリ層(およびデータ層のデータベースの場合もある)が活用されます。

  • Fusion Middleware Controlコンソールは、アプリケーション層およびディレクトリ層のコンポーネントに対する管理機能を提供します。

  • Oracle WebLogic Serverには、Webサーバーのサポートが組み込まれています。有効にされていると、HTTPリスナーはアプリケーション層にも配置されます。

1.2.1.4 データ層の理解

データ層は、すべてのLDAPサービスが配置されるデプロイメント・レイヤーです。この層には、Oracle Internet Directory (OIDHOST)、Oracle Unified Directory、およびOracle Database (IDMDBHOST)などの製品が含まれています。

データ層は、次の2種類の情報を格納します。

  • アイデンティティ情報: ユーザーおよびグループに関する情報はアイデンティティ・ストアに格納されます。

  • Oracle Platform Security Services (OPSS): セキュリティ・ポリシーおよび構成に関する情報は、ポリシー・ストアに格納されます。

ポリシー情報は、データベース内に配置されている集中管理されたポリシー・ストアに格納されます。アイデンティティ情報はOracle Internet Directoryに格納することも、別のディレクトリに格納することもできます。

ノート:

Oracle Access ManagerはOracle Virtual DirectoryサーバーまたはlibOVDを使用して、サード・パーティ・ディレクトリにアクセスします。

1.2.2 エンタープライズ統合トポロジについて

単一ノード・トポロジとは異なり、エンタープライズ統合トポロジは、高可用性、フェイルオーバーおよびファイアウォールなどの機能も考慮され、このドキュメントの範囲外です。

1.2.3 統合の用語

Oracle Fusion Middlewareアーキテクチャを定義する用語の定義

表1-1は、Oracle Fusion Middleware環境のアーキテクチャおよびトポロジの説明に使用される主要な用語および頭字語を示しています。

表1-1 Oracle Fusion Middlewareの統合の用語

用語 定義

IdM構成ツール

アイデンティティ管理コンポーネントのステータスを検証し、特定の統合タスクを実行するためのコマンド行ツール。

Oracle Accessプロトコル(OAP)

認可中のWebゲートとAccess Managerサーバー間の通信のためのセキュアなチャネル。

Oracle Fusion Middlewareホーム

Middlewareホームは、Oracle WebLogic Serverホーム、およびオプションで1つ以上のOracleホームから構成されています。

ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

Oracle HTTP Server(OHS)

Oracle WebLogic Serverのリスナーを提供するOracle Fusion MiddlewareのためのWebサーバー・コンポーネント。

WebLogic Serverホーム

WebLogic Serverホームには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。WebLogic Serverホーム・ディレクトリは、Middlewareホーム・ディレクトリの下の別のOracleホーム・ディレクトリと同等です。

Oracleホーム

Oracleホームには、特定の製品をホストするために必要なインストール済ファイルが含まれています。たとえば、Oracle Identity ManagementのOracleホームには、Oracle Identity Managementのバイナリ・ファイルおよびライブラリ・ファイルを含むディレクトリが含まれています。

Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。

Oracleインスタンス

Oracleインスタンスには、1つ以上のシステム・コンポーネント(Oracle Webキャッシュ、Oracle HTTP Server、Oracle Internet Directoryなど)が含まれています。Oracleインスタンスのシステム・コンポーネントは、同一マシン上に置く必要があります。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されています。

Oracleインスタンスは、Oracle WebLogic Serverドメインのピアです。両方に、Oracleホーム外部の固有の構成が含まれます。

Oracleインスタンスのディレクトリ構造は、Oracleホームのディレクトリ構造とは別個です。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。

Oracle WebLogic Serverドメイン

WebLogic Serverドメインは、Javaコンポーネントの論理的関係があるグループです。WebLogic Serverドメインには、ドメイン内のすべてのリソースの構成および管理の中心である管理サーバーと呼ばれる特別なWebLogic Serverインスタンスが含まれています。通常、ドメインは、管理対象サーバーという追加のWebLogic Serverインスタンスを含めるように構成します。Webアプリケーション、EJB、Webサービスおよびその他のリソースなどのJavaコンポーネントは管理対象サーバーにデプロイし、管理サーバーは構成と管理を行う目的でのみ使用します。

WebLogic Serverドメインの管理対象サーバーは、クラスタにグループ化できます。

Oracle WebLogic Serverドメインは、Oracleインスタンスのピアです。両方に、Oracleホーム外部の固有の構成が含まれます。

WebLogic Serverドメインのディレクトリ構造は、WebLogic Serverホームのディレクトリ構造とは別です。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。

システム・コンポーネント

システム・コンポーネントは、WebLogic Serverではない管理可能プロセスです。たとえば、Oracle HTTP Server、Webキャッシュ、Oracle Internet Directoryです。JSEコンポーネントを含めます。

Javaコンポーネント

Javaコンポーネントは、システム・コンポーネントと同等ですが、アプリケーション・サーバー・コンテナによって管理されます。通常、一連のアプリケーションおよびリソースを参照し、通常ドメイン拡張子テンプレートと一対一の関係を持ちます。たとえば、SOAとWebCenter Spacesです。

Oracle Fusion Middlewareファーム

Oracle Enterprise Manager Fusion Middleware Controlは、Webブラウザ・ベースのグラフィカル・ユーザー・インタフェースで、Oracle Fusion Middlewareファームを監視および管理するために使用できます。

Oracle Fusion Middlewareファームは、Fusion Middleware Controlによって管理されるコンポーネントの集合です。Oracle WebLogic Serverドメイン、1つ以上の管理対象サーバー、およびドメインにインストールされ、構成され、稼働しているOracle Fusion Middlewareシステム・コンポーネントで構成されます。

Oracle Identity Management

Oracle Fusion Middlewareのアイデンティティおよびアクセス管理コンポーネントのスイート。詳細は、「統合で使用されるOracle Identity Managementコンポーネントの概要」を参照してください。

WebLogic管理サーバー

管理サーバーは、WebLogicドメイン内のすべてのリソースを構成および管理するための中心ポイントです。

WebLogic管理対象サーバー

管理対象サーバーは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービスおよびそれらに関連するリソースをホストするための追加のWebLogic Serverインスタンスです。1つのドメイン内で複数の管理対象サーバーが稼働できます。ドメイン内の特定の管理対象サーバーは、特にOracle Fusion Middlewareコンポーネントをホストするために作成されます。

1.3 統合で使用されるOracle Identity Managementコンポーネントの概要

この項では、このガイドで統合について説明するOracle Identity Managementコンポーネントの簡単な概要と統合の利点について説明します。

内容は次のとおりです。

1.3.1 Oracle Unified Directory

Oracle Unified Directoryは、次世代の包括的なディレクトリ・サービスです。これは大規模なデプロイメントに対応し、要件の厳しい環境で高いパフォーマンスを提供するように設計されています。

Oracle Unified Directoryサーバーは、すべてJavaで記述されているLDAPv3準拠ディレクトリ・サーバーです。ディレクトリ・サーバーは完全なLDAPv3準拠、高いパフォーマンスと領域効率のいいデータ・ストレージ、容易な構成および管理を提供します。

このドキュメントのいくつかの手順では、アイデンティティ・ストアのリポジトリとしてOracle Unified Directoryを使用します。

1.3.2 Oracle Internet Directory

Oracle Internet Directoryは、分散したユーザーおよびネットワーク・リソースに関する情報の高速検索と集中管理を可能にする汎用ディレクトリ・サービスです。これは、Lightweight Directory Access Protocol (LDAP)バージョン3と、Oracle Databaseの高いパフォーマンス、スケーラビリティ、堅牢性および可用性を組み合せたものです。

Oracle Internet Directoryは、アイデンティティ管理コンポーネントおよび他のアプリケーションによって利用されるユーザー・アイデンティティが格納されるアイデンティティ・ストアのリポジトリとして機能できます。

1.3.3 Oracle Access Management Access Manager

Oracle Access Management Access Managerは、全面的なWeb周辺のセキュリティ機能を提供します。これにはWebシングル・サインオン、認証および認可、ポリシー管理、監査などが含まれます。Oracle Identity Managementスタックのすべての既存のアクセス・テクノロジは、Access Managerに集約されています。

Access Managerとの統合の詳細は、次を参照してください。

1.3.3.1 IDMDomainエージェントおよびWebゲートに関するノート

デフォルトでは、IDMDomainエージェントはOracle HTTP Serverのデプロイメントで有効化されます。IDMDomainエージェントからWebゲート・エージェントに移行する場合は、次の点に注意してください。

  • WebゲートでIDMDomainのpreferredHostを使用している場合、IDMDomain用の保護ポリシー設定をWebゲート用として再使用できます。

  • IDMDomainとWebゲートは共存できます。Oracle HTTP ServerのデプロイメントでIDMDomainエージェントによってWebゲート・エージェントが検出された場合、IDMDomainエージェントは休眠状態になります。

1.3.4 Oracle Identity Governance

Oracle Identity Managementは、エンタープライズITリソース内のユーザーのアクセス権限を自動的に管理する、強力かつ柔軟なエンタープライズ・アイデンティティ管理システムです。Oracle Identity Governanceは、企業のすべてのリソースにわたってユーザー・アクセス権限を管理するために基礎から設計されており、最初のアクセス権限の作成からビジネス要件の変化に対する動的な対応に至るまでアイデンティティ管理ライフサイクル全体を管理します。

1.3.5 Oracle Access Management Identity Federation

クラウド、WebサービスおよびB2Bトランザクションにおけるフェデレーテッド認証のサポートを向上するために、11g リリース2 (11.1.2)のシングル・アクセス管理サーバーにSAMLベースのフェデレーション・サービスが導入されます。Oracle Access Management Identity Federationは、パートナ間で安全にアイデンティティ情報を交換するための、エンタープライズ・レベルかつキャリア・グレードのサービスです。Identity Federationは、多様なデータ・ストア、ユーザー・ディレクトリ、認証プロバイダおよびアプリケーションと統合することによって既存のIT投資を保護します。

この初期リリースでは、Identity Federationはサービス・プロバイダ・モードのみに制限されています。アイデンティティ・プロバイダ・モードではOracle Identity Federation 11gR1のインストールが必要です。

Access ManagerとのIdentity Federationサービスの使用方法の詳細は、「Identity Federationとの統合」を参照してください。

1.4 Oracle Identity Management統合のクイック・リンク

統合手順へのリンク

表1-2は、ここで説明する統合手順へのリンクを示しています。

表1-2 このガイドの統合手順へのリンク

統合するコンポーネント リンク

Access ManagerとLDAPディレクトリ

Oracle Access ManagerとLDAPの統合

Access ManagerとOracle Identity Governance

Oracle Identity GovernanceとOracle Access ManagerおよびLDAPコネクタとの統合

Access ManagerとIdentity Federation

Identity Federationとの統合

マルチディレクトリ・アイデンティティ・ストア

複数ディレクトリのアイデンティティ・ストアの構成

表1-3は、他のOracle Identity Managementドキュメントに記載される主な統合手順を示しています:

表1-3 他のガイドの統合手順へのリンク

統合するコンポーネント リンク

OIGとOracle Identity Analytics (OIA)

『Oracle Identity Governanceの管理』Identity Analyticsとの統合に関する項

1.5 パスワード管理シナリオについて

これらのデプロイ・モードによってサポートされている一般的な管理シナリオには、次のものが含まれます。

1.5.1 Access ManagerをOracle Identity Governanceと統合する場合について

**INTERNAL XREF ERROR**は、Access ManagerとOracle Identity Governanceが統合された場合にパスワード管理がどのように実現されるかを示しています。

図1-3 パスワード管理のためのAccess ManagerとOracle Identity Governanceの統合


パスワード管理のためのAccess ManagerとOracle Identity Governanceの統合

コンポーネント間の相互作用のフローは次のとおりです。

  1. ユーザーは、Access Managerによって保護されたリソースにアクセスを試みます。

  2. Oracle Access Management Webゲートにより、(未認証の)リクエストが捕捉されます。

  3. WebゲートによりユーザーがAccess Managerログイン・サービスにリダイレクトされ、そこで検証チェックが実行されます。

  4. Access Managerによりパスワード期限切れなどのパスワード管理トリガー条件が検出されると、ユーザーがOracle Identity Governanceにリダイレクトされます。

  5. Oracle Identity Governanceにより、ユーザーとの相互作用を通じてユーザーのアイデンティティが確立され、パスワードのリセットなどの適切なアクションが実行されます。

  6. Access Managerにより、自動ログインを通じてユーザーのログインが行われ、ユーザーがAccess Managerによって保護されたリソース(ユーザーがステップ1でアクセスしようとしていたもの)にリダイレクトされます。

1.5.2 自己登録について

このシナリオでは、アカウントを持たないユーザーがAccess Managerによって保護されたリソースにアクセスしようとします。Oracle Access Management 11g Webゲートにより、このリクエストが捕捉され、ユーザーが認証されていないことが検出され、ユーザーがOracle Access Management資格証明コレクタにリダイレクトされ、そこで「新規アカウントの登録」リンクを含むAccess Managerログイン・ページが表示されます。

このリンクを選択すると、ユーザーは安全にOracle Identity Governanceの自己登録URLにリダイレクトされます。Oracle Identity Governanceにより、ユーザーとの相互作用を通じてそのアカウントがプロビジョニングされます。

ようこそページは、自己登録/アカウント作成を開始できる、保護されていないページです。このページには、2つのリンクが紹介テキストまたはブランド情報とともに表示されます。これらのリンクは:

  • 新規アカウントの登録 - これは、対応するアプリケーションの登録ウィザードへの保護されていないURLです。

  • ログイン - これは、ログイン成功後にユーザーが転送されるランディング・ページとして機能する、保護されたURLです。

ノート:

自己登録要件があるシングル・サインオン・システムによって保護されたアプリケーションは、自己登録ページをサポートすることが予期されます。オプションは:

  • デフォルトの自己登録ページまたはカスタマイズされたバージョンのページを使用した自己登録。

    これは最も一般的なオプションであり、ここで説明されています。

  • 他のアプリケーションの匿名ページを使用した自己登録。

    アプリケーションにより登録プロセスの最後にユーザーを自動的にログインするように指示する場合は、Oracle Platform Security Services APIを使用することによってこれを実装できます。

アカウント作成フローは次のとおりです。

  1. ユーザーは、(ブラウザを使用して)「新規アカウントの登録」リンクを含むアプリケーションのようこそページにアクセスします。

  2. ユーザーは、「新規アカウントの登録」リンクをクリックし、アプリケーションによって提供された自己登録ページに転送されます。

  3. ユーザーは、アプリケーションと相互作用して自己登録します。

  4. 完了すると、アプリケーションによりユーザーの自動ログインが実行されます。

保護されたアプリケーションにより、ユーザーを作成するためにOracle Identity GovernanceにSPMLリクエストが送信されることが予期されます。この後、アプリケーションにより次のいずれかの操作が選択されます。

  • アプリケーションにより、ユーザーを自動ログインしないことを選択できます。アプリケーションにより、ユーザーを保護されたランディング・ページURLにリダイレクトします。その後、Access Managerによりログイン・ページが表示され、ユーザーがログイン・フローに進みます。

  • リクエストに関連付けられた承認がない場合は、アプリケーションにより、Oracle Platform Security Services (OPSS) APIを利用して特定のランディング・ページURLに自動ログインし、そのURL(およびSSO Cookie)を含んだリダイレクト・リクエストで応答します。これにより、ログイン・ページを表示せずにユーザーが直接ランディング・ページに転送されます。

  • 承認が必要な場合、自動ログインは実行できません。アプリケーションにより、SPMLリクエストの時点でどのプロファイルを使用するかが決定されます。アプリケーションにより、リクエストが送信されたことを示す適切なページで応答する必要があります。

1.5.3 パスワードの変更について

パスワードの変更フローにより、ユーザーは各自のパスワードを変更できます。

Access ManagerおよびOracle Identity Governanceによるパスワードの変更フローでは、ユーザーはAccess Managerに正常にログインした後、すぐにパスワードを変更する必要があります。ユーザーは、パスワードを変更してチャレンジを設定するまで、保護されたリソースへのアクセスを許可されません。

ログインが成功すると、Access Managerによりトリガー条件が有効であるかどうかが検出され、ユーザーがOracle Identity Governanceの「パスワードの変更」URLにリダイレクトされます。Oracle Identity Governanceでは、ユーザー・パスワードの変更またはチャレンジの設定を容易にし、トリガー条件をリセットします。

完了すると、Oracle Identity Governanceによりユーザーが保護されたリソースにリダイレクトされます。

この状況は、次の場合にトリガーされます。

  • Change Password upon Loginフラグがオンになっています。これが発生する場合:

    • 新しいユーザーが作成された場合

    • 管理者がユーザーのパスワードをリセットした場合

  • パスワードの有効期限が切れました。

このフローでは、ユーザーが初めてAccess Managerによって保護されたアプリケーションにログインし、次に進む前にパスワードの変更を求められる状況について説明します。

パスワードの変更フローは次のとおりです。

  1. ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。

  2. Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。

  3. ユーザーは資格証明を送信し、これがAccess Managerにより検証されます。

  4. 続いてAccess Managerにより、初回ログインのトリガー条件のいずれかが有効であるかどうかが判別されます。有効である場合は、Access Managerにより、ユーザーがOracle Identity Governanceの「パスワードの変更」URLにリダイレクトされます。

  5. Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、Oracle Identity Governanceが匿名認証ポリシーによって保護されていることが判別され、ユーザー・リクエストの処理が許可されます。

  6. Oracle Identity Governanceにより、ユーザーとの相互作用を通じてユーザーがパスワードを変更できるようになります。完了すると、Oracle Identity Governanceにより「初回ログイン」フローをトリガーした属性が更新されます。続いてOracle Identity Governanceにより、ユーザーの自動ログインが実行されます。

  7. Oracle Identity Governanceにより、Access Managerに初回ログインの成功が通知されます。

  8. Oracle Identity Governanceにより、ステップ1でユーザーがアクセスしようとしていたアプリケーションURLにユーザーがリダイレクトされます。

1.5.4 パスワードを忘れた場合について

パスワードを忘れた場合のフローでは、ユーザーはすべてのチャレンジ質問に正しく回答した後で各自のパスワードをリセットできます。

このシナリオでは、ユーザーはAccess Managerログイン・ページを表示して「パスワードを忘れた場合」リンクをクリックします。Access Managerにより、ユーザーはOracle Identity Management「パスワードを忘れた場合」URLにリダイレクトされ、パスワードの変更に成功したときにOracle Identity Governanceによるリダイレクト先となる宛先URLが問合せパラメータ(backURL)として渡されます。

Oracle Identity Managementにより、ユーザーに対してチャレンジ質問が尋ねられます。正しい回答を入力すると、ユーザーは新しいパスワードを指定できます。

完了すると、Oracle Identity Managementによりユーザーが保護されたリソースにリダイレクトされます。

パスワードを忘れた場合のフローは次のとおりです。

  1. ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。

  2. Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。

  3. ユーザーはAccess Managerログイン・ページで「パスワードを忘れた場合」リンクをクリックし、これによりユーザーはOracle Identity Governanceの「パスワードを忘れた場合」URLに送信されます。

  4. Oracle Identity Governanceにより、ユーザーとの相互作用を通じてユーザーがパスワードをリセットできるようになります。完了すると、Oracle Identity Governanceによりユーザーの自動ログインが実行されます。

  5. Oracle Identity Governanceにより、ステップ1でアクセスしようとしていたアプリケーションURLにユーザーがリダイレクトされます。

1.5.5 アカウントのロックとロック解除について

Access Managerでは、ログイン試行を追跡し、その回数がパスワード・ポリシーで確立された制限を超えるとアカウントをロックします。

ユーザー・アカウントがロックされた後は、ログイン試行に対して、Access Managerによりヘルプ・デスクの連絡先情報および「パスワードを忘れた場合」リンク、または同様の情報が表示されます。アカウントのロック解除プロセスに関して提供される情報は、各自の組織で従うプロセスを反映したものにカスタマイズされている必要があります。

アカウントのロックとロック解除のフローは次のとおりです。

  1. ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスを試みます。

  2. Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。

  3. ユーザーは資格証明を送信し、これがAccess Managerによる検証に失敗します。Access Managerによりログイン・ページがレンダリングされ、ユーザーは資格証明を再送信するように求められます。

  4. ユーザーのログイン試行の失敗回数がポリシーで指定された制限を超えます。Access Managerによりユーザー・アカウントがロックされ、ユーザーがAccess ManagerのアカウントのロックアウトURLにリダイレクトされます。ページが開いてヘルプ・デスクの連絡先情報および「パスワードを忘れた場合」リンクが表示されます。

  5. ユーザーがヘルプ・デスクに電話で連絡し、管理者にアカウントのロック解除を依頼すると、次のようになります。

    1. ヘルプ・デスクがOracle Identity Governance管理コンソールを使用してアカウントをロック解除します。

    2. Oracle Identity Governanceにより、Access Managerにアカウント・ロック解除イベントが通知されます。

    3. ユーザーはアプリケーションURLにアクセスしようとし、このイベントにより通常のOracle Access Managementシングル・サインオン・フローがトリガーされます。

  6. ユーザーが「パスワードを忘れた場合」リンクを使用すると、ユーザーがOracle Identity Governanceの「パスワードを忘れた場合」URLに送信され、次のようになります。

    1. Oracle Identity Governanceにより、ユーザーとの相互作用を通じてユーザーがパスワードをリセットできるようになります。完了すると、Oracle Identity Governanceによりユーザーの自動ログインが実行されます。

    2. Oracle Identity GovernanceによりユーザーがアプリケーションURLにリダイレクトされます。

    ノート:

    ユーザー・ステータスがOracle Identity Governanceでロックされた場合のみ、ユーザーはOracle Identity Governanceの「パスワードを忘れた場合」フローを通じてアカウントを自分でロック解除できます。ユーザーのロック済ステータスは、「SSOユーザー増分リコンシリエーション」または「SSOユーザー完全リコンシリエーション」というスケジュール化されたジョブが実行されたときのみLDAPプロバイダからOracle Identity Governanceに同期されます。

1.5.6 チャレンジの設定について

チャレンジの設定により、ユーザーはチャレンジ質問および回答を登録できます。

このようなリダイレクトが発生した場合、Oracle Identity Managementによりチャレンジ質問が設定されているかどうかがチェックされます。設定されていない場合、ユーザーはパスワードをリセットするとともにチャレンジ質問を設定するように求められます。

Access Managerによる検出とリダイレクトは次のパスワード・トリガー条件で行われます。

  • 必要な数のチャレンジを増やすためにパスワード・ポリシーが更新されました。

  • チャレンジを要求するためにパスワード・ポリシーが更新されました

フローは次のとおりです。

ノート:

このフローは、初回ログインが必要ではないことを前提としています。

  1. ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。

  2. Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。

  3. ユーザーは資格証明を送信し、これがAccess Managerにより検証されます。パスワード・トリガー条件が検出された場合は、Access Managerにより、ユーザーがOracle Identity Governanceのパスワードの変更URLにリダイレクトされます。

  4. Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、Oracle Identity Governanceが匿名認証ポリシーによって保護されていることが判別され、ユーザー・リクエストの処理が許可されます。

  5. Oracle Identity Governanceにより、ユーザーとの相互作用を通じてチャレンジが設定されます。完了すると、Oracle Identity Governanceによりチャレンジの設定フローをトリガーした属性が更新されます。

  6. Oracle Identity Governanceにより、ステップ1でユーザーがアクセスしようとしていたアプリケーションURLにユーザーがリダイレクトされます。

1.6 システム要件と動作保証情報

ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システムの互換性、要件および動作保証情報のドキュメントを参照してください。

互換性に関するドキュメントでは、Oracle Fusion Middleware 12cコンポーネントをインストール、パッチ適用またはアップグレードする際に生じる可能性がある、互換性および相互運用性に関する考慮事項が説明されています。詳細は、『相互運用性および互換性の理解』を参照してください。

システム要件のマニュアルには、ハードウェアおよびソフトウェア要件、最小ディスク領域およびメモリー要件、必要なシステム・ライブラリ、パッケージ、パッチなどの情報が記載されています。

動作要件のドキュメントには、サポートされているインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDK、ディレクトリ・サーバーおよびサードパーティ製品が記載されています。

ノート:

Oracle Identity Management統合コンポーネントは、次のオペレーティング・システムをサポートしていません:
  • AIX
  • HPUX Itanium
  • Microsoft Windows

最新の要件および動作保証情報のドキュメントについては、『相互運用性および互換性の理解』の表のOracle Fusion Middlewareの動作保証マトリックスについての説明を参照してください。

1.7 My Oracle Supportを使用したその他のトラブルシューティング情報

Oracle Fusion Middlewareの問題の解決にMy Oracle Support (以前のMetaLink)を使用できます。

My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。

  • ナレッジ・ベース記事

  • コミュニティ・フォーラムとディスカッション

  • パッチとアップグレード

  • 動作保証情報

ノート:

My Oracle Supportを使用してサービス・リクエストを記録することもできます。

My Oracle Supportには、https://support.oracle.comからアクセスできます。