| Oracle Identity Manager Connector概要 リリース9.1.0 B50388-01 |
|
 戻る |
 次へ |
Oracle Identity Managerを使用すると、組織のITリソースを1箇所で集中管理できます。Oracle Identity Managerには、各種のリソースとの統合を可能にする様々なソリューションが用意されています。Oracle Identity Managerコネクタは、推奨される統合ソリューションです。
ターゲット・システムとOracle Identity Managerの統合は次の2つの部分で構成されます。
ターゲット・アカウントの管理
ターゲット・アカウント管理の機能は、さらに次の2つに分けられます。
ターゲット・リソースのリコンシリエーション: これは、既存のOIMユーザーに対してターゲット・システム・アカウントを作成、変更または削除するすべてのアクションが、Oracle Identity Managerに送信されレプリケートされるプロセスです。
プロビジョニング: これは、Oracle Identity Managerでターゲット・システム・アイデンティティを作成、変更または削除するすべてのアクションが、ターゲット・システムに送信されレプリケートされるプロセスです。
信頼できるソースのリコンシリエーション
これは、認可ソースでユーザーのアイデンティティ情報を作成、変更または削除するすべてのアクションが、Oracle Identity Managerに送信されレプリケートされるプロセスです。
リコンシリエーションとプロビジョニングによって、組織のあらゆるターゲット・システムの管理対象アイデンティティをOracle Identity Managerが正確に把握することを目的としています。
データ・フローに関しては、プロビジョニングではOracle Identity Managerから外部へのフローが提供されます。プロビジョニングはプッシュ・モデルに基づくもので、Oracle Identity Managerではこれを使用して、変更をターゲット・システムに送信します。リコンシリエーションでは、Oracle Identity Managerの内側へのフローが提供されます。リコンシリエーションはプッシュ・モデルまたはプル・モデルに基づくもので、Oracle Identity Managerではこれを使用して、ターゲット・システムのアイデンティティ関連アクティビティを検出します。プッシュ・モデルをサポートするターゲット・システムは、アイデンティティ関連の変更をOracle Identity Managerのようなサード・パーティ・システムに送信する機能を備えています。プル・モデルは、プッシュ・モデルをサポートしないターゲット・システムで使用されます。プル・モデルは、アイデンティティ関連の変更に関してターゲット・システムを定期的にポーリングすることで実装されます。
この章では、次の項目について説明します。
Oracle Identity Managerは、アイデンティティ対応の異種ITシステムとの統合のために3層の統合ソリューション戦略を提供します。この3層の戦略は、最小限のカスタム開発、最大限のコード再利用、および開発時間の短縮を目的としています。この3つの層を次に示します。
事前定義済コネクタおよび事前定義済汎用テクノロジ・コネクタ・プロバイダを使用したすぐに利用できる統合方法
カスタム汎用テクノロジ・コネクタ・プロバイダを使用して作成されるコネクタ
アダプタ・ファクトリを使用して作成されるカスタム・コネクタ
図1-1に、Oracle Identity Managerの3層の統合ソリューション戦略を示します。
この項では、次の項目について説明します。
ターゲット・リソースで事前定義済コネクタを使用できる場合、推奨される統合方法は事前定義済コネクタによる統合です。事前定義済コネクタはターゲット・アプリケーション専用に設計されているため、最も迅速な統合方法となります。事前定義済コネクタは、Oracle eBusiness Suite、PeopleSoft、Siebel、JD EdwardおよびSAPなどの一般的なビジネス・アプリケーションの他、Microsoft Active Directory、Java Directory ServerおよびUNIXの各データベース、RSA ClearTrustなどのテクノロジ・アプリケーションもサポートします。事前定義済コネクタは、ターゲット・システムで推奨される統合テクノロジを使用し、ターゲット・システム固有の属性で事前に構成されています。
Oracle Identity Managerを、対応する事前定義済コネクタがないターゲット・システムと統合するには、カスタム・コネクタを作成してターゲット・システムとOracle Identity Managerをリンクできます。アダプタ・ファクトリのカスタマイズ機能を使用しない場合は、Oracle Identity Managerの汎用テクノロジ・コネクタ機能を使用してコネクタを作成できます。
|
関連項目: 汎用テクノロジ・コネクタの詳細は、『Oracle Identity Manager管理およびユーザー・コンソール・ガイド』の第II部「統合ソリューション機能」を参照してください。 |
テクノロジ・インタフェースまたはアクセス可能なユーザー・リポジトリがターゲット・システムにない場合は、ターゲット・システムのためにカスタム・コネクタを開発できます。Design Consoleのアダプタ・ファクトリ・ツールには定義ユーザー・インタフェースがあり、これを使用すると、コーディングやスクリプトを作成せずに、このようなカスタム開発を簡単に行うことができます。
|
関連項目: アダプタ・ファクトリの詳細は、『Oracle Identity Manager概要』のアダプタ・ファクトリに関する項、および『Oracle Identity Managerデザイン・コンソール・ガイド』を参照してください。 |
Oracle Identity Managerは、ユーザーおよび権限を管理し、リソースへのユーザー・アクセスを制御する集中管理メカニズムです。しかし、Oracle Identity Managerをユーザー・アカウントのプライマリ・リポジトリまたはフロントエンド・エントリ・ポイントとして使用しないことも選択できます。かわりに、ターゲット・システムに存在するすべてのアカウントの最新プロファイルをメンテナンスするために、Oracle Identity Managerを使用してそのシステムを定期的にポーリングできます。これが、Oracle Identity Managerのリコンシリエーション構成です。
|
注意: 一部のターゲット・システムでは、ユーザー・データに対する更新のリコンシリエーションがリアルタイムで発生し、Oracle Identity Managerによるターゲット・システムの定期的なポーリングを必要としません。 |
図1-2にリコンシリエーションを示します。
この図に示すように、リコンシリエーション構成では、Oracle Identity Managerはターゲット・システムのすべてのユーザーおよびユーザー・グループ・データに対して単一の更新済ストアとしてのみ使用されます。ユーザーは、ローカル・リソース固有の管理者によって作成、削除およびメンテナンスされます。
リコンシリエーションでは、Oracle Identity Managerのユーザー検出機能とアカウント検出機能が使用されます。
次の各項では、リコンシリエーションについて詳しく説明します。
リコンシリエーションの構成では、次のリコンシリエーション・パラメータからオプションを組み合せて選択します。
リコンシリエーション構成の例は、「リコンシリエーション構成の例」を参照してください。
この項では、ターゲット・リソースと信頼できるソースというリコンシリエーションのタイプについて説明します。
リコンシリエーションを構成するときに、ターゲット・システムをターゲット・リソースとして指定できます。ターゲット・リソースのリコンシリエーションの実行では、OIMユーザーに割り当てられたリソースが、同じユーザーのターゲット・システム・アカウントと同期されます。
次の例で、ターゲット・リソースのリコンシリエーションがどのように行われるかを説明します。
Microsoft Active DirectoryでユーザーJohn Doeのアカウントが作成されるとします。ターゲット・リソースのリコンシリエーションを次に実行した後に、Microsoft Active DirectoryリソースがJohn DoeのOIMユーザー・アイデンティティに割り当てられます。OIMユーザーに割り当てられるリソースの属性は、Microsoft Active Directoryで作成されたアカウントの属性と同じ値になります。
Microsoft Active Directoryでアカウントに変更が行われると、その後のリコンシリエーションの実行時に、OIMユーザーに割り当てられたリソースにも同じ変更が行われます。
図1-3に、ターゲット・リソースのリコンシリエーションで行われる手順を示します。
リコンシリエーションを構成するときに、ターゲット・システムを信頼できるソースとして指定できます。次の例で、信頼できるソースのリコンシリエーションがどのように行われるかを説明します。
Microsoft Active DirectoryでユーザーJohn Doeのアカウントが作成されるとします。信頼できるソースのリコンシリエーションを次に実行した後で、John DoeのOIMユーザー・アイデンティティが作成されます。OIMユーザーの属性は、Microsoft Active Directoryで作成されたアカウントの属性と同じ値になります。
Microsoft Active Directoryでアカウントに変更が行われる、その後のリコンシリエーションの実行時に、OIMユーザーにも同じ変更が行われます。
図1-4に、信頼できるソースのリコンシリエーションで行われる手順を示します。
組織のオペレーティング環境では、1つのユーザー・アカウントを構成する様々な属性に対して信頼できるソースとして複数のターゲット・システムが使用されることがあります。たとえば、従業員の姓名には人事システム、従業員の電子メール・アドレスにはMicrosoft Active Directoryを利用できます。このようなシナリオでは、各ターゲット・システムをユーザー・アカウントの特定の属性または一連の属性に関する信頼できるソースとして構成できます。このためには、複数の信頼できるソースのリコンシリエーションを構成します。これは、信頼できるソースのリコンシリエーションの特殊な実装です。
複数の信頼できるソースのリコンシリエーションの別の形としては、特定のユーザー・タイプに属するユーザー・アカウントの信頼できるソースとして複数のターゲット・システムを指定します。これは次の例で説明します。
組織のオペレーティング環境で、顧客のトランザクションを管理するためにSiebelが使用されています。顧客に対して作成されるユーザー・アカウントは、Customerユーザー・タイプにグループ分けされます。従業員の情報を格納するためにはSun Java System Directoryが使用されており、ユーザー・アカウントはEmployeeユーザー・タイプにグループ分けされます。複数の信頼できるソースのリコンシリエーションを構成するときは、Customerユーザー・タイプのすべてのアカウントの信頼できるソースとしてSiebelを指定し、Employeeユーザー・タイプのすべてのアカウントの信頼できるソースとしてSun Java System Directoryを指定します。
まとめると、複数の信頼できるソースのリコンシリエーションは次のいずれかの形で実装できます。
各ターゲット・システムを、ユーザー・アカウントの特定の属性または一連の属性に対して信頼できるソースとして指定する。
各ターゲット・システムを、特定のユーザー・タイプの信頼できるソースとして指定する。
Oracle Identity Managerを使用してターゲット・システムに対する完全リコンシリエーションを実行できます。このリコンシリエーション・モードの目的は、リコンシリエーション時に処理するためにすべてのターゲット・システム・アカウントをフェッチすることです。完全リコンシリエーションは、ターゲット・システムでのリコンシリエーションの初回実行時にデフォルトで実行されます。このリコンシリエーションの実行開始時のタイムスタンプがOracle Identity Managerに記録されます。リコンシリエーションの次回実行では、記録されたタイムスタンプ以降に追加、変更または削除されたアカウントがリコンシリエーションのためにフェッチされます。つまり、2回目のリコンシリエーションの実行から、増分リコンシリエーションがデフォルトのリコンシリエーション・モードになります。
増分リコンシリエーションから完全リコンシリエーションまたは完全リコンシリエーションから増分リコンシリエーションへは手動で切り替えることができます。
リコンシリエーションの実行時に、ターゲット・システムのレコードの変更はすべてOracle Identity Managerにデフォルトでリコンサイルされます。リコンサイルされるレコード数によっては、このプロセスが完了するまで長い時間がかかることがあります。また、リコンシリエーション中に接続が切断すると、プロセスの時間がさらに長くなる場合があります。このような問題を回避するためにバッチ・リコンシリエーションを構成できます。
バッチ・リコンシリエーションでは、リコンサイルするレコード全体が複数のバッチに分割されます。バッチには、バッチ・サイズとして指定した数のレコードが含まれます。
この機能の実際の実装はコネクタごとに少し異なることがあります。次の例で、バッチ・リコンシリエーションがどのように行われるかを説明します。
組織のオペレーティング環境でSun Java System Directoryがターゲット・システムとして構成されているとします。このターゲット・システムに対してバッチ・リコンシリエーションを構成するには、スケジュール済タスクの次の属性に値を指定します。
StartRecord: この属性は、バッチ・リコンシリエーションを開始する必要のあるレコード数を指定するために使用します。この属性の値に120を指定するとします。
BatchSize: この属性は、各バッチに含めるレコード数を指定するために使用します。この属性の値に50を指定するとします。
NumberOfBatches: この属性は、リコンサイルする必要があるバッチの合計数を指定するために使用します。この属性の値に6を指定するとします。
リコンシリエーションの次回実行の開始時に、リコンサイルされるレコードが136件ある場合、これらのレコードは50件、50件、36件の3つのバッチに分けられ、各バッチはOracle Identity Managerにリコンサイルされます。
バッチ・リコンシリエーションを構成しない場合は、バッチ・サイズを指定しないでください。その場合、非バッチ・リコンシリエーションが行われます。
デフォルトでは、リコンシリエーションの前回実行後に追加または変更されたすべてのターゲット・システムのレコードが、現在のリコンシリエーションの実行中にリコンサイルされます。リコンサイルする必要がある新規追加されたレコードまたは変更されたレコードの一部を指定して、リコンシリエーション用のレコードをフィルタ処理することができます。この形式の制限付きリコンシリエーションは、リコンシリエーション用にカスタマイズ済問合せを作成して実装します。次の例で、制限付きリコンシリエーションがどのように行われるかを説明します。
Sun Java System Directoryの場合、カスタマイズ済問合せをITリソース・パラメータCustomizedReconQueryの値として指定することで、制限付きリコンシリエーションを実装します。カスタマイズ済問合せの例を次に示します。
givenname=John&sn=Doe
このカスタマイズ済問合せでは、名がJohn、姓がDoeのユーザーのレコードがリコンサイルされます。
givenname=John&sn=Doe|departmentnumber=033
このカスタマイズ済問合せでは、次の条件のいずれかを満たすユーザーのレコードがリコンサイルされます。
ユーザーの名がJohn、姓がDoeである。
ユーザーが、番号が033の部門に属する。
制限付きリコンシリエーションを構成しない場合は、カスタマイズ済問合せを指定しないでください。標準リコンシリエーションが行われます。
Oracle Identity Managerを使用して、定期、オンデマンドおよびリアルタイム・リコンシリエーションを行うことができます。
|
注意: これらすべてのリコンシリエーションはどのコネクタでもサポートされるわけではありません。 |
定期リコンシリエーションは、定期的な間隔で実行されるリコンシリエーションです。通常、定期リコンシリエーションはスケジュール済タスクを使用してスケジュールされます。たとえば、特定のコネクタについて1日、1週間または1か月間隔でリコンシリエーションを実行するようにスケジュールできます。
オンデマンド・リコンシリエーションは、必要に応じて開始するリコンシリエーションの実行です。次に例を示します。
毎日午前1:00に実行するようにリコンシリエーションをスケジュールしているとします。ある日曜日にターゲット・システムが大幅に変更され、この変更をすぐにOracle Identity Managerでリコンサイルする必要があります。この状況では、変更をOracle Identity Managerにコピーするためにリコンシリエーションの実行を手動で開始できます。
リアルタイム・リコンシリエーションでは、作成または変更されたデータがターゲット・システムからOracle Identity Managerにすぐに送信されます。通常、このようなデータ送信はリスナーを介して実行されます。ターゲット・システムでデータが作成または変更されると常に、変更されたデータをターゲット・システムがリスナーに送信します。リスナーがこのデータを解析してOracle Identity Managerに転送します。
前述したように、リコンシリエーションを構成するには、これまでの項で説明したリコンシリエーション・パラメータから特定のオプションを選択します。Oracle Identity Managerリリース9.1.0でサポートされるリコンシリエーション構成の例を次に示します。
|
注意: リリース9.1.0のOracle Identity Managerコネクタは、Oracle Identity Managerリリース9.1.0にのみデプロイできます。 |
単一のターゲット・システムに対する信頼できるソース、完全、バッチおよび標準のリコンシリエーション。たとえば、すべてのOracle Identity Managerユーザーに対するOracle e-Business Employee Reconciliation。
単一のターゲット・システムに対する信頼できるソース、増分および標準のリコンシリエーション。たとえば、すべてのOracle Identity Managerユーザーに対するOracle e-Business Employee Reconciliation。
ターゲット・リソース、完全および標準のリコンシリエーション。たとえば、すべてのユーザー・アカウントに対するIBM RACF。
ターゲット・リソース、増分およびバッチのリコンシリエーション。たとえば、すべてのユーザー・アカウントに対するLotus Notes。
信頼できるソースが複数ある環境では、次のリコンシリエーションの実行を組み合せることにより、単一のOracle Identity Managerデプロイメントへのユーザー・アイデンティティの完全な移入が実現します。
複数の信頼できるソース、完全、非バッチおよび制限付き（userType=Employee）のリコンシリエーション。たとえば、OIMユーザー・タイプEmployeeでのみ信頼できるソースとして使用されるOracle e-Business Employee Reconciliation。
複数の信頼できるソース、完全、バッチおよび標準のリコンシリエーション。たとえば、OIMユーザー・タイプContractorでのみ信頼できるソースとして使用されるMicrosoft Active Directory。
リコンシリエーション・イベントは、想定されるOracle Identity Manager内での動作によって2種類に分類できます。受信データが、それまでOracle Identity Managerが認識していなかったために作成する必要があるアカウント、またはOracle Identity Managerにそのレコードが存在するために更新する必要があるアカウントに関連する場合は、リコンシリエーション・イベントを標準リコンシリエーション・イベントと呼びます。
受信データが、削除（失効）とマークする必要があるアカウントに関連する場合は、リコンシリエーション・イベントを削除リコンシリエーション・イベントと呼びます。削除リコンシリエーション・イベントには次の2つのタイプがあります。
アカウントを削除するためのデータが指定され、Oracle Identity Managerが既存のルールに基づいて一致するアカウントを検索するイベント。
Oracle Identity Managerの一致するアカウント・レコードが、アカウントを削除するためのデータとして指定されるイベント。
後者は、リコンシリエーションの削除検出メカニズムが採用されている場合に発生します。どちらのタイプも、アカウントが一致すると、Oracle Identity Managerのリソース・インスタンスが失効としてマークされます。
Oracle Identity Managerを使用すると、ターゲット・システム上でユーザーを作成、メンテナンスおよび削除できます。この構成では、Oracle Identity Managerはターゲット・システム上のユーザー・データを管理するフロントエンド・エントリ・ポイントとして機能します。アカウントがプロビジョニングされると、アカウントがプロビジョニングされたユーザーは、Oracle Identity Managerと対話しなくてもターゲット・システムにアクセスできます。これが、Oracle Identity Managerのプロビジョニング構成です。図1-5に、Oracle Identity Managerのプロビジョニング構成を示します。
プロビジョニング操作は次のいずれかの方法で開始できます。
リクエストベースのプロビジョニング
リクエストベースのプロビジョニングでは、個人がターゲット・システム・アカウントのリクエストを作成します。必要な権限を持つOIMユーザーがリクエストを承認して、リクエストしたユーザーにターゲット・システム・アカウントをプロビジョニングすると、プロビジョニング・プロセスが完了します。
ポリシーベースのプロビジョニング
このタイプのプロビジョニングでは、アクセス・ポリシーを介してリソースがユーザーに自動的に付与されます。アクセス・ポリシーは、ユーザー・グループ（またはロール）とターゲット・リソースの間の関連を定義するために使用されます。ユーザー・グループとは、共通の機能（アクセス権、ロール、権限など）へのアクセスを付与するユーザーの集合です。ユーザー・グループを使用して、グループ・メンバーのレコードを作成し、集合的に管理します。
また、このようなグループに対して、メンバーシップ・ルールの割当てや削除もできます。これらのルールでは、特定のユーザー・グループに割当てできるユーザーが定義されます。デフォルトでは、これらのユーザー・グループの各メンバーは、ターゲット・システムの事前定義済アカウントを取得します。また、Oracle Identity Managerを使用して、ポリシーベースのプロビジョニング・サイクルの一環として実行できる承認プロセスを作成することもできます。
場合によっては、アクセス・ポリシーの導入またはアクセス・ポリシーへの変更が、そのポリシーに指定された基準を満たすユーザーに割り当てられる権限の変更を伴うことがあります。たとえば、次のポリシーが導入されるとします。
ロンドン事務所で働くすべてのプロジェクト・マネージャはSAPシステムへのアクセス権が必要です。
このポリシーがOracle Identity Managerに導入されると、SAPユーザー・アカウントがすべてのプロジェクト・マネージャに自動的にプロビジョニングされます。
このタイプのプロビジョニングは、Oracle Identity Manager管理者がOIMユーザーにリソースをプロビジョニングするための特別な管理者専用機能です。このプロビジョニング・タイプのワークフローには、リクエストと承認の手順は含まれません。ダイレクト・プロビジョニングは、Oracle Identity Manager管理およびユーザー・コンソールを使用して実行します。
コネクタを使用して実行できる操作のタイプは、次のようなターゲット・システムの構成方法によって異なります。
管理対象リソースすなわちターゲット・リソースとして構成すると、ターゲット・システム・アカウントをOIMユーザーにプロビジョニングできます。Oracle Identity Managerのコンテキストでは、このようなターゲット・システム・アカウントはリソースと呼ばれてOIMユーザーに割り当てられます。
この項では、ターゲット・システムがターゲット・リソースとして構成されているときに実行できるコネクタの操作について説明します。
参照フィールドの同期では、ターゲット・システムで参照フィールド・データに対して行われた追加または変更に関するデータが、Oracle Identity Managerの参照フィールドにコピーされます。参照フィールドの同期は、スケジュール済タスクを使用して開始されます。特定のターゲット・システムの各参照フィールドについて、参照定義がOracle Identity Managerに作成されます。Oracle Identity Managerの参照フィールドはプロビジョニングの際に使用されます。参照フィールド同期の実行中に、ターゲット・システムの参照フィールドの既存データに対する追加または変更が、Oracle Identity Managerの参照定義にレプリケートされます。
ターゲット・リソースで実行できるその他の操作は、ターゲット・リソースのリコンシリエーションとプロビジョニングです。ターゲット・リソースのリコンシリエーションでは、ターゲット・システム自体でのアカウントに対する変更がOracle Identity Managerでリコンサイルされます。つまり、Oracle Identity Managerのリソースが、ターゲット・システムにおける対応するアカウントの変更と同期されます。このようなアクティビティがリコンシリエーションを構成します。
ターゲット・リソースのリコンシリエーション:
ターゲット・システムからフェッチされた新しく作成されたターゲット・システム・アイデンティティの場合、ターゲット・リソース・アカウント（リソース・オブジェクト）が対応するOIMユーザーに付与（プロビジョニング）されます。これが行われるのは、ターゲット・システム・アイデンティティに対するOIMユーザーがすでに存在する場合のみです。
ターゲット・システムからフェッチされた変更済のターゲット・システム・アイデンティティの場合、同じ変更が、Oracle Identity Managerのエンティティにプロビジョニングされた対応するリソース・オブジェクトに行われます。
通常、電子メール・サーバーなどのターゲット・システムはターゲット・リソースとして指定されます。
|
注意: ターゲット・リソースには、プロビジョニング・フローを関連付けることができます。 |
Oracle Identity Managerを介してターゲット・システム上でリソースの作成および管理を行うこともできます。このようなアクティビティがプロビジョニングを構成します。プロビジョニングの目的は、ターゲット・システムでのユーザーの作成およびメンテナンスを自動化することです。プロビジョニングは、そのプロビジョニングのライフ・サイクルの構成要素となりうるワークフローの承認および監査の要件に対応するためにも使用されます。
プロビジョニングの詳細および実行できる様々なタイプのプロビジョニング操作は、「プロビジョニング」を参照してください。
ターゲット・システムは、組織内でエンティティ（個人およびリソース）のアイデンティティ情報の認可ソースとして使用される場合に、信頼できるソースとして認識されます。信頼できるソースの各アイデンティティは、Oracle Identity Managerの1つのOIMユーザーに対応する必要があります。あるエンティティが組織内の他のシステムにアカウントを持つことができるのは、信頼できるソース上にアカウントがある場合のみです。
|
注意: Oracle Identity Managerのコンテキストでは、OIMユーザーという語は、そのユーザーに対して作成されたOracle Identity Managerアイデンティティと同じ意味で使用されます。 |
信頼できるソースのリコンシリエーション:
ターゲット・システムからフェッチされた新しく作成されたターゲット・システム・アイデンティティの場合、対応するOIMユーザーがOracle Identity Managerに作成されます。
ターゲット・システムからフェッチされた変更済のターゲット・システム・アイデンティティの場合、対応するOIMユーザーに対して同じ変更が行われます。
ターゲット・システムの特定の属性を信頼できるソースとして指定した場合は、Oracle Identity Managerによってターゲット・システムで同じ属性のセットのプロビジョニングを行えないようにする必要があります。
通常、人事システムや社内名簿のようなターゲット・システムは信頼できるソースとして指定されます。
