Oracle® Fusion Middleware Oracle Identity Management Suite統合ガイド 11g リリース2 (11.1.2.1.0) B71104-03 |
|
![]() 前 |
![]() 次 |
この章では、Oracle Identity Managementスイートの統合の概念について説明します。
内容は次のとおりです。
この章のトピックに進む前に、Oracle Identity Managementの基礎知識について、次のドキュメントを参照してください。
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』
Oracle Fusion Middleware管理者ガイド
このドキュメントの手順を使用してOracle Identity Managementのコンポーネントを統合する前に、それらのコンポーネントをインストールおよびデプロイする必要があります。
Oracle Identity Managementのコンポーネントのインストールの詳細は、次のものを参照してください。
『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』
Oracle Fusion Middleware Oracle Identity and Access Managementクイック・インストレーション・ガイド
インストールのロードマップ
『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の「概要」の章には、インストールのロードマップ、前提条件、インストールおよび構成のワークフローなどIdMのデプロイメント手順の基礎知識が記載されています。
デプロイメント・トポロジ
アイデンティティ管理のトポロジおよびそれらのコンポーネントが動作することになる環境についても理解する必要があります。
このドキュメントでサポートされているトポロジの範囲の詳細は、第1.2項を参照してください。
Oracle Identity Managementは、個別または集合で使用できる多数のアプリケーションから構成されます。Oracle Identity Managementで使用できる2つの基本的なタイプのトポロジは、次のとおりです。
基本統合トポロジ
このトポロジでは、各コンポーネントが最大1つのノードで実行されている環境におけるスイート・コンポーネント間の統合がサポートされます。
エンタープライズ統合トポロジ
このトポロジは、エンタープライズ環境におけるスイート・コンポーネント間の統合を構成するためのものです。各コンポーネントは、1つ以上のノードで実行されることがあります。
このドキュメントで説明するトポロジ
このドキュメントでは、単一ノード統合トポロジについてのみ説明します。各コンポーネントが1つのノードで実行される環境にOracle Identity Managementをデプロイする場合は、このドキュメントで説明する手順を使用してください。この手順は、統合ツールおよび手法を理解するため、特定のアイデンティティ管理コンポーネントを統合することによる効果と利点について理解するためにも使用できます。
この項では、このドキュメントの基盤となるコンポーネント・トポロジについて説明します。各トポロジを構成する層についても説明します。
シングル・ドメイン・アーキテクチャでは、Oracle Access Management Access ManagerサーバーとOracle Identity Managerサーバーは同じOracle WebLogic Server上に構成されます。
図1-1は、基本的なシングル・ドメイン統合トポロジを示しています。
このトポロジでは、すべてのIdMコンポーネントが同じWebLogicドメイン内に構成されてるため、それらは1つのWebLogic管理サーバーによって管理されます。
注意: この図は、いくつかの代理ポートを示しています。完全なリストは、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートに関する項を参照してください。 |
図1-2は、前の統合トポロジのバリエーションを示しています。ここでは、Access ManagerサーバーとOracle Identity Managerサーバーが別々のWebLogicドメインに構成されています。
このトポロジでは、Access Managerサーバー(AMHOST)とOracle Identity Managerサーバー(OIMHOST)は、別々のWebLogicドメインに構成されているため、それぞれがそれ自体の管理サーバーによって管理されます。
注意: この図は、いくつかの代理ポートを示しています。完全なリストは、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールとポートに関する項を参照してください。 |
このアーキテクチャは、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アプリケーションが配置される層です。この層にデプロイされる主要なJava EEコンポーネントとしては、Oracle Identity Manager、Oracle Access Management Identity Federation、Oracle Enterprise Manager Fusion Middleware Controlなどの製品があります。
アプリケーション層にあるアイデンティティ管理アプリケーションは、次に示すようにディレクトリ層と対話的に処理を行います。
エンタープライズ・アイデンティティ情報についてはディレクトリ層が活用されます。
アプリケーション・メタデータについてはディレクトリ層(およびデータ層のデータベースの場合もある)が活用されます。
Fusion Middleware Controlコンソールは、アプリケーション層およびディレクトリ層のコンポーネントに対する管理機能を提供します。
Oracle WebLogic Serverには、Webサーバーのサポートが組み込まれています。有効にされていると、HTTPリスナーはアプリケーション層にも配置されます。
データ層は、すべてのLDAPサービスが配置されるデプロイメント・レイヤーです。この層には、Oracle Internet Directory (OIDHOST
)、Oracle Virtual Directory (OVDHOST
)、Oracle Database (IDMDBHOST
)などの製品が含まれています。
データ層は、次の2種類の情報を格納します。
アイデンティティ情報: ユーザーおよびグループに関する情報はアイデンティティ・ストアに格納されます。
Oracle Platform Security Services (OPSS): セキュリティ・ポリシーおよび構成に関する情報は、ポリシー・ストアに格納されます。
ポリシー・データの格納
ポリシー情報は、データベース内に配置されている集中管理されたポリシー・ストアに格納されます。アイデンティティ情報はOracle Internet Directoryに格納することも、別のディレクトリに格納することもできます。
アイデンティティ・データの格納
アイデンティティの詳細をOracle Internet Directory以外のディレクトリに格納する場合は、Oracle Directory Integration Platformを使用して、他のディレクトリのユーザーとグループをOracle Internet Directoryと同期させることができます。詳細は、『Oracle Fusion Middleware高可用性ガイド』のOracle Directory Integration Platformのコンポーネント・アーキテクチャに関する項を参照してください。
注意: Oracle Identity ManagerはOracle Virtual DirectoryサーバーまたはlibOVDを使用して、サード・パーティ・ディレクトリにアクセスします。 |
このドキュメントで説明する単一ノード・トポロジとは異なり、エンタープライズ統合トポロジは、高可用性、フェイルオーバーおよびファイアウォールなどの機能も考慮され、このドキュメントの範囲外です。
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。エンタープライズ統合トポロジの概念と実装手順の説明が記載されています。
このドキュメントの統合シナリオは、Oracle Internet Directory LDAPサーバーで構成される単純なアイデンティティ・ストア・トポロジに焦点を当てていますが、サイトでMicrosoft Active Directoryなどのサード・パーティ・ディレクトリに一部のユーザー・データが格納されていたり、Oracle Internet Directoryに他のユーザー・データが格納されている場合があります。
このトポロジを考慮するために、Oracle Virtual Directoryを使用して、Oracle Identity Managementの各コンポーネントが解釈できる単一の統合ビューにすべてのアイデンティティ・データを提供できます。
構成の詳細は、第12章を参照してください。
表1-1は、Oracle Fusion Middleware環境のアーキテクチャおよびトポロジの説明に使用される主要な用語および頭字語を示しています。
表1-1 Oracle Fusion Middlewareの統合の用語
用語 | 定義 |
---|---|
IdM構成ツール |
アイデンティティ管理コンポーネントのステータスを検証し、特定の統合タスクを実行するためのコマンドライン・ツール。 |
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 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 Fusion Middleware Oracle Access Management管理者ガイド』のIDMドメイン・エージェントの集中ログアウトの構成に関する項。 |
Oracle Identity Managerは、エンタープライズITリソース内のユーザーのアクセス権限を自動的に管理する、強力かつ柔軟なエンタープライズ・アイデンティティ管理システムです。Oracle Identity Managerは、企業のすべてのリソースにわたってユーザー・アクセス権限を管理するために基礎から設計されており、最初のアクセス権限の作成からビジネス要件の変化に対する動的な対応に至るまでアイデンティティ管理ライフサイクル全体を管理します。
Oracle Identity Managerとの統合の詳細は、第9章「Access Manager、OAAMおよびOIMの統合」を参照してください。
Oracle Adaptive Access Managerは、エンタープライズ向けにWebアクセスのリアルタイム不正検出およびオンライン多要素認証セキュリティを提供するOracle Identity Managementのソリューションです。
Oracle Adaptive Access Managerとの統合の詳細は、次を参照してください。
クラウド、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サービスの使用方法の詳細は、第10章「Identity Federationとの統合」を参照してください。
Oracle Identity Navigatorは、ブラウザ経由でアクセスするWebベースのアプリケーションです。これを使用してAccess Manager、Oracle Adaptive Access Manager、Oracle Identity Manager、Directory Services (ODSM)およびその他のOracle Identity Managementのコンポーネントのコンソールにアクセスできます。
Access Managerとの統合の詳細は、第11章「Oracle Identity Navigatorとの統合」を参照してください。
表1-2は、このドキュメントで説明する統合手順へのリンクを示しています。
表1-2 統合手順へのリンク
統合するコンポーネント | リンク |
---|---|
インストール後のLDAPとOracle Identity Managerとの同期 |
|
Oracle Virtual DirectoryとOracle Identity Manager |
|
Oracle Virtual DirectoryとAccess Manager |
|
Oracle Internet DirectoryとAccess Manager |
|
Access ManagerとOracle Identity Manager |
|
Access ManagerとOracle Adaptive Access Manager |
|
Access Manager、Oracle Identity ManagerおよびOracle Adaptive Access Manager |
|
Access ManagerとIdentity Federation |
|
Access ManagerとOracle Identity Navigator |
|
マルチディレクトリ・アイデンティティ・ストア |
|
この項では、Access Manager、Oracle Adaptive Access ManagerおよびOracle Identity Managerを統合するための一般的なシナリオ、リソース保護と収集およびパスワード管理の利点について説明します。
この項では、Access ManagerとOAAMの高度な統合内の保護されたリソースにユーザーがアクセスを試みるときのプロセス・フローについて説明します。高度な統合オプションは、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 Agentにより、(未認証の)リクエストが捕捉され、ユーザーが、暗号化されたTAPトークンとともにOAAMサーバーにリダイレクトされます。
OAAMサーバーによって、TAPトークンからユーザーの現在の認証ステータスがチェックされます。TAPトークンには、現在の認証レベルが含まれています。現在の認証レベルの値に応じて、Oracle Adaptive Access Managerは、そのユーザーを認証するかどうかを決定できます。したがって、ユーザーは次のフローの1つを通過することになります。
認証フローの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』の認証フローに関する項を参照してください。
このシナリオでは、ユーザーは、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によって、ユーザー・デバイスのフィンガープリントが取得されます(デバイス・フィンガープリンティング)。
Oracle Adaptive Access Managerによって、認証後ルールが実行されます。それにより、ユーザーのリスク・スコアが決定され、ポリシーに指定されている任意のアクション(たとえば、KBAやOTP)またはアラートが実行されます。
ユーザーは、リスク・スコアに応じてチャレンジ・フローに入れられることもあります。
チャレンジ・フローが成功し、そのユーザーの適切なプロファイルが登録されている場合、Oracle Adaptive Access Managerによってそのユーザー名を含むTAPトークンが作成され、それがAccess Managerに送り返されます。Access Managerは戻されたトークンをアサートします。トークンをアサートした後、Access ManagerはそのCookieを作成し、通常のシングル・サインオン・フロー(ユーザーを保護されたリソースにリダイレクトする)を続行します。
ユーザーがOracle Adaptive Access Managerに未登録
ユーザーがOracle Adaptive Access Managerに登録されていない場合、プロセス・フローは次のようになります。
ユーザーが登録されていない場合は、KBAやOTPなどの登録を行うように求められます。登録が必須であるかオプションであるかが指定されたセキュリティ要件に基づいて、登録が要求されます。
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により、ユーザー・デバイスのフィンガープリントが取得され、ユーザーがOAAMパスワード・ページに進むことを許可するかどうかを決定する認証前ルールが実行されます。
ユーザーが次に進むことを許可された場合は、認証パッド・チェックポイント中に仮想認証デバイス・ルールが実行されます。これらのルールにより、どの仮想オーセンティケータをOAAMパスワード・ページに表示するかが決定されます。
ユーザーがOracle Adaptive Access Managerに登録されている場合は、OAAMサーバーにより、パーソナライズされたTextPadまたはKeyPadとともにOAAMパスワード・ページが表示されます。
ユーザーが登録されていない場合は、Oracle Adaptive Access Managerにより、汎用TextPadとともにOAAMパスワード・ページが表示されます。
ユーザーは、OAAMパスワード・ページで自分のパスワードを送信します。
Oracle Adaptive Access Managerから収集された資格証明は、Oracle Access Management OAP APIを使用してアイデンティティ・ストアに対して検証されます。Access Manager側での検証の後、Oracle Adaptive Access Managerにより認証後ルールが実行されます。
Oracle Adaptive Access Managerにより、ユーザーとの相互作用を通じて、目的のアクションを実行するためにアイデンティティが確立されます。Oracle Adaptive Access Managerにより、ユーザーのリスク・スコアが決定され、ポリシーに指定されている任意のアクション(たとえば、KBAやOTP)またはアラートが実行されます。
ユーザーが登録されていない場合は、必要に応じてKBAやOTPなどの登録を行うように求められます。
登録が必須であるかオプションであるかが指定されたセキュリティ要件に基づいて、登録が要求されます。
I認証が成功し、ユーザーに登録済の適切なプロファイルがある場合は、Oracle Adaptive Access Managerによりこのユーザー名のTAPトークンが構成され、Access Managerに戻されます。Access Managerは戻されたトークンをアサートします。トークンをアサートした後、Access ManagerはそのCookieを作成し、通常のシングル・サインオン・フロー(ユーザーを保護されたリソースにリダイレクトする)を続行します。
ユーザーが、TAPschemeによって保護されているリソースへのアクセスに必要なレベルより高いレベルですでに認証されている場合、フローがOracle Adaptive Access Managerによって中断されることなく、ユーザーは保護されているリソースに直接アクセスできます。
この項では、Access ManagerとOAAMの基本統合内の保護されたリソースにユーザーがアクセスを試みるときのプロセス・フローについて説明します。このデプロイメントは、別のOAAMサーバーを必要とせずにログイン・セキュリティおよびナレッジ・ベース認証(KBA)を提供します。
ユーザーは、Access Managerによって保護されたリソースにアクセスを試みます。
Oracle Access Management Webゲートにより、リクエストが捕捉され、ユーザーがOAAMサーバーにリダイレクトされます。
Access Managerにより、OAAM APIがコールされ、ユーザーに進むことを許可するかどうかを決定する認証前ルールが実行されます。
Access Managerによって、ALLOW、BLOCK、DENYなどのルール結果に基づいた適切なページが表示されます。
ユーザーに進むことを許可する場合、Access Managerによってパスワード・ページが表示されます。
ユーザーは、パスワード・ページで自分のパスワードを送信します。
Access Managerから収集された資格証明がアイデンティティ・ストアに対して検証されます。
検証後、Access ManagerによってOAAM APIが再度コールされ、認証後ルールが実行されます。
Access Managerによって、ルール結果(REGISTER USER、REGISTER QUESTIONS、REGISTER USER (オプション)、CHALLENGE、ALLOWまたはBLOCK)に基づいて適切なセットのページが表示されます。
たとえば、結果がREGISTER USERである場合、ユーザー登録プロセスの一部として(最初のログインの場合)、ユーザーは3つのチャレンジ質問を選択して回答するように求められます。
たとえば、結果がCHALLENGEである場合、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 Adaptive Access ManagerおよびOracle Identity Managerを統合する場合
このシナリオでは、ユーザーはOAAMパスワード・ページを表示して「パスワードの変更」リンクをクリックします。
ユーザーはブラウザを使用して、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により、Oracle Access Management Java APIがコールされ、資格証明が検証されます。
認証が成功し、登録済の質問があるもののパスワードの再設定をユーザーが希望する場合、ユーザーは「パスワードの変更」リンクをクリックします。
ユーザーは、Oracle Adaptive Access Managerの「パスワードの変更」URLにリダイレクトされ、そこでユーザーはパスワードを変更できます。
Oracle Adaptive Access Managerにより、現在のパスワードおよび新しいパスワードが収集され、そのオーセンティケータを使用してユーザーからのパスワードが確認されます。
Oracle Identity Managerから取得されたパスワード・ポリシー情報が表示され、ユーザーが適切なパスワードを選択するように指示されます。
Oracle Adaptive Access Managerにより、Oracle Identity Managerコールが行われ、リポジトリ内のパスワードが更新されます。
更新が成功すると、Oracle Adaptive Access Managerにより、ユーザーがAccess Managerによって保護されたリソースにリダイレクトされます。
パスワードを忘れた場合のフローでは、ユーザーはすべてのチャレンジ質問に正しく回答した後で各自のパスワードをリセットできます。
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ゲートにより、(未認証の)リクエストが捕捉されます。
Oracle Access Management Webゲートにより、ユーザーがOAAMサーバーにリダイレクトされます。
OAAMサーバーによって、ユーザーにOAAMユーザー名ページが提示されます。
ユーザーは、OAAMユーザー名ページで自分のユーザー名を送信します。
Oracle Adaptive Access Managerにより、ユーザー・デバイス(デスクトップ・コンピュータ、ラップトップ・コンピュータ、PDA、携帯電話、キオスクまたは他のWeb対応デバイス)のフィンガープリントが取得され、ユーザーがOAAMパスワード・ページに進むことを許可するかどうかを決定する認証前ルールが実行されます。
ユーザーが次に進むことを許可された場合は、OAAMサーバーにより、仮想認証デバイス・ルールで指定された強力なオーセンティケータとともにOAAMパスワード・ページが表示されます。
ユーザーは、OAAMパスワード・ページで「パスワードをお忘れですか」リンクをクリックします。
Oracle Adaptive Access Managerにより、ユーザーに対して事前登録されたチャレンジ質問のセットが表示されます。
ユーザーは、チャレンジ質問に対する回答を入力します。
Oracle Adaptive Access Managerにより、ファジー・ロジックを使用してチャレンジ質問に対する回答が検証されます。
ユーザーが正しい回答を入力した場合は、「パスワードのリセット」ページにリダイレクトされます。
Oracle Adaptive Access Managerにより、Oracle Identity Managerを呼び出すことによってOracle Identity Managerからパスワード・ポリシー・テキストが取得され、「パスワードのリセット」ページに表示されます。
ユーザーは、新しいパスワードを入力します。
Oracle Adaptive Access Managerにより、Oracle Identity Managerが呼び出され、リポジトリが新しいパスワードで更新されます。
更新が成功すると、Oracle Adaptive Access Managerにより、ユーザーがAccess Managerによって保護されたリソースにリダイレクトされます。
Access Managerでは、ログイン試行を追跡し、その回数が確立された制限を超えるとアカウントをロックします。
アカウントがロックされると、Access Managerによりヘルプ・デスクの連絡先情報が表示されます。
エンド・ユーザーから連絡を受けると、ヘルプ・デスクはOracle Identity Manager管理コンソールを使用してアカウントをロック解除します。その後Oracle Identity Managerにより、Access 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シングル・サインオン・フローがトリガーされます。
チャレンジの設定により、ユーザーはチャレンジ質問および回答を登録できます。
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がOracle Adaptive 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をコールして資格証明が検証されます。
認証が成功し、ユーザーに登録済の質問があるもののユーザーがチャレンジ質問のリセットを希望する場合、ユーザーは「チャレンジのリセット」リンクをクリックします。
ユーザーは、Oracle Adaptive Access Managerにリダイレクトされ、そこでチャレンジ質問をリセットできます。
チャレンジ登録をリセットした後、Oracle Adaptive Access Managerによりユーザーはチャレンジを登録するように求められます。
ユーザーが登録を完了しなかった場合は、次のログイン時に登録を求められます。
ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システム要件と動作要件のドキュメントを参照してください。これらのドキュメントは、Oracle Technology Network (OTN)で入手できます。
システム要件に関するドキュメントには、ハードウェア要件およびソフトウェア要件、ディスク領域とメモリーの最小要件、必要なシステム・ライブラリ、パッケージ、パッチなどの情報が記載されています。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html
動作要件のドキュメントには、サポートされているインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDK、ディレクトリ・サーバーおよびサードパーティ製品が記載されています。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
Oracle Fusion Middlewareの問題の解決にMy Oracle Support (以前のMetaLink)を使用できます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。
ナレッジ・ベース記事
コミュニティ・フォーラムとディスカッション
パッチとアップグレード
動作保証情報
注意: My Oracle Supportを使用してサービス・リクエストを記録することもできます。 |
My Oracle Supportにはhttps://support.oracle.com
からアクセスできます。