| Oracle Identity Manager概要 リリース9.1.0 E05915-01 |
|
 戻る |
 次へ |
この章では、Oracle Identity Managerの次のデプロイ構成について説明します。
Oracle Identity Managerを使用すると、ターゲット・システムでユーザーを作成、メンテナンスおよび削除できます。この構成では、Oracle Identity Managerは、ターゲット・システムですべてのユーザー・データを管理するためのフロントエンド・エントリ・ポイントとして機能します。アカウントがプロビジョニングされると、アカウントがプロビジョニングされたユーザーは、Oracle Identity Managerと対話しなくてもターゲット・システムにアクセスできます。これが、Oracle Identity Managerのプロビジョニング構成です。
プロビジョニングの目的は、ターゲット・システムでのユーザーの作成およびメンテナンスを自動化することです。プロビジョニングは、そのプロビジョニングのライフ・サイクルの構成要素となりうるワークフローの承認および監査の要件に対応するためにも使用されます。図5-1に、プロビジョニング・モジュールの仕組みを示します。
プロビジョニング・イベントは、次の方法のいずれかで起動できます。
リクエストベースのプロビジョニング
リクエストは、管理者または特定の場合にはユーザー自身によって手動で作成できます。承認ワークフローはリクエストの送信後に開始され、承認済アカウント・プロファイルのプロビジョニングは承認の完了後に開始されます。
ポリシーベースのプロビジョニング
このタイプのプロビジョニングは、アクセス・ポリシーを介したユーザーへのターゲット・リソースの付与の自動化を意味します。アクセス・ポリシーは、ユーザー・グループ（またはロール）とターゲット・リソースの間の関連を定義するために使用されます。デフォルトでは、これらのユーザー・グループの各メンバーは、ターゲット・リソースの事前定義済アカウントを取得します。また、Oracle Identity Managerを使用して、ポリシーベースのプロビジョニング・サイクルの一環として実行できる承認プロセスを作成することもできます。
このタイプのプロビジョニングは、特殊な管理者専用機能です。承認プロセスを待たなくても、ターゲット・システムで特定のユーザーのアカウントを作成できます。
Oracle Identity Managerは、ユーザーおよび権限を管理し、リソースへのユーザー・アクセスを制御する集中管理メカニズムです。しかし、Oracle Identity Managerをユーザー・アカウントのプライマリ・リポジトリまたはフロントエンド・エントリ・ポイントとして使用しないことも選択できます。かわりに、ターゲット・システムに存在するすべてのアカウントの最新のプロファイルを維持するために、Oracle Identity Managerを使用してそのシステムを定期的にポーリングできます。これが、Oracle Identity Managerのリコンシリエーション構成です。
|
注意: 一部のターゲット・システムでは、ユーザー情報に対する更新のリコンシリエーションがリアルタイムで発生し、Oracle Identity Managerによるターゲット・システムの定期的なポーリングを必要としません。 |
図5-2に、リコンシリエーションを示します。
この図に示すように、Oracle Identity Managerは、ターゲット・システムのすべてのユーザー、ユーザー・グループおよび組織データに対して単一の更新済ストアとしてのみ使用されます。ユーザーは、ローカル・リソース固有の管理者によって作成、削除およびメンテナンスされます。
リコンシリエーションでは、Oracle Identity Managerのユーザー検出機能とアカウント検出機能が使用されます。
次の各項では、リコンシリエーションについて詳しく説明します。
リコンシリエーションの構成では、次のリコンシリエーション・パラメータからオプションの組合せを選択します。
リコンシリエーション構成を作成するには、これらの各パラメータからオプションを1つ選択する必要があります。リコンシリエーション構成の例は、「リコンシリエーション構成の例」を参照してください。
この項では、リコンシリエーション・タイプの信頼できるソースおよびターゲット・リソースについて説明します。
リコンシリエーションの構成中に、ターゲット・システムを信頼できるソースとして指定できます。信頼できるソースのリコンシリエーションの実行では、ターゲット・システムで新規作成されたユーザーがOracle Identity Managerにリコンサイルされます。つまり、ターゲット・システムは新しいユーザーに関する情報の信頼できるソースとしての役割を果します。信頼できるソースのリコンシリエーションには、ターゲット・システムとOracle Identity Managerの両方にすでに存在するユーザー・レコードへの変更のリコンシリエーションも含まれます。
図5-3に、信頼できるソースのリコンシリエーションに含まれる手順を示します。
組織の動作環境では、複数のターゲット・システムが、ユーザー・アカウントを構成する様々な属性に対する信頼できるソースとして機能する場合があります。たとえば、従業員の氏名はHRシステムから、従業員の電子メール・アドレスはMicrosoft Active Directoryから取得することがあります。このような場合、ユーザー・アカウントの特定の属性または属性セットに対する信頼できるソースとして、各ターゲット・システムを構成できます。そのためには、複数の信頼できるソースのリコンシリエーションを構成します。これは、信頼できるソースのリコンシリエーションの特殊な実装です。
複数の信頼できるソースのリコンシリエーションの別の形態では、特定のユーザー・タイプに属するユーザー・アカウントの信頼できるソースとして複数のターゲット・システムを指定します。これは、次の例を使用して説明します。
組織の動作環境では、Siebelを使用して顧客とのトランザクションを追跡しています。顧客に対して作成されたユーザー・アカウントは、Customerユーザー・タイプに分類されます。Sun Java System Directoryを使用して、Employeeユーザー・タイプに分類されるユーザー・アカウントの形式で従業員に関する情報を格納します。複数の信頼できるソースのリコンシリエーションを構成する際に、Customerユーザー・タイプのすべてのアカウントにはSiebelを信頼できるソースとして指定し、Employeeユーザー・タイプのすべてのアカウントにはSun Java System Directoryを信頼できるソースとして指定します。
要約すると、複数の信頼できるソースのリコンシリエーションは次のいずれかの形式で実装できます。
各ターゲット・システムをユーザー・アカウントの特定の属性または属性セットに対する信頼できるソースとして指定する。
各ターゲット・システムを特定のユーザー・タイプに対する信頼できるソースとして指定する。
|
関連資料:
|
Oracle Identity Managerについては、信頼できるソースではないターゲット・システムをターゲット・リソースとして指定できます。OIMユーザーの場合、Oracle Identity Managerで実行されるプロビジョニング操作によりターゲット・リソースのアカウントを作成、変更または削除できます。
|
関連資料: 用語OIMユーザーおよびOIMアカウントの定義は、『Oracle Identity Managerリファレンス』の用語集を参照してください。 |
また、これらの操作は、ターゲット・リソース自体に対して実行できます。ターゲット・リソースのリコンシリエーションの実行は、ターゲット・リソースでのユーザー・アカウントの作成および変更をOracle Identity Managerへリコンサイルすることを目的としています。
たとえば、Microsoft Active Directoryターゲット・システムを表すリソースがOracle Identity Managerユーザーにプロビジョニングされ、リソースの属性がOracle Identity Managerの外で変更されるとします。プロビジョニングされたインスタンスの変更は、ターゲット・リソースのリコンシリエーションによりOracle Identity Managerにリコンサイルできます。
図5-4に、ターゲット・リソースのリコンシリエーションに含まれる手順を示します。
Oracle Identity Managerを使用してターゲット・システムで全体リコンシリエーションを実行できます。このモードのリコンシリエーションの目的は、ターゲット・システムのアカウントをすべてOracle Identity Managerにリコンサイルすることです。全体リコンシリエーションは、ターゲット・システムでのリコンシリエーションの初回実行時にデフォルトで実行されます。このリコンシリエーションの実行の最後に、タイムスタンプITリソース・パラメータの値がリコンシリエーションの実行が終了した時刻に設定されます。リコンシリエーションの次回実行では、リコンシリエーションの初回実行の終了後に追加、変更または削除されたユーザー・アカウントのレコードのみが、リコンシリエーションのためにフェッチされます。つまり、2回目のリコンシリエーションの実行から、増分リコンシリエーションがデフォルトのリコンシリエーション・モードになります。
タイムスタンプ・パラメータの値を0に設定すると、増分リコンシリエーションから全体リコンシリエーションに手動で切り替えることができます。リコンシリエーションの次回実行の最後に、タイムスタンプITリソース・パラメータは、リコンシリエーションの実行が終了した時刻に設定され、それ以降は増分リコンシリエーションが実行されます。
|
注意: タイムスタンプ・パラメータの実装は、ターゲット・システムごとに異なります。たとえば、Sun Java System DirectoryではLast Recon TimeStampパラメータが使用されます。 |
リコンシリエーションの実行時に、ターゲット・システムのレコードの変更はすべて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リリース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の公開されたAPIセットには、リコンシリエーションに関連するセットが含まれます。Oracle Identity Managerでは、これらのAPIを使用してリコンシリエーション・イベントを作成します。汎用APIセットの一部であるため、これらのAPIはJavaベースのシステムから使用できます。これらのAPIは、標準および削除のリコンシリエーション・イベントの作成に加え、適切なデータをイベントに提供するためのメカニズムを備えています。
|
関連資料: リコンシリエーションに関連するAPIの詳細は、『Oracle Identity Manager API使用法ガイド』の第2章「新機能」を参照してください。 |
Oracle Identity Managerでターゲット・システムをリソース・オブジェクトとして定義する際に、ターゲット・システムの実際のフィールドを表すリコンシリエーション・フィールドを作成します。これにより、データをターゲット・システムのフィールド名からOracle Identity Managerのフィールド名に変換するためのリコンシリエーション接続の設定が不要になります。
リコンシリエーション・フィールドを定義する場合は、フィールド名以外の情報も指定する必要があります。フィールドが受け取るデータのタイプを示すフィールド・タイプを定義します。フィールド・タイプの値には、String、Number、Date、IT ResourceおよびMulti-Valuedがあります。
定義したリコンシリエーション・フィールドは、プロセス・フォームに定義されているフィールドにマップする必要があります。これらのマッピングの目的は、次のとおりです。
|
関連資料: 『Oracle Identity Managerデザイン・コンソール・ガイド』の「「Process Definition」フォーム」 |
ターゲット・システムから受け取ったデータを使用してプロセス・フォームのフィールドを更新する方法を定義します。
たとえば、Object1リソース・オブジェクトのリコンシリエーション・フィールドがattribute1で、プロセス・フォームのフィールドfield1にマップされる場合、attribute1で受け取った値は、field1に設定される値となります。複数値フィールドの場合、フィールドはプロセス・フォームの特定の子表にマップされます。インタフェースには、子表の要素のみが表示されます。信頼できるソースの場合、プロセス・フォームのフィールドは、ユーザー定義フィールドなどのエンティティ・フォーム（ユーザーまたは組織のフォーム）のフィールドで置き換えられます。
一部のマッピングは、キー・マッピングとして定義できます。これらのマッピングは、更新する必要があるレコードの識別に使用されるプロセス一致ルールを構成します。たとえば、前述の例で定義したマッピングをキー・マッピングとして指定することもできます。その場合、リコンシリエーション・エンジンは、ルールの評価を実行する際に、field1の値がリコンシリエーション・データのattribute1の値と同じであるObject1のプロビジョニングされたインスタンスをすべて検索します。
|
注意: キー・マッピングは、ターゲット・リソースのリコンシリエーションの場合にのみ該当します。 |
|
関連資料: ステータス・リコンシリエーションの詳細は、『Oracle Identity Managerデザイン・コンソール・ガイド』の「「Reconciliation Field Mappings」タブ」を参照してください。 |
リコンシリエーション一致ルールは、Oracle Identity Managerがターゲット・システムで新たに検出されたアカウントを割り当てる必要があるアイデンティティを特定するためにリコンシリエーション・エンジンで使用されます。リコンシリエーション・エンジンでは、ターゲット・システム用に設定された既知のパターンに基づいて、新たに検出されたアカウントのユーザーを検索できます。次の例について考えてみます。
ターゲット・システムのすべてのログインIDが、ユーザーの頭文字と姓から作成されているとします。その場合、ターゲット・システムから受け取ったログインIDを受け入れ、名がログインIDの最初の文字で始まり、姓がログインIDの残りの部分と同じであるユーザーを検索するというルールを設定できます。
|
関連資料: リコンシリエーション一致ルールの詳細は、『Oracle Identity Managerデザイン・コンソール・ガイド』の「「Reconciliation Manager」フォーム」を参照してください。 |
リコンシリエーション・アクション・ルールを使用すると、リコンシリエーション・ルールの評価から発生するシナリオに基づいて、リコンシリエーション・エンジンが自動的に実行する必要がある次のアクションを定義できます。
イベントを管理者に割り当てる。
Oracle Identity Managerで新しいプロビジョニング済リソースを作成し、対応する所有者のアイデンティティに関連付ける。
Oracle Identity Managerで一致したプロビジョニング済リソースを更新する。
Oracle Identity Managerで一致したプロビジョニング済リソースを削除する。
Oracle Identity Managerで新しいユーザーを作成する。
Oracle Identity Managerで既存のユーザーを更新する。
Oracle Identity Managerで既存のユーザーを削除する。
|
関連資料: リコンシリエーション・アクション・ルールの詳細は、『Oracle Identity Managerデザイン・コンソール・ガイド』の「「Resource Objects」フォーム」を参照してください。 |
リコンシリエーション・エンジンでは、構成可能なコンポーネントをすべて使用します。また、これらのコンポーネントを使用して入力データをアクション項目リストに変換するデータ処理機能およびルール評価機能が組み込まれています。また、ルール・コンテキストに基づいてアクションを自動化できるかどうかを判断するコンポーネントも組み込まれています。自動または手動でアクションが実行されると、エンジンは適切な更新およびプロビジョニングのアクションを実行します。
Reconciliation Event ManagerはDesign Consoleのフォームです。このフォームを使用すると、リコンシリエーション・イベントを検討して必要なアクションを実行できます。Reconciliation Event Managerには、受け取ったデータ、ルール評価の結果、実行できるアクション、アクションの結果が表示されます。
フォームのメイン・セクションには、関連付けられているリソース・オブジェクト、イベントが発生した日付、現行のステータス、リンクされているエンティティなどのイベント情報が表示されます。実行できるアクションのための、フォームのアクション・ボタンは次のとおりです。
Close Event: 解決なしでイベントを閉じます。
Re-apply Matching Rules: 処理済データを取り除き、前回のルールの適用による結果を削除して、すべての一致ルールを再適用します。このアクションは、ルールが変更されたときに実行する必要があります。
Create User: 指定されたデータに基づいてOIMユーザーを作成できるようにします。
Create Organization: 指定されたデータに基づいてOIM組織を作成できるようにします。
ターゲット・リソースのリコンシリエーションで、プロビジョニング済リソースの既存のインスタンスにイベントがリンクされると、そのリソース・インスタンス用のプロセス・フォームが更新されます。
|
注意: 信頼できるソースのリコンシリエーションでは、ユーザーまたは組織のレコードがかわりに更新されます。 |
リコンシリエーションの実行前にアカウントがOracle Identity Managerに存在しなかった場合は、デフォルトのプロビジョニング・プロセスが起動され、アダプタは抑止されます。また、すべての非条件付きタスクは自動的に完了します。
どちらの場合も、マーカー・タスクがプロビジョニング済リソース（またはユーザー/組織）のプロビジョニング・プロセスに追加されます。マーカー・タスクは、Reconciliation Insert ReceivedかReconciliation Update Receivedのいずれかになります。これらのタスクには、プロビジョニングを開始するために、アダプタがアタッチされていることがあります。タスクにアダプタがアタッチされていない場合は、レスポンス・コード「Event Processed」がそのタスクに割り当てられます。このレスポンス・コードに基づいてプロビジョニング・プロセス・タスクを追加生成し、リコンシリエーション・イベントによってプロビジョニング・フローを開始することができます。このメカニズムを利用して複数ターゲットの同期化プロセスを開始できます。
リコンシリエーション・イベントは、想定されるOracle Identity Manager内での動作によって2種類に分類できます。入力データが、それまでOracle Identity Managerが認識していなかったために作成する必要があるアカウント、またはOracle Identity Managerにそのレコードが存在するために更新する必要があるアカウントに関連する場合は、リコンシリエーション・イベントを標準リコンシリエーション・イベントと呼びます。標準リコンシリエーション・イベントでは、Oracle Identity Managerはこのアカウントの存在を認識する必要はありません。適切なプロビジョニング・プロセスが設定され、実行されます。
入力データが、削除（失効）とマークする必要があるアカウントに関連する場合は、リコンシリエーション・イベントを削除リコンシリエーション・イベントと呼びます。削除リコンシリエーション・イベントには、次の2種類があります。
アカウントを削除するためのデータが指定され、Oracle Identity Managerが既存のルールに基づいて一致するアカウントを検索するイベント。
Oracle Identity Managerの一致するアカウント・レコードが、アカウントを削除するためのデータとして指定されるイベント。
後者は、リコンシリエーションの削除検出メカニズムが採用されている場合に発生します。どちらの場合も、アカウントが一致すると、プロビジョニング・プロセスはキャンセルされ、リソース・インスタンスは失効とマークされます。
図5-5に、Oracle Identity Managerを使用してプロビジョニングとリコンシリエーションの両方のタスクを実行する、プロビジョニングおよびリコンシリエーション構成を示します。この構成では、ターゲット・システムのアカウントは、ローカル管理者とOracle Identity Managerの両方によって作成およびメンテナンスできることを前提とします。
この構成を実現するには、プロビジョニングとリコンシリエーションの両方の設定にかかわる手順をすべて実行する必要があります。
