| Oracle® Fusion Middleware Oracle Identity Management Suite統合ガイド 11g リリース2 (11.1.2.3.0) E67361-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Management Suite統合ガイド 11g リリース2 (11.1.2.3.0) E67361-04 |
|
前 |
次 |
この章では、Oracle Identity Managementスイートの統合の概念について説明します。
内容は次のとおりです。
このドキュメントの手順を使用してOracle Identity Managementのコンポーネントを統合する前に、それらのコンポーネントをインストールおよびデプロイする必要があります。この前提条件について、次の項で説明します。
Oracle Identity Managementのコンポーネントのインストールの詳細は、次のものを参照してください。
Oracle Identity and Access Managementインストレーション・ガイド
Oracle Fusion Middleware Oracle Identity and Access Managementクイック・インストレーション・ガイド
IdMデプロイメントでは次のいずれかの工程を使用します(すでに使用している可能性もあります)。
インストール、続いてコンポーネント統合、最後にスケールアウト(HA)
インストール、続いてスケールアウト、最後に統合
スケールアウトでは、ここで説明する統合手順の一部をすでに実行している場合があります。関連する項の注記によって、手順が必要かどうかを判断できます。
『Oracle Identity and Access Managementインストレーション・ガイド』の「概要」の章には、インストールのロードマップ、前提条件、インストールおよび構成のワークフローなどIdMのデプロイメント手順の基礎知識が記載されています。
高可用性ガイドのOracle Fusion Middlewareの高可用性ソリューションに関する項では、Oracle Fusion Middlewareの高可用性ソリューションを説明すると同時に、各種のHAオプションのトポロジおよびアーキテクチャについても説明します。
アイデンティティ管理のトポロジおよびそれらのコンポーネントが連動する環境についても理解する必要があります。
このドキュメントでサポートされているトポロジの詳細は、第1.2項を参照してください。
この統合を開始する前に、Oracle Identity ManagerでLDAP同期を有効化してください。
インストール中にOIM構成ウィザードを使用してLDAP同期を有効化しなかった場合は、付録E「Oracle Identity ManagerにおけるLDAP同期の有効化」で手順を参照してください。
次のトピックでは、LDAPアイデンティティ・ストアとOracle Identity Manager間の統合の概要を示します。
Oracle Identity Managerには、LDAPベースのアイデンティティ・ストアをOracle Identity Managerアーキテクチャに統合する機能があります。Oracle Identity Managerから直接LDAPベースのアイデンティティ・ストアを接続および管理できます。この機能を使用すると、アイデンティティのリクエスト・ベースの作成および管理を含めたOracle Identity Managerの高度なユーザー管理機能を使用して、企業のアイデンティティ・ストア内でアイデンティティを管理できます。
このデプロイメント・アーキテクチャでは、ユーザー・アイデンティティ情報が、LDAPストアに加えてOracle Identity Managerデータベースにも格納されるため、Oracle Identity Managerが機能するために必要なリレーショナル機能がサポートされます。すべてのデータは、プロビジョニング・アクションの実行やポリシーおよびルールの設定なしで、透過的に同期が維持されます。ユーザーの作成や変更など、Oracle Identity Manager内で開始されるアイデンティティ操作は、トランザクションの整合性を維持する形で両方のストアで実行されます。さらに、Oracle Identity Manager外部で行われたLDAPストアの変更は、Oracle Identity Managerにプルされ、アイデンティティ・コンテキストの一部として使用できるようになります。
Oracle Identity Managerのユーザーおよびロールは、Oracle Identity Managerデータベースに格納されます。ただし、Oracle Identity Managerでユーザー、ロールまたはロール・メンバーシップの変更が発生した場合、この情報はLDAPアイデンティティ・ストアに伝播されます。ユーザー、ロールまたはロール・メンバーシップの変更がLDAPで直接発生した場合、これらの変更はOracle Identity Managerに同期化されます。同期化には、次のことが含まれます。
Oracle Identity Managerで行われる変更: ユーザーの作成、変更、削除、有効/無効の状態とロック済/ロック解除済の状態における変更、およびパスワード変更が、LDAPに同期化されます。
ロールの作成、変更および削除アクションにより、LDAPグループがメンバーシップ変更も含めて更新されます。
ユーザー、ロールおよびロール・メンバーシップの初期ロードが同期化されます。
LDAPでのユーザー・プロファイルに対する直接変更がOracle Identity Managerにリコンサイルされます。ただし、LDAPで行われたユーザー・パスワードへの変更はOracle Identity Managerにリコンサイルされません。
LDAPでのロールおよびロール・メンバーシップに対する直接変更がOracle Identity Managerにリコンサイルされます。
ユーザーおよびロール・データで変更が発生すると、実際の操作はカーネル・ハンドラを活用して実行されます。これらのハンドラは、検証、前処理、アクションおよび後処理など、オーケストレーション・ライフサイクルの様々な段階を通過します。
Oracle Identity Managerカーネル・オーケストレーションはエンティティ・マネージャに接続し、そのエンティティ・マネージャがさらにLDAPプロバイダに接続します。LDAPプロバイダはOracle Virtual Directory (OVD)およびIdentity Virtualization Library (libOVD)に接続します。OVDは、Oracle Internet Directory、iPlanet、Active Directoryなど、様々なディレクトリ・システムへのインタフェースです。LDAPプロバイダはOVDを使用してLDAPデータにアクセスします。libOVDは、Fusion Middlewareコンポーネント(Oracle Identity ManagerおよびAccess Managerなど)に組み込まれたLDAP仮想化レイヤー(OVDに基づく)です。これはOVDのようなスタンドアロンLDAPサーバーではありません。
図1-1に、Oracle Identity ManagerとLDAP間の通信を示します。
Oracle Identity ManagerとLDAPアイデンティティ・ストア間での統合の構成およびデータの同期化の詳細は、次の各項を参照してください。
Oracle Identity ManagerおよびLDAP間の統合の構成は、Oracle Identity Managerのインストール後に実行されます。LDAPをOracle Identity Managerと統合する際は、予約されたユーザーを格納するコンテナを作成し、Oracle Identity Managerの操作を実行する新規ユーザーをOracle Identity Managerに作成して、Oracle Identity Managerと連動するようにOVD (またはlibOVD)をディレクトリ・サーバーで構成する必要があります。このタスクについて、後述する項で説明します。
構成後ユーティリティは、E.2.1項「LDAP構成後ユーティリティの実行」に説明されているように、Oracle Identity Managerで次にスケジュールされているジョブを有効にします。これは、LDAPディレクトリで見つかった値で各ジョブの「最終変更番号」パラメータを更新します。
LDAPユーザー作成および更新のリコンシリエーション
LDAPユーザー削除のリコンシリエーション
LDAPロール・メンバーシップのリコンシリエーション
LDAPロール階層のリコンシリエーション
LDAPロール作成および更新のリコンシリエーション
LDAPロール削除のリコンシリエーション
さらに、「最終変更番号」パラメータを更新した後は、これらのスケジュール済ジョブを有効にする必要があります。これを行うには、『Oracle Identity Managerの管理』のジョブの無効化と有効化に関する項を参照してください。
|
関連項目: スケジュール済ジョブの詳細は、『Oracle Identity Managerの管理』のスケジュール済タスクの管理に関する項を参照してください。 |
Oracle Identity Managerデータベースには、ユーザーおよびロールの情報が格納されています。Oracle Identity Managerでユーザーおよびロールの情報が更新された場合は、LDAPディレクトリなどの外部リポジトリも更新する必要があります。
LDAPの変更は、Oracle Identity Managerの変更の前に実行されます。Oracle Identity Managerで変更が失敗した場合は、LDAPへの変更を元の状態に戻す必要があります。これは、有効化操作を無効化操作で、作成操作を削除操作でそれぞれ修正し、変更操作を当初の値を使用した変更操作で修正することによって実現します。
たとえば、ユーザーが作成された場合、検証段階では、パスワードや他のポリシーの検証などの検証プロセスが実行されます。前処理段階では、最初にLDAPにユーザーが作成されます。そのユーザーは、次のアクション段階で、Oracle Identity Managerに作成されます。Oracle Identity Managerでのユーザーの作成でエラーが発生した場合、Oracle Identity Managerには対応するユーザーが作成されていないため、そのユーザーはLDAPから削除する必要があります。変更を元に戻す操作は、Oracle Identity Managerに事前定義されている補正メソッドを使用したカーネル・ハンドラによって提供されます。
|
注意: 各ハンドラには、実行メソッドと補正メソッドが事前定義されています。実行メソッドでは、任意の操作(ユーザーの作成など)が実行されます。補正メソッドは、エラーが発生した場合にコールされ、実行メソッドが実行した操作を元に戻します。 |
Oracle Identity ManagerからLDAPに日付を同期化するには、LDAPの場所をOracle Identity Managerで把握している必要があります。LDAPの場所に関する情報は、Directory Server ITリソースとしてOracle Identity Managerに格納されます。これは、Oracle Identity Managerによって提供されるデフォルトのITリソースです。Oracle Identity Managerのインストール時に指定可能な、このITリソースの様々なパラメータを使用すると、Oracle Identity ManagerとLDAPを接続できます。
識別名(DN)およびGUID属性は、Oracle Identity ManagerとLDAPで同じエントリを識別するために使用されます。LDAPの各エントリにはDN属性があり、LDAP内でのエントリの一意の場所を示します。GUID属性は、エントリを識別するための一意のIDです。ユーザーおよびロールのDNとGUIDは、Oracle Identity Managerデータベースのユーザーおよびロールの表の列に格納されます。
この節では、以下のトピックについて説明します。
Oracle Identity ManagerからLDAPにデータを同期化するには、次のユーザー操作を実行できます。
ユーザーの作成
ユーザーの更新
ユーザーの削除
ユーザーの有効化
ユーザーの無効化
ユーザーのロック
ユーザーのロック解除
ロール・メンバーの追加
ロール・メンバーの削除
パスワードの変更
Oracle Identity ManagerからLDAPにデータを同期化するには、次のロール操作を実行できます。
ロールの作成
ロールの更新
ロールの削除
メンバーへのロールの追加
ロールの追加と更新
メンバーからのロールの削除
ロール階層の追加
ロール階層の削除
LDAPアイデンティティ・ストアでアイデンティティが直接変更された場合は、認証ソースのリコンシリエーションを介して、その変更をOracle Identity Managerにレプリケートする必要があります。アイデンティティには、ユーザーおよびロールが含まれます。
LDAPからOracle Identity Managerへのユーザーのリコンサイルは、リコンシリエーションのスケジュール済タスクが含まれているリコンシリエーションの一般構成で機能します。
|
関連項目: スケジューラおよびスケジュール済タスクの詳細は、『Oracle Identity Managerの管理』のスケジュール済タスクの管理に関する項を参照してください。 |
|
注意: LDAPからOracle Identity Managerにユーザーをリコンサイルする際に、LDAP同期化リコンシリエーション・ジョブではなく、バルク・ロード・ユーティリティを使用すると、LDAP同期化が有効な場合は、これらのユーザーに関する後続の操作に失敗する可能性があります。これを回避するには、Oracle Identity Managerにロードされているすべてのユーザーを正しいGUIDおよびDNの値で更新し、LDAP内のこれらのユーザーすべてをorclIDXPersonと呼ばれるオブジェクト・クラスで更新する必要があります。バルク・ロード・ユーティリティの詳細は、『Oracle Identity Managerのためのアプリケーションの開発とカスタマイズ』のバルク・ロード・ユーティリティの使用に関する項を参照してください。 |
ロールのリコンシリエーションは、LDAPグループでのみ機能します。ロールのリコンシリエーションでは、ロールの作成、更新および削除がサポートされています。ロール・メンバーシップのリコンシリエーションでは、外部のLDAPディレクトリで発生した変更から導出されたロール・メンバーシップの作成と削除がサポートされています。
Oracle Identity Managerにロールおよびユーザーが存在しない場合、ロール・メンバーシップのリコンシリエーションは失敗します。したがって、LDAP同期化スケジュール済ジョブは、次の順序で実行するように構成してください。
Fusion Applicationsロール・カテゴリ・シーディング
|
注意: Fusion Applicationsロール・カテゴリ・シーディングは事前定義済のスケジュール済タスクで、LDAP同期化が有効な場合のみ、他のLDAP同期化スケジュール済ジョブとともに生成されます。このジョブは、LDAP内の異なるビジネス・カテゴリをすべて取得し、OIMロール・カテゴリとして作成します。事前定義されたスケジュール済ジョブのリストは、『Oracle Identity Managerの管理』の事前定義済のスケジュール済タスクに関する項を参照してください。 |
LDAPロール作成および更新のリコンシリエーション
LDAPロール階層のリコンシリエーション
LDAPユーザー作成および更新のリコンシリエーション
LDAPロール・メンバーシップのリコンシリエーション
Fusion Applicationsロール・カテゴリ・シーディングを除くこれらの各ジョブには、完全リコンシリエーションを実行するためのパラレル・ジョブがあります。Fusion Applicationsロール・カテゴリ・シーディングを除くこれらすべてのジョブは、変更ログに基づいてリコンシリエーションを実行しますが、完全リコンシリエーション・ジョブは、検索ベースを使用してリコンシリエーションを実行します。
統合されたLDAP完全リコンシリエーションのスケジュール済ジョブは、次のジョブを順番に実行します。
LDAPユーザー作成および更新の完全リコンシリエーション
LDAPロール作成および更新の完全リコンシリエーション
LDAPロール・メンバーシップの完全リコンシリエーション
LDAPロール階層の完全リコンシリエーション
|
関連項目: 統合されたLDAP完全リコンシリエーションのスケジュール済ジョブの詳細は、『Oracle Identity Managerの管理』のLDAPスケジュール済タスクに関する項を参照 |
統合されたLDAP完全リコンシリエーションのスケジュール済ジョブを実行すると、次のジョブを特定の順序で実行する必要があるため、以前のジョブのジョブ・ステータスや特定ジョブのイベント・ステータスがすべてチェックされます。実行できないジョブがあれば、ジョブの停止が自動実行され、診断ログにエラー・メッセージが記録されます。
|
注意: LDAPユーザー削除の完全リコンシリエーション・ジョブとLDAPロール削除の完全リコンシリエーション・ジョブは、統合されたLDAP完全リコンシリエーションの一部ではありません。これらのスケジュール済ジョブは、デフォルトで使用禁止にされています。ラジオ・ボタンを選択すると有効にでき、それぞれを実行することもできます。 |
統合されたLDAP同期化完全リコンシリエーション・ジョブの詳細ページのラジオ・ボタンを選択して、それぞれのジョブを実行することもできます。ジョブの詳細ページには、4種類の完全リコンシリエーション・ジョブに対するすべての共通パラメータがあります。また、統合されたLDAP同期化完全リコンシリエーションのスケジュール済ジョブの次のパラメータに対して値を指定できます。
リコンシリエーション検索ベース: ユーザーまたはロールの完全リコンシリエーションに対する検索ベース。これにより、LDAPが検索を開始するLDAPディレクトリ内の場所が定義されます。
リコンシリエーション・ロール検索フィルタ: ロールの完全リコンシリエーションに対する検索フィルタ。このフィルタにより、LDAPディレクトリのサブツリー内の特定のロール/グループ・エントリを可能にし、その他を除外できます。
リコンシリエーション・ユーザー検索フィルタ: ユーザーの完全リコンシリエーションに対する検索フィルタ。このフィルタにより、LDAPディレクトリのサブツリー内の特定のユーザー・エントリを可能にし、その他を除外できます。
統合されたLDAP同期化完全リコンシリエーション・ジョブを実行すると、リコンシリエーション検索ベースおよび/またはリコンシリエーション・ユーザー検索フィルタおよびリコンシリエーション・ロール検索フィルタのパラメータに入力された値に基いて、LDAPからOracle Identity Managerにユーザー・アカウントおよびロール・アカウントが投入されます。この完全リコンシリエーションの結果、LDAPの特定のノードから削除されたエントリに対してOracle Identity Managerデータベースで削除されます。
リコンシリエーション検索ベースおよびリコンシリエーション検索フィルタのパラメータは、次のユースケースをサポートします(サンプル・パラメータが示されます)。
LDAPからOracle Identity Managerデータベースへのユーザー・アカウントまたはロール・アカウントのリコンサイル
これにより、特定のユーザーまたはロールのきめ細かなリコンシリエーションを実行するオプションが提供されます。リコンシリエーション検索ベース・パラメータの値は、次のようになります。
"cn=sampleuser1,cn=users,cn=subrealm1,dc=us,dc=example,dc=com"
ノード下のすべてのユーザーおよびロールまたはグループのリコンサイル
リコンシリエーション検索ベースの値は、次のようになります。
"cn=subrealm1,dc=us,dc=example,dc=com"
ここで、ユーザーの完全リコンシリエーションとロールの完全リコンシリエーションが起動されます。その結果、tenant1ノード下のすべてのユーザーおよびロールまたはグループがリコンサイルされます。
ノード下のすべてのユーザーのリコンサイル:
リコンシリエーション検索ベースの値は、次のようになります。
"cn=users,cn=subrealm1,dc=us,dc=example,dc=com"
ここで、tenant1ノード下のすべてのユーザーがリコンサイルされます。
ノード下のすべてのロールまたはグループのリコンサイル:
リコンシリエーション検索ベース・パラメータの値は、次のようになります。
"cn=groups,cn=subrealm1,dc=us,dc=example,dc=com"
ここで、tenant1ノード下のすべてのロールまたはグループがリコンサイルされます。
リコンシリエーション検索ベースおよびリコンシリエーション検索フィルタのパラメータは、LDAP同期化完全リコンシリエーションにはバインドされていません。リコンシリエーション検索フィルタは空白にできます。検索ベースは、Oracle Identity ManagerからLDAPへのプロビジョニングまたはエントリの投入に使用できます。一方、リコンシリエーション検索ベースは、LDAPからOracle Identity Managerデータベースへの完全リコンシリエーションの実行に使用できます。リコンシリエーション検索ベースに値が指定されない場合、プロビジョニングと完全リコンシリエーションの両方に対してディレクトリ・サーバーのITリソース構成の検索ベースの値が使用されます(リコンシリエーション検索ベース・パラメータのサンプル値は、次のようになります)。
"cn=subrealm1,dc=us,dc=example,dc=com"
検索ベース・パラメータのサンプル値は、次のようになります。
"dc=us,dc=example,dc=com"
リコンシリエーション・ユーザー検索フィルタおよびリコンシリエーション・ロール検索フィルタのパラメータのサンプル値は、次のようになります。
(objectclass=orclAPPIDPerson) (title=foobar)
統合されたLDAP同期化完全リコンシリエーションのスケジュール済ジョブに対してログ記録されたメッセージ
次のリストは、統合されたLDAP同期化完全リコンシリエーションのスケジュール済ジョブに対して、Oracle Identity Manager診断ログ・ファイルに記録されたメッセージです。
LDAP Sync Full Reconciliation Scheduler job {0} is currently Running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Stopped.
LDAP Sync Full Reconciliation Scheduler job {0} is currently being Interrupted while running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Failed.
Error occurred while running the LDAP Sync User Full Reconciliation scheduler job. Please refer to the OIM Server logs for more details.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has been Shutdown.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running.
SQLException has occurred.
All LDAPSync Full Reconciliation jobs ran successfully and Stopped.
Oracle Virtual DirectoryをOracle Access Management Access Manager (Access Manager)とともに使用することは、オプションです。ただしOracle Virtual DirectoryをAccess Managerとともに使用することを計画している場合は、この文献に記載されている主な統合手順を開始する前に、Access Managerとの統合用にOracle Virtual Directoryを構成する必要があります。
手順については、付録F「Oracle Access Management Access Managerと統合するためのOracle Virtual Directoryの構成」を参照してください。
このドキュメントでは、共通環境変数を示すために短縮表記を使用します。たとえば、Oracle Middlewareホーム・ディレクトリはほとんどの場合、MW_HOMEと示されます。
共通環境変数のリストについては、『Oracle Identity and Access Managementインストレーション・ガイド』のインストール・ディレクトリの特定に関する項を参照してください。
Oracle Identity Managementは、個別または集合で使用できる多数のアプリケーションから構成されます。Oracle Identity Managementで使用できる2つの基本的なタイプのトポロジは、次のとおりです。
基本統合トポロジ
このトポロジでは、各コンポーネントが別のノードで実行されている環境におけるスイート・コンポーネント間の統合がサポートされます。
エンタープライズ統合トポロジ
このトポロジは、エンタープライズ環境におけるスイート・コンポーネント間の統合をサポートします。各コンポーネントは複数のノードで実行される場合があります。
このドキュメントで説明するトポロジ
このドキュメントでは、最初のタイプの、単一ノード統合トポロジについてのみ説明します。各コンポーネントが各自のノードで実行される環境にOracle Identity Managementをデプロイする場合は、このドキュメントで説明する手順を使用してください。この手順は、統合ツールおよび手法を理解するため、特定のアイデンティティ管理コンポーネントを統合することによる効果と利点について理解するためにも使用できます。
図1-2は、IdMコンポーネントのAccess ManagerとOracle Identity Managerが別々のWebLogicドメインで構成されている、基本統合トポロジを示しています。
注意:
Access Managerサーバー(AMHOST)、Oracle Identity Managerサーバー(OIMHOST)、およびOracle Internet Directory (OID)を含むすべてのIdMコンポーネントが別々のWebLogicドメインで構成され、それぞれが各自の管理サーバーで管理されています。
このトポロジは各コンポーネントの管理性を高め、さらにパッチおよびアップグレードの適用時における柔軟性を保証します。各コンポーネントのパッチは単独で適用することが可能で、他のコンポーネントへのバージョン依存性はありません。
簡潔にするため、OMSSトポロジの一部は省略されています。たとえば、DMZに存在するMSASサーバーは図に表示されていません。OMSSアーキテクチャの詳細は、第5.2項を参照してください。
BIPサーバーおよびSOA SuiteがOIMドメイン上に存在します。これらは図に表示されていません。
この図は、いくつかの代理ポートのみを示しています。
Oracle Identity ManagerのSOA Suiteについて
OIMで使用されるSOA Suiteは、OIMと同じドメイン内にインストールする必要があります。ただし、SOA Suiteを他の目的に使用する場合は、その目的のための固有サービス、コンポジットおよびその他のSOA機能を実行するために、別のSOA Suiteのインストールの設定を検討してください。
単一ドメイン・アーキテクチャについて
単一ドメイン・アーキテクチャでは、Oracle Access Management Access Manager、Oracle Identity ManagerおよびMobile Security Access Serverは同じWebLogicドメイン上に構成されます。可能ではありますが、このようなトポロジは前述の理由のため現在のコンテキストで現実的ではなく、IdM統合に推奨されません。
このアーキテクチャは、3つのレイヤーまたはゾーンで構成されているとみなすことができます。
Web層はHTTPサーバーで構成されており、受信Webトラフィックを処理します。
アプリケーション層には、Oracle Identity ManagerやOracle Access Managerなど、アイデンティティおよびアクセスを管理するためのアイデンティティ管理アプリケーションが含まれています。
データ層(ここではディレクトリ・サーバーを含むとみなす)は、LDAPおよびデータベースをホストします。
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は、ユーザー認証などの操作の実行に使用されます。
アプリケーション層は、Java EEアプリケーションが配置される層です。Oracle Identity Manager、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リスナーはアプリケーション層にも配置されます。
データ層は、すべてのLDAPサービスが配置されるデプロイメント・レイヤーです。この層には、Oracle Internet Directory (OIDHOST)、Oracle Virtual Directory (OVDHOST)、Oracle Unified Directory、Oracle Database (IDMDBHOST)などの製品が含まれています。
データ層は、次の2種類の情報を格納します。
アイデンティティ情報: ユーザーおよびグループに関する情報はアイデンティティ・ストアに格納されます。
Oracle Platform Security Services (OPSS): セキュリティ・ポリシーおよび構成に関する情報は、ポリシー・ストアに格納されます。
ポリシー・データの格納
ポリシー情報は、データベース内に配置されている集中管理されたポリシー・ストアに格納されます。アイデンティティ情報はOracle Internet Directoryに格納することも、別のディレクトリに格納することもできます。
アイデンティティ・データの格納
Oracle Internet Directory以外のディレクトリにアイデンティティの詳細を格納する場合、Oracle Virtual Directoryを使用して、Oracle Identity Managementの各コンポーネントが解釈できる単一の統合ビューにすべてのアイデンティティ・データを提供できます。詳細は第7章を参照してください。
|
注意: Oracle Identity ManagerはOracle Virtual DirectoryサーバーまたはlibOVDを使用して、サード・パーティ・ディレクトリにアクセスします。 |
このドキュメントで説明する単一ノード・トポロジとは異なり、エンタープライズ統合トポロジは、高可用性、フェイルオーバーおよびファイアウォールなどの機能も考慮され、このドキュメントの範囲外です。
『Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド』を参照してください。エンタープライズ統合トポロジの概念と実装手順の説明が記載されています。
このドキュメントの統合シナリオは、Oracle Internet Directory LDAPサーバーで構成される単純なアイデンティティ・ストア・トポロジに焦点を当てていますが、サイトでMicrosoft Active Directoryなどのサード・パーティ・ディレクトリに一部のユーザー・データが格納されていたり、Oracle Internet Directoryに他のユーザー・データが格納されている場合があります。
このトポロジを考慮するために、Oracle Virtual Directoryを使用して、Oracle Identity Managementの各コンポーネントが解釈できる単一の統合ビューにすべてのアイデンティティ・データを提供できます。
構成の詳細は、第7章を参照してください。
表1-1は、Oracle Fusion Middleware環境のアーキテクチャおよびトポロジの説明に使用される主要な用語および頭字語を示しています。
表1-1 Oracle Fusion Middlewareの統合の用語
| 用語 | 定義 |
|---|---|
|
IdM構成ツール |
アイデンティティ管理コンポーネントのステータスを検証し、特定の統合タスクを実行するためのコマンド行ツール。 |
|
Oracle Accessプロトコル(OAP) |
認可中のWebゲートとAccess Managerサーバー間の通信のためのセキュアなチャネル。 |
|
Middlewareホームは、Oracle WebLogic Serverホーム、およびオプションで1つ以上のOracleホームから構成されています。 ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。 |
|
|
Oracle HTTP Server (OHS) |
Oracle WebLogic Serverのリスナーを提供するOracle Fusion MiddlewareのためのWebサーバー・コンポーネント。 |
|
WebLogic Serverホームには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。WebLogic Serverホーム・ディレクトリは、Middlewareホーム・ディレクトリの下の別のOracleホーム・ディレクトリと同等です。 |
|
|
Oracleホームには、特定の製品をホストするために必要なインストール済ファイルが含まれています。たとえば、Oracle Identity ManagementのOracleホームには、Oracle Identity Managementのバイナリ・ファイルおよびライブラリ・ファイルを含むディレクトリが含まれています。 Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。 |
|
|
Oracleインスタンスには、1つ以上のシステム・コンポーネント(Oracle Webキャッシュ、Oracle HTTP Server、Oracle Internet Directoryなど)が含まれています。Oracleインスタンス内のシステム・コンポーネントは、同じマシン上に配置する必要があります。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されています。 Oracleインスタンスは、Oracle WebLogic Serverドメインのピアです。両方には、Oracleホームの外部にある特定の構成が格納されます。 Oracleインスタンスのディレクトリ構造は、Oracleホームのディレクトリ構造とは異なります。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。 |
|
|
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コンポーネントは、システム・コンポーネントと同等ですが、アプリケーション・サーバー・コンテナによって管理されます。通常、一連のアプリケーションおよびリソースを参照し、通常ドメイン拡張子テンプレートと一対一の関係を持ちます。たとえば、SOAとWebCenter Spacesです。 |
|
|
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のアイデンティティおよびアクセス管理コンポーネントのスイート。詳細は第1.3項を参照してください。 |
|
管理サーバーは、WebLogicドメイン内のすべてのリソースを構成および管理するための中心ポイントです。 |
|
|
管理対象サーバーは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービスおよびそれらに関連するリソースをホストするための追加のWebLogic Serverインスタンスです。1つのドメイン内で複数の管理対象サーバーが稼働できます。ドメイン内の特定の管理対象サーバーは、特にOracle Fusion Middlewareコンポーネントをホストするために作成されます。 |
この項では、このドキュメントで統合について説明するIdMコンポーネントの簡単な概要と統合の利点について説明します。内容は次のとおりです。
Oracle Unified Directoryは、次世代の包括的なディレクトリ・サービスです。これは大規模なデプロイメントに対応し、要件の厳しい環境で高いパフォーマンスを提供するように設計されています。
Oracle Unified Directoryサーバーは、すべてJavaで記述されているLDAPv3準拠ディレクトリ・サーバーです。ディレクトリ・サーバーは完全なLDAPv3準拠、高いパフォーマンスと領域効率のいいデータ・ストレージ、容易な構成および管理を提供します。
このドキュメントのいくつかの手順では、アイデンティティ・ストアのリポジトリとしてOracle Unified Directoryを使用します。詳細は、第2.3項「アイデンティティ・ストアの構成」を参照してください。
Oracle Internet Directoryは、分散したユーザーおよびネットワーク・リソースに関する情報の高速検索と集中管理を可能にする汎用ディレクトリ・サービスです。これは、Lightweight Directory Access Protocol (LDAP)バージョン3と、Oracle Databaseの高いパフォーマンス、スケーラビリティ、堅牢性および可用性を組み合せたものです。
Oracle Internet Directoryは、アイデンティティ管理コンポーネントおよび他のアプリケーションによって利用されるユーザー・アイデンティティが格納されるアイデンティティ・ストアのリポジトリとして機能できます。
Oracle Internet Directoryとの統合の詳細は、次を参照してください。
Oracle Virtual Directoryは、1つ以上のエンタープライズ・データソースを単一のディレクトリに仮想化して抽象的に表示するLDAPバージョン3対応のサービスです。Oracle Virtual Directoryは、クライアント・アプリケーションからデータの場所、形式およびプロトコルを隠し、多数のディレクトリを1つのローカル・リポジトリであるかのように表示します。
Oracle Virtual Directoryとの統合の詳細は、次を参照してください。
Oracle Access Management Access Managerは、全面的なWeb周辺のセキュリティ機能を提供します。これにはWebシングル・サインオン、認証および認可、ポリシー管理、監査などが含まれます。Oracle Identity Managementスタックのすべての既存のアクセス・テクノロジは、Access Managerに集約されています。
Access Managerとの統合の詳細は、次を参照してください。
デフォルトでは、IDMDomainエージェントはOracle HTTP Serverのデプロイメントで有効化されます。IDMDomainエージェントからWebゲート・エージェントに移行する場合は、次の点に注意してください。
WebゲートでIDMDomainのpreferredHostを使用している場合、IDMDomain用の保護ポリシー設定をWebゲート用として再使用できます。
IDMDomainとWebゲートは共存できます。Oracle HTTP ServerのデプロイメントでIDMDomainエージェントによってWebゲート・エージェントが検出された場合、IDMDomainエージェントは休眠状態になります。
|
関連項目: 『Oracle Access Management管理者ガイド』のIDMドメイン・エージェントの集中ログアウトの構成に関する項。 |
Oracle Identity Managerは、エンタープライズITリソース内のユーザーのアクセス権限を自動的に管理する、強力かつ柔軟なエンタープライズ・アイデンティティ管理システムです。Oracle Identity Managerは、企業のすべてのリソースにわたってユーザー・アクセス権限を管理するために基礎から設計されており、最初のアクセス権限の作成からビジネス要件の変化に対する動的な対応に至るまでアイデンティティ管理ライフサイクル全体を管理します。
Oracle Identity Managerとの統合の詳細は、第3章「Access Manager、OAAMおよびOIMの統合」を参照してください。
Oracle Adaptive Access Managerは、エンタープライズ向けにWebアクセスのリアルタイム不正検出およびオンライン多要素認証セキュリティを提供するOracle Identity Managementのソリューションです。次の機能が提供されます。
不正や誤用に対処するための、アクセスの複数のチャネルをまたいだリアルタイムおよびバッチのリスク分析
デバイス・フィンガープリント、リアルタイムの動作プロファイリングおよびリスク分析などの一連の拡張機能
回答ロジックおよびOTP Anywhereによるナレッジベース認証(KBA)チャレンジ・インフラストラクチャなどのリスクベース認証メソッド
|
関連項目: 『Oracle Adaptive Access Managerの管理』のOracle Adaptive Access Managerの概要に関する項。 |
Oracle Adaptive Access Managerとの統合の詳細は、次を参照してください。
|
注意: Oracle Adaptive Access Managerの共存モードでのOAM 10gおよびAccess Manager 11gの両方との統合と、シングル・ログイン・ページ・モードなどのカスタマイズはこのドキュメントの範囲外です。詳細は、『Oracle Adaptive Access Manager開発者ガイド』を参照してください。 |
Oracle Mobile Security Suiteでは、企業アプリケーションおよびデータを隔離して保護するためにモバイル・デバイス上で安全なエンタープライズ・ワークスペースが作成されます。
Oracle Mobile Security SuiteとAccess Managerは常にまとめてインストールされ、デフォルトで統合されます。これによってユーザーはAccess Managerで保護された企業アプリケーションにMobile Workspaceアプリケーションからアクセスすることが可能になり、同時に一体的な管理コンソールも提供されます。Oracle Identity Managerとの統合によって、アイデンティティがOracle Identity Managerで管理されているモバイル・ユーザーが、Access Managerのシングル・サインオン機能で企業アプリケーションにアクセスできます。
Oracle Mobile Security Suiteとの統合の詳細は、第5章を参照してください。
クラウド、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サービスの使用方法の詳細は、第6章「Identity Federationとの統合」を参照してください。
表1-2は、このドキュメントで説明する統合手順へのリンクを示しています。
表1-2 このガイドの統合手順へのリンク
| 統合するコンポーネント | リンク |
|---|---|
|
インストール後のLDAPとOracle Identity Managerとの同期 |
|
|
Oracle Virtual DirectoryとOracle Identity Manager |
|
|
Oracle Virtual DirectoryとAccess Manager |
|
|
Access ManagerとOracle Identity Manager |
|
|
Access Manager、Oracle Identity ManagerおよびOracle Adaptive Access Manager |
|
|
Access ManagerとIdentity Federation |
|
|
マルチディレクトリ・アイデンティティ・ストア |
|
|
Access ManagerとOracle Adaptive Access Manager |
|
|
IdMコンポーネント用のエンドツーエンドSSL |
|
他のドキュメントの統合手順
表1-3は、他のIdMドキュメントに記載される主な統合手順を示しています。
表1-3 他のガイドの統合手順へのリンク
| 統合するコンポーネント | リンク |
|---|---|
|
Oracle Privileged Account Manager (OPAM)とOracle Identity Manager (OIM) |
『Oracle Privileged Account Managerの管理』のOracle Identity Managerとの統合に関する項。 |
|
OPAMとOAM |
『Oracle Privileged Account Managerの管理』のOracle Access Management Access Managerとの統合に関する項。 |
|
OIMとOracle Identity Analytics (OIA) |
『Oracle Identity Managerの管理』のIdentity Analyticsとの統合に関する項 |
この項では、Access Manager、Oracle Adaptive Access ManagerおよびOracle Identity Managerを統合するための一般的なシナリオ、リソース保護と収集およびパスワード管理の利点について説明します。
この項では、Trusted Authentication Protocolを使用して、Access ManagerおよびOAAMの拡張統合内の保護されたリソースにユーザーがアクセスを試みるときのプロセス・フローについて説明します(TAPを使用したOAAM拡張)。TAPを使用したOAAM拡張は、サポートされているOAAMとAccess Managerとの拡張統合です。この統合タイプでは、認証スキーム、仮想オーセンティケータ、不正ルール、ナレッジ・ベース認証、チャレンジ・プロセッサおよび共有ライブラリ・フレームワークと、その他の高度なセキュリティ・アクセス機能(OTP Anywhereやステップアップ認証など)を提供します。
ステップアップ認証では、特定の認証レベルのリソースに認証されたユーザーが、相対的に高い認証レベルのリソースにアクセスできます。ユーザーが現在のトークンのレベルを超える認証レベルで保護されたリソースにアクセスすると、OAAMではユーザーをどのくらいまで認証するかを判断するポリシーが実行されて、その保護されたリソースへのアクセスに必要な認証レベルを取得できます。
図1-3は、ステップアップ認証の次のシナリオを示しています。
ケース1: ユーザーはAccess Managerとステップアップ認証を実行するOracle Adaptive Access Managerによって認証される
ケース3: ユーザーはAccess Managerによって認証され、Oracle Adaptive Access Managerはステップアップ認証を実行しない
3つのケースすべてに関連する最初の手順は、次のとおりです。
ユーザーは、Oracle Adaptive Access Managerで構成されているTAPschemeを介してAccess Managerによって保護されているリソースにアクセスを試みます。
Oracle Access Management Webゲートにより、未認証のリクエストが捕捉され、暗号化されたTAPトークンとともにリクエストがOAAMサーバーに転送されます。
Access ManagerはTAPSchemeで定義されたチャレンジURLに基づいてリクエストをOAAMに転送します。
OAAMサーバーによって、TAPトークンからユーザーの現在の認証ステータスがチェックされます。TAPトークンには、現在の認証レベルが含まれています。現在の認証レベルの値に応じて、Oracle Adaptive Access Managerは、そのユーザーを認証するかどうかを決定できます。それに応じて、ユーザーはこの項で説明したフローの1つに導かれます。
認証フローの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』の認証フローに関する項を参照してください。
このシナリオでは、ユーザーは、低い認証レベルの別のリソースに最近アクセスしたときにすでに認証されています。ユーザーが、TAPschemeによって保護されているリソースにアクセスしようとしたときに、Oracle Adaptive Access Managerによってユーザー名とパスワードのページが表示されることはありません。ユーザーはすでに認証されているためです。ただし、次のフローは、ユーザーがOracle Adaptive Access Managerで登録されているかどうかに基づいて、Oracle Adaptive Access Managerで実行されます。
ユーザーがOracle Adaptive Access Managerに登録済
ユーザーがOracle Adaptive Access Managerに登録済である場合、プロセス・フローは次のようになります。
Oracle Adaptive Access Managerは、PC、ノートブック、携帯電話、スマートフォンまたはユーザーが使用するその他のWeb対応マシンのフィンガープリントを取得します。
Oracle Adaptive Access Managerにより認証後ルールが実行され、リスク・スコアが決定され、ポリシーに指定されている任意のアクションまたはアラートが実行されます。
リスク・スコアが十分に高い場合は、Oracle Adaptive Access Managerにより、ユーザーに対して2番目のチャレンジ(KBAまたはOTP)が表示されます。チャレンジ・フローで、ユーザーは登録済のチャレンジ質問またはワンタイム・パスワードによってチャレンジされます。
チャレンジ・フローが成功し、そのユーザーの適切なプロファイルが登録されている場合、Oracle Adaptive Access Managerによってそのユーザー名を含むTAPトークンが作成され、それがAccess Managerに送り返されます。Access Managerは戻されたトークンをアサートします。トークンをアサートした後、Access ManagerはそのCookieを作成し、通常のシングル・サインオン・フロー(ユーザーを保護されたリソースにリダイレクトする)を続行します。
ユーザーがOracle Adaptive Access Managerに未登録
ユーザーがOracle Adaptive Access Managerに登録されていない場合、プロセス・フローは次のようになります。
ユーザーが登録されていない場合、仮想デバイス、パーソナル・イメージ、フレーズおよびチャレンジ質問と、ワンタイム・パスワード(OTPが構成されている場合)を登録するように求められる場合があります。登録が必須であるかオプションであるかが指定されたセキュリティ要件に基づいて、登録が要求されます。
Oracle Adaptive Access Managerは、PC、ノートブック、携帯電話、スマートフォンまたはユーザーが使用するその他のWeb対応マシンのフィンガープリントを取得します。
Oracle Adaptive Access Managerにより認証後ルールが実行され、リスク・スコアが決定され、ポリシーに指定されている任意のアクションまたはアラートが実行されます。
リスク・スコアが十分に高い場合は、Oracle Adaptive Access Managerによってユーザーがブロックされます。これは、登録済プロファイル(KBAまたはOTPなし)のないユーザーにチャレンジできないためです。
リスクがない場合、そのユーザーはプロファイル登録に進み、その後、Oracle Adaptive Access Managerによってそのユーザー名を含むTAPトークンが作成され、それがAccess Managerに送り返されます。Access Managerは戻されたトークンをアサートします。トークンをアサートした後、Access ManagerはそのCookieを作成し、通常のシングル・サインオン・フロー(ユーザーを保護されたリソースにリダイレクトする)を続行します。
ユーザーが認証されていない場合、プロセス・フローは次のようになります。
OAAMサーバーによって、ユーザーにOAAMユーザー名ページが提示されます。
ユーザーは、OAAMユーザー名ページで自分のユーザー名を送信します。
Oracle Adaptive Access Managerは、PC、ノートブック、携帯電話、スマートフォンまたはユーザーが使用するその他のWeb対応マシンのフィンガープリントを取得します。
Oracle Adaptive Access Managerにより、ユーザーがOAAMパスワード・ページに進むことを許可するかどうかを決定する認証前ルールが実行されます。
ユーザーが次に進むことを許可された場合は、仮想認証デバイスのルールが実行され、どの仮想オーセンティケータをOAAMパスワード・ページに表示するかが決定されます。
ユーザーがOracle Adaptive Access Managerに登録されている場合は、OAAMサーバーにより、パーソナライズされたTextPadまたはKeyPadとともにOAAMパスワード・ページが表示されます。ユーザーが登録されていない場合は、Oracle Adaptive Access Managerにより、汎用TextPadとともにOAAMパスワード・ページが表示されます。
ユーザーはOAAMパスワード・ページでパスワードを送信し、収集された資格証明は、Oracle Access Management OAP APIを使用してアイデンティティ・ストアに対して検証されます。Access Manager側での検証の後、Oracle Adaptive Access Managerにより認証後ルールが実行されます。
ルール/リスク・スコアに基づいて、Oracle Adaptive Access Managerではユーザーの続行の許可、ユーザーへのチャレンジ、またはユーザーのブロックが行われます。
ユーザーが次に進むことを許可された場合は、Oracle Adaptive Access Managerがセキュリティ要件に応じて登録チェックポイントを評価します。ユーザーが登録されていない場合、仮想デバイス、パーソナル・イメージ、フレーズ、チャレンジ質問、およびOTP (構成されている場合)を登録するように求められる場合があります。
リスクが十分に高いためにユーザーがチャレンジされる場合、Oracle Adaptive Access Managerはチャレンジ・チェックポイントを評価して、ユーザーをブロックするか、別のチャレンジ(KBAまたはOTP)を表示するかを判断します。チャレンジ選択が構成済で、ユーザーが複数のOTPタイプを登録している場合、ユーザーは選択できます。
ユーザーがブロックされた場合は、続行できません。
認証が成功し、ユーザーに登録済の適切なプロファイルがある場合は、Oracle Adaptive Access Managerによりこのユーザー名のTAPトークンが構成され、Access Managerに戻されます。Access Managerは戻されたトークンをアサートします。トークンをアサートした後、Access ManagerはそのCookieを作成し、通常のシングル・サインオン・フロー(ユーザーを保護されたリソースにリダイレクトする)を続行します。
ユーザーが、TAPschemeによって保護されているリソースへのアクセスに必要なレベルより高いレベルですでに認証されている場合、フローがOracle Adaptive Access Managerによって中断されることなく、ユーザーは保護されているリソースに直接アクセスできます。
この項では、Access ManagerとOAAMの基本統合(OAAM基本)内の保護されたリソースにユーザーがアクセスを試みるときのプロセス・フローについて説明します。このデプロイメントは、ログイン・セキュリティおよびナレッジ・ベース認証(KBA)を提供します。OAAM基本の詳細は、第C.3項「OAAMとAccess Managerとの基本統合」を参照してください。
プロセス・フローは次のようになります。
ユーザーは、Access Managerによって保護されたリソースにアクセスを試みます。
Oracle Access Management Webゲートにより、リクエストが捕捉され、リクエストがOAAMサーバーに転送されます。
Access Managerにより、OAAM APIがコールされ、ユーザーに進むことを許可するかどうかを決定する認証前ルールが実行されます。Access Managerによって、許可、ブロック、拒否などのルール結果に基づいた適切なページが表示されます。
ユーザーに進むことを許可する場合、Access Managerによってパスワード・ページが表示されます。
ユーザーはパスワードを送信し、Access Managerから収集された資格証明がアイデンティティ・ストアに対して検証されます。
Access ManagerによってOAAM APIがコールされ、認証後ルールが実行されます。
Access Managerにより、結果(ユーザー登録、質問登録、チャレンジ、許可またはブロック)に基づいて、適切なページのセットが表示されます。
たとえば、結果がユーザー登録である場合、ユーザー登録プロセスの一部として(最初のログインの場合)、ユーザーは3つのチャレンジ質問を選択して回答するように求められます。
たとえば、結果がチャレンジである場合、Access Managerにより、セキュリティ質問が表示されたチャレンジ質問ページが表示されます。
これらのデプロイ・モードによってサポートされている一般的な管理シナリオには、次のものが含まれます。
図1-4は、Access ManagerとOracle Identity Managerの統合時にパスワード管理がどのように行われるかを示しています。
コンポーネント間の相互作用のフローは次のとおりです。
ユーザーは、Access Managerによって保護されたリソースにアクセスを試みます。
Oracle Access Management Webゲートにより、(未認証の)リクエストが捕捉されます。
WebゲートによりユーザーがAccess Managerログイン・サービスにリダイレクトされ、そこで検証チェックが実行されます。
Access Managerによりパスワード期限切れなどのパスワード管理トリガー条件が検出されると、ユーザーがOracle Identity Managerにリダイレクトされます。
Oracle Identity Managerにより、ユーザーとの相互作用を通じてユーザーのアイデンティティが確立され、パスワードのリセットなどの適切なアクションが実行されます。
Access Managerにより、自動ログインを通じてユーザーのログインが行われ、ユーザーがAccess Managerによって保護されたリソース(ユーザーが手順1でアクセスしようとしていたもの)にリダイレクトされます。
このシナリオでは、アカウントを持たないユーザーがAccess Managerによって保護されたリソースにアクセスしようとします。Oracle Access Management 11g Webゲートによってリクエストが捕捉され、ユーザーが認証されていないことが検出され、そのユーザーがOracle Access Management Credential Collector (またはWebゲートを認証する10g)にリダイレクトされ、それによって「新規アカウントの登録」リンクを含むAccess Managerログイン・ページが表示されます。
このリンクを選択すると、ユーザーは安全にOracle Identity Managerの自己登録URLにリダイレクトされます。Oracle Identity Managerにより、ユーザーとの相互作用を通じてそのアカウントがプロビジョニングされます。
ようこそページは、自己登録/アカウント作成を開始できる、保護されていないページです。このページには、2つのリンクが紹介テキストまたはブランド情報とともに表示されます。これらのリンクは次のとおりです。
新規アカウントの登録 - これは、対応するアプリケーションの登録ウィザードへの保護されていないURLです。
ログイン - これは、ログイン成功後にユーザーが転送されるランディング・ページとして機能する、保護されたURLです。
|
注意: 自己登録要件があるシングル・サインオン・システムによって保護されたアプリケーションは、自己登録ページをサポートすることが予期されます。オプションは次のとおりです。
|
|
関連項目: Oracle Platform Security Servicesの詳細は、『Oracle Fusion Middlewareセキュリティ概要』を参照してください。 |
アカウント作成フローは次のとおりです。
ユーザーは、(ブラウザを使用して)「新規アカウントの登録」リンクを含むアプリケーションのようこそページにアクセスします。
ユーザーは、「新規アカウントの登録」リンクをクリックし、アプリケーションによって提供された自己登録ページに転送されます。
ユーザーは、アプリケーションと相互作用して自己登録します。
完了すると、アプリケーションによりユーザーの自動ログインが実行されます。
保護されたアプリケーションにより、ユーザーを作成するためにOracle Identity ManagerにSPMLリクエストが送信されることが予期されます。この後、アプリケーションにより次のいずれかの操作が選択されます。
アプリケーションにより、ユーザーを自動ログインしないことを選択できます。アプリケーションにより、ユーザーを保護されたランディング・ページURLにリダイレクトします。その後、Access Managerによりログイン・ページが表示され、ユーザーがログイン・フローに進みます。
リクエストに関連付けられた承認がない場合は、アプリケーションにより、Oracle Platform Security Services (OPSS) APIを利用して特定のランディング・ページURLに自動ログインし、そのURL(およびSSO Cookie)を含んだリダイレクト・リクエストで応答します。これにより、ログイン・ページを表示せずにユーザーが直接ランディング・ページに転送されます。
承認が必要な場合、自動ログインは実行できません。アプリケーションにより、SPMLリクエストの時点でどのプロファイルを使用するかが決定されます。アプリケーションにより、リクエストが送信されたことを示す適切なページで応答する必要があります。
パスワードの変更フローにより、ユーザーは各自のパスワードを変更できます。
Access ManagerおよびOracle Identity Managerによるパスワードの変更フロー
この状況では、ユーザーはAccess Managerに正常にログインした後、すぐにパスワードを変更する必要があります。ユーザーは、パスワードを変更してチャレンジを設定するまで、保護されたリソースへのアクセスを許可されません。
ログインが成功すると、Access Managerによりトリガー条件が有効であるかどうかが検出され、ユーザーがOracle Identity Managerの「パスワードの変更」URLにリダイレクトされます。Oracle Identity Managerでは、ユーザー・パスワードの変更またはチャレンジの設定を容易にし、トリガー条件をリセットします。
完了すると、Oracle Identity Managerによりユーザーが保護されたリソースにリダイレクトされます。
この状況は、次の場合にトリガーされます。
Change Password upon Loginフラグがオンになっています。これは次の場合に発生します。
新しいユーザーが作成された場合
管理者がユーザーのパスワードをリセットした場合
パスワードの有効期限が切れました。
このフローでは、ユーザーが初めてAccess Managerによって保護されたアプリケーションにログインし、次に進む前にパスワードの変更を求められる状況について説明します。
パスワードの変更フローは次のとおりです。
ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。
Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。
ユーザーは資格証明を送信し、これがAccess Managerにより検証されます。
続いてAccess Managerにより、初回ログインのトリガー条件のいずれかが有効であるかどうかが判別されます。有効である場合は、Access Managerにより、ユーザーがOracle Identity Managerの「パスワードの変更」URLにリダイレクトされます。
Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、Oracle Identity Managerが匿名認証ポリシーによって保護されていることが判別され、ユーザー・リクエストの処理が許可されます。
Oracle Identity Managerにより、ユーザーとの相互作用を通じてユーザーがパスワードを変更できるようになります。完了すると、Oracle Identity Managerにより「初回ログイン」フローをトリガーした属性が更新されます。続いてOracle Identity Managerにより、ユーザーの自動ログインが実行されます。
Oracle Identity Managerにより、Access Managerに初回ログインの成功が通知されます。
Oracle Identity Managerにより、手順1でユーザーがアクセスしようとしていたアプリケーションURLにユーザーがリダイレクトされます。
パスワードを忘れた場合のフローでは、ユーザーはすべてのチャレンジ質問に正しく回答した後で各自のパスワードをリセットできます。
Access ManagerとOracle Identity Managerの統合におけるパスワードを忘れた場合のフロー
このシナリオでは、ユーザーはAccess Managerログイン・ページを表示して「パスワードを忘れた場合」リンクをクリックします。Access Managerにより、ユーザーはOracle Identity Managerの「パスワードを忘れた場合」URLにリダイレクトされ、パスワードの変更に成功したときにOracle Identity Managerによるリダイレクト先となる宛先URLが問合せパラメータ(backURL)として渡されます。
Oracle Identity Managerにより、ユーザーに対してチャレンジ質問が尋ねられます。正しい回答を入力すると、ユーザーは新しいパスワードを指定できます。
完了すると、Oracle Identity Managerによりユーザーが保護されたリソースにリダイレクトされます。
パスワードを忘れた場合のフローは次のとおりです。
ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。
Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。
ユーザーはAccess Managerログイン・ページで「パスワードを忘れた場合」リンクをクリックし、これによりユーザーはOracle Identity Managerの「パスワードを忘れた場合」URLに送信されます。
Oracle Identity Managerにより、ユーザーとの相互作用を通じてユーザーがパスワードをリセットできるようになります。完了すると、Oracle Identity Managerによりユーザーの自動ログインが実行されます。
Oracle Identity Managerにより、手順1でアクセスしようとしていたアプリケーションURLにユーザーがリダイレクトされます。
Access Manager、Oracle Identity ManagerおよびOracle Adaptive Access Managerの統合におけるパスワードを忘れた場合のフロー
Oracle Adaptive Access ManagerとOracle Identity Managerの統合では、パスワードを忘れた場合の機能はOAAMパスワード・ページ上のリンクとして使用可能になります。このフローが開始されるのは、ユーザーがOAAMパスワード・ページを表示して「パスワードをお忘れですか」リンクをクリックしたときです。
プロセス・フローは次のようになります。
ブラウザを使用して、ユーザーはAccess Managerで保護されているアプリケーションURLに認証スキーム経由でアクセスしようとします。
Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ログインのためにリクエストがOAAMサーバーに転送されます。
OAAMサーバーによって、ユーザーにOAAMユーザー名ページが提示され、ここでユーザーは自分のユーザー名を送信します。
Oracle Adaptive Access Managerにより、ユーザー・デバイス(デスクトップ・コンピュータ、ラップトップ・コンピュータ、PDA、携帯電話、キオスクまたは他のWeb対応デバイス)のフィンガープリントが取得され、認証前ルールが実行されてユーザーがブラックリストの国、デバイス、IP、ISPまたはユーザー・グループのメンバーかどうか、あるいはWEBZIPを使用中かどうかがチェックされます。ブラック・リストに記載されたグループに属していたりWEBZIPを使用している場合は、ブロックされ、続行できません。
ユーザーが次に進むことを許可された場合は、仮想認証デバイスのルールが実行され、どの仮想認証デバイスをパスワード・ページに表示するかが決定されます。
OAAMサーバーは仮想認証デバイスのあるOAAMパスワード・ページを表示します。
ユーザーは、OAAMパスワード・ページで「パスワードをお忘れですか」リンクをクリックします。
|
注意: 「パスワードをお忘れですか」リンクは、未登録のユーザーの初回ログインには使用できません。初回ログオンでパスワードをリセットする必要があります。 |
OAAMサーバーは、「パスワードを忘れた場合」チェックポイントを実行します。
Oracle Adaptive Access Managerによって、ユーザーにチャレンジ・ページが提示されます。
ユーザーが未登録の場合、ユーザーはブロックされ、保護されたリソースにアクセスできません。
ユーザーが登録済の場合、デプロイメントに応じてOTPまたはKBAによってチャレンジされます。チャレンジ選択が構成済で、ユーザーが複数のOTPチャレンジ・タイプを登録している場合、OAAMでチャレンジされるOTPチャレンジ・タイプの選択肢が与えられます。
チャレンジが成功すると、Oracle Adaptive Access Managerにより、パスワード・ポリシー・テキストのためにOracle Identity Managerへのコールが行われます。
ユーザーは、パスワード・ポリシー・テキストが表示される「パスワードのリセット」ページにリダイレクトされます。
ユーザーは新しいパスワードを入力し、もう一度入力して新しいパスワードを確認します。
Oracle Adaptive Access Managerにより、ユーザー名およびパスワードが収集され、OAP APIコールがAccess Managerに送信されます。
Access ManagerはAccess Managerで構成されたアイデンティティ・ストアへのLDAPコールを行い、資格証明を検証します。
Oracle Adaptive Access Managerにより、Oracle Identity Managerが呼び出され、リポジトリが新しいパスワードで更新されます。
認証後、Oracle Adaptive Access Managerが認証後チェックポイント・ポリシーを評価します。ポリシーの結果に基づいて、Oracle Adaptive Access Managerではユーザーへのチャレンジ、ユーザーの登録のチェック、またはユーザーのブロックが行われます。
認証後の結果が許可の場合、Oracle Adaptive Access Managerが登録チェックポイントを評価して、登録を保留しているユーザー情報はどれか判断されます。登録のタイプに基づいて、登録フローに入ります。
リスクが十分に高い場合は、認証後の結果がチャレンジになることがあります。Oracle Adaptive Access Managerは、チャレンジ・チェックポイントを評価して、ユーザーをブロックするか、またはユーザーをチャレンジ・フローに送り、いずれかの登録済チャレンジ・メカニズム(構成に応じてKBAまたはOTP)でチャレンジするかを判別します。
認証後の結果がブロックの場合は、ユーザーはブロックされ、保護されたリソースにアクセスできません。
必要なフローでOracle Adaptive Access Managerがユーザーとやり取りし、ユーザーが成功した場合はAccess ManagerがOAM Cookieを設定し、ユーザーはログインしてシングル・サインオン・セッションが作成されます。
Access Managerでは、ログイン試行を追跡し、その回数が確立された制限を超えるとアカウントをロックします。
アカウントがロックされると、Access Managerによりヘルプ・デスクの連絡先情報および「パスワードを忘れた場合」リンクや、類似情報が表示されます。
エンド・ユーザーから連絡を受けると、ヘルプ・デスクはOracle Identity Manager管理コンソールを使用してアカウントをロック解除します。その後Oracle Identity Managerにより、Access Managerに変更が通知されます。エンド・ユーザーがヘルプ・デスクへの連絡ではなく「パスワードを忘れた場合」リンクの使用を決めた場合、Oracle Identity Managerはユーザーと交信します。完了時に、ユーザーはパスワードをリセットできます。
ユーザー・ログイン試行の失敗回数がパスワード・ポリシーで指定された値を超えると、ユーザー・アカウントがロックされます。ユーザー・アカウントがロックされた後のログイン試行に対しては、アカウントのロック解除プロセスに関する情報を提供するページを表示しますが、これは各自の組織で従うプロセス(ヘルプ・デスク情報および「パスワードを忘れた場合」リンクや、類似情報)を反映したものにカスタマイズされている必要があります。
アカウントのロックとロック解除のフローは次のとおりです。
ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスを試みます。
Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。
ユーザーは資格証明を送信し、これがAccess Managerによる検証に失敗します。Access Managerによりログイン・ページがレンダリングされ、ユーザーは資格証明を再送信するように求められます。
ユーザーのログイン試行の失敗回数がポリシーで指定された制限を超えます。Access Managerによりユーザー・アカウントがロックされ、ユーザーがAccess ManagerのアカウントのロックアウトURLにリダイレクトされます。ページが開いてヘルプ・デスクの連絡先情報および「パスワードを忘れた場合」リンクが表示されます。
ユーザーがヘルプ・デスクに電話で連絡し、管理者にアカウントのロック解除を依頼すると、次のようになります。
Oracle Identity Managerにより、Access Managerにアカウント・ロック解除イベントが通知されます。
ユーザーはアプリケーションURLにアクセスしようとし、このイベントにより通常のOracle Access Managementシングル・サインオン・フローがトリガーされます。
ユーザーが「パスワードを忘れた場合」リンクをクリックすると、ユーザーがOracle Identity Managerの「パスワードを忘れた場合」URLに送信され、次のようになります。
Oracle Identity Managerにより、ユーザーとの相互作用を通じてユーザーがパスワードをリセットできるようになります。完了すると、Oracle Identity Managerによりユーザーの自動ログインが実行されます。
Oracle Identity ManagerによりユーザーがアプリケーションURLにリダイレクトされます。
|
注意: ユーザー・ステータスがOracle Identity Managerでロックされた場合のみ、ユーザーはOracle Identity Managerの「パスワードを忘れた場合」フローを通じてアカウントを自分でロック解除できます。LDAPユーザー作成および更新のリコンシリエーションのスケジュール済ジョブが実行されている場合のみ、ユーザーのロック済ステータスがLDAPプロバイダからOracle Identity Managerに同期されます。 |
チャレンジの設定により、ユーザーはチャレンジ質問および回答を登録できます。
Access ManagerとOracle Identity Managerの統合におけるチャレンジの設定フロー
Access Managerによる検出とリダイレクトは次のパスワード・トリガー条件で行われます。
必要な数のチャレンジを増やすためにパスワード・ポリシーが更新されました。
チャレンジを要求するためにパスワード・ポリシーが更新されました。
このようなリダイレクトが発生した場合、Oracle Identity Managerによりチャレンジ質問が設定されているかどうかがチェックされます。設定されていない場合、ユーザーはパスワードをリセットするとともにチャレンジ質問を設定するように求められます。
フローは次のとおりです。
|
注意: このフローは、初回ログインが必要ではないことを前提としています。 |
ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。
Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、ユーザーがAccess Managerログイン・ページにリダイレクトされます。
ユーザーは資格証明を送信し、これがAccess Managerにより検証されます。パスワード・トリガー条件が検出された場合は、Access Managerにより、ユーザーがOracle Identity Managerのパスワードの変更URLにリダイレクトされます。
Oracle Access Management Webゲート(SSOエージェント)により、リクエストが捕捉され、Oracle Identity Managerが匿名認証ポリシーによって保護されていることが判別され、ユーザー・リクエストの処理が許可されます。
Oracle Identity Managerにより、ユーザーとの相互作用を通じてチャレンジが設定されます。完了すると、Oracle Identity Managerによりチャレンジの設定フローをトリガーした属性が更新されます。
Oracle Identity Managerにより、手順1でユーザーがアクセスしようとしていたアプリケーションURLにユーザーがリダイレクトされます。
Access Manager、Oracle Identity ManagerおよびOracle Adaptive Access Managerの統合におけるチャレンジの設定フロー
このシナリオでは、ユーザーは正常に認証されてもチャレンジ質問を登録する必要があります。ユーザーは、チャレンジ質問を登録するまで、保護されたリソースへのアクセスを許可されません。
|
注意: Oracle Adaptive Access Managerを既存のOracle Identity Managerデプロイに追加する場合は、Oracle Identity Managerで登録されているすべての既存の質問および回答を放棄する必要があります。かわりに、ユーザーは次のログイン時にOracle Adaptive Access Managerでチャレンジ質問を再度登録するように求められます。 |
ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。
Oracle Access Management Webゲートにより、(未認証の)リクエストが捕捉されます。
Oracle Access Management Webゲートにより、ユーザーがOAAMサーバーにリダイレクトされ、リダイレクトURLが渡されます。
Oracle Adaptive Access Managerによって、ユーザーにOAAMユーザー名ページが提示されます。
ユーザーは、OAAMユーザー名ページで自分のユーザー名を送信します。
Oracle Adaptive Access Managerにより、ユーザー・デバイス(デスクトップ・コンピュータ、ラップトップ・コンピュータ、PDA、携帯電話、キオスクまたは他のWeb対応デバイス)のフィンガープリントが取得され、ユーザーがOAAMパスワード・ページに進むことを許可するかどうかを決定する認証前ルールが実行されます。
ユーザーが次に進むことを許可された場合は、OAAMサーバーにより、仮想認証デバイス・ルールで指定された強力なオーセンティケータとともにOAAMパスワード・ページが表示されます。
ユーザーは、OAAMパスワード・ページで自分のパスワードを送信します。
認証中にOracle Adaptive Access Managerにより、Access Managerをコールして資格証明が検証されます。
認証後に、Oracle Adaptive Access Managerによりユーザーがチャレンジ質問を登録したかどうかがチェックされます。
ユーザーが質問を登録していない場合は、Oracle Adaptive Access Managerにより、ユーザーとの相互作用を通じてチャレンジが設定されます(チャレンジ質問の選択と回答の登録またはOTPプロファイルの設定、あるいはその両方)。
登録が成功すると、Oracle Adaptive Access Managerにより、ユーザーがAccess Managerによって保護されたリソースにリダイレクトされます。
チャレンジのリセットにより、ユーザーは各自のチャレンジの登録をリセットできます。
フローは次のとおりです。
ユーザーはブラウザを使用して、Access Managerによって保護されたアプリケーションのURLにアクセスしようとします。
Oracle Access Management Webゲートにより、(未認証の)リクエストが捕捉されます。
Oracle Access Management Webゲートにより、ユーザーがOAAMサーバーにリダイレクトされ、リダイレクトURLが渡されます。
OAAMサーバーによって、ユーザーにOAAMユーザー名ページが提示されます。
ユーザーは、OAAMユーザー名ページで自分のユーザー名を送信します。
Oracle Adaptive Access Managerにより、ユーザー・デバイス(デスクトップ・コンピュータ、ラップトップ・コンピュータ、PDA、携帯電話、キオスクまたは他のWeb対応デバイス)のフィンガープリントが取得され、ユーザーがOAAMパスワード・ページに進むことを許可するかどうかを決定する認証前ルールが実行されます。
ユーザーが次に進むことを許可された場合は、OAAMサーバーにより、仮想認証デバイス・ルールで指定された強力なオーセンティケータとともにOAAMパスワード・ページが表示されます。
ユーザーは、OAAMパスワード・ページで自分のパスワードを送信します。
認証中にOracle Adaptive Access Managerにより、Access Managerをコールして資格証明が検証されます。
認証が成功し、ユーザーに登録済の質問があるもののユーザーがチャレンジ質問のリセットを希望する場合、ユーザーは「チャレンジのリセット」リンクをクリックします。
|
注意: インテグレータはOAAMのユーザー・プリファレンスページ(または、場合によっては直接、OAAMの質問リセットページ)にユーザーを導く、保護されたアプリケーションへのリンクを追加する必要に迫られます。リンクを追加すると、ユーザーが自分のOAAM登録を管理できます。 |
ユーザーはOracle Adaptive Access Managerのユーザー・プリファレンス/質問登録ページにリダイレクトされ、ここでチャレンジ質問をリセットできます。
モバイル・セキュリティ・アカウントの管理フローによって、ユーザーは自分のモバイル・セキュリティ・アカウントおよびアプリケーションを管理できます。Oracle Mobile Security SuiteとOracle Mobile Security Suite統合コンポーネント間のフローは次のようになります。
ユーザーはOracle Mobile Security Suiteでモバイル・デバイスを登録します。
Oracle Mobile Security Suiteはユーザーのロールに基づいて、アプリケーションをユーザーにプロビジョニングします。
ユーザーは次の作業のためにOracle Identity Managerセルフ・サービス・コンソールにログインします。
デバイスの表示
操作の実行(デバイスまたはワークスペース用のパスコードのロック、ワイプまたはリセットなど)
Oracle Identity Managerコンソールに埋め込まれたOracle Mobile Security SuiteタスクフローがOracle Mobile Security Suiteを起動してデバイス上の情報を取得し、そこで操作を実行します。
ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システムの互換性、要件および動作保証情報のドキュメントを参照してください。
互換性に関するドキュメントでは、Oracle Fusion Middleware 11gコンポーネントをインストール、パッチ適用またはアップグレードする際に生じる可能性がある、互換性および相互運用性に関する考慮事項が説明されています。詳細は、『Oracle Identity and Access Management相互運用および互換性ガイド』を参照してください。
システム要件のマニュアルには、ハードウェアおよびソフトウェア要件、最小ディスク領域およびメモリー要件、必要なシステム・ライブラリ、パッケージ、パッチなどの情報が記載されています。
動作要件のドキュメントには、サポートされているインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDK、ディレクトリ・サーバーおよびサードパーティ製品が記載されています。
最新の要件および動作保証情報のドキュメントについては、『Oracle Identity and Access Management相互運用および互換性ガイド』の表のOracle Fusion Middlewareの動作保証マトリックスについての説明を参照してください。
Oracle Fusion Middlewareの問題の解決にMy Oracle Support (以前のMetaLink)を使用できます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。
ナレッジ・ベース記事
コミュニティ・フォーラムとディスカッション
パッチとアップグレード
動作保証情報
|
注意: My Oracle Supportを使用してサービス・リクエストを記録することもできます。 |
My Oracle Supportにはhttps://support.oracle.comからアクセスできます。
