リリース9.0.3
E05091-01
 目次 |
 索引 |
| Oracle Identity Manager デザイン・コンソール・ガイド リリース9.0.3 E05091-01 |
|
この章では、Design Consoleのユーザー管理について説明します。次の内容について説明します。
「User Management」フォルダには、会社の組織、ユーザー、ユーザー・グループ、リクエスト、フォーム・テンプレート、場所、プロセス・タスクおよびリコンシリエーション・イベントについての情報をシステム管理者が作成、管理するためのツールがあります。
このフォルダには次のフォームがあります。
「Organizational Defaults」フォームは「User Management」フォルダに表示されます。このフォームは、組織の構成を反映するレコードを表示したり、組織のエンティティに関連する情報を入力および変更するために使用します。組織のレコードには、企業階層、たとえば、会社、部門、または支店における組織単位についての情報が含まれます。サブ組織は、別の組織のメンバーである組織、たとえば、会社の部門などです。サブ組織が属する組織は親組織と呼ばれます。
「Organizational Defaults」タブは、現在の組織に対してプロビジョニングできるリソースの、カスタムのプロセス・フォームのデフォルトのパラメータ値を指定するために使用します。各プロセス・フォームは、その組織に対して許容されているリソース・オブジェクト、または関連する「Resource Objects」フォームの「Allow All」チェック・ボックスが選択されているリソースに関連付けられています。
「Process Defaults」タブに入力した値は、組織のすべてのユーザーのデフォルト値になります。
図5-1に「Organizational Defaults」フォームを示します。
次の表は、「Organizational Default」フォームのデータ・フィールドについて説明しています。
「Policy History」フォームは、ユーザーに対して許可または拒否されているリソースについての情報を表示するために使用します。
Oracle Identity Managerでは、ユーザーのタイプは2つあります。
図5-2にこのフォームを示します。
次の表は、「Policy History」フォームのデータ・フィールドについて説明しています。
このタブは、次の基準に基づいてユーザーに対して許可または拒否されているリソース・オブジェクトを表示するために使用します。
「Policy History」タブには「Display Selection」領域が含まれます。このタブの内容を整理するには、次に示すように、この領域の一番上のボックスのメニューから項目を選択します。
アクセス・ポリシーに基づいてユーザーに対して許可または拒否されているリソース・オブジェクトを表示するには、このボックスからアクセス・ポリシーを選択します。
トラッキング・システムを使用すると、ユーザーがメンバーである組織と、ユーザーに適用されるアクセス・ポリシーに基づいて、ユーザーが許可または拒否されているリソースを表示できます。
ユーザーに対して許可されているリソース・オブジェクトは、「Resources Allowed」リストに表示されます。このリストは、そのユーザーに対してプロビジョニングできるリソース・オブジェクトを表しています。そのユーザーに対してプロビジョニングされているリソース・オブジェクトを表しているわけではありません。
そのユーザーに対して拒否されているリソース・オブジェクトは、「Resources Not Allowed」リストに表示されます。
このトラッキング・システムを表示するには、次の手順を実行します。
User Policy Profile Historyウィンドウが表示されます。
このウィンドウから、次に示す手順で選択したユーザーおよび日付と時刻について、許可または拒否されているリソースを表示できます。
「Group Entitlements」フォームは「User Management」フォルダに表示されます。これは、フォームの作成と移動、およびユーザー・グループのメンバーがエクスプローラを使用してアクセスできるフォームおよびフォルダの指定を行うために使用します。
「Group Entitlements」フォームで作業するには、次の手順を実行します。
「User Group Information」ダイアログ・ボックスが表示されます。
User Formの「Assignment」参照表が表示されます。
矢印ボタンを使用して、「Assigned Forms」リストに対する追加や削除を行います。
「User Group Information」ダイアログ・ボックスが表示されます。
新しく追加したユーザー・フォームは「Group Entitlement」表に一覧表示されます。「Group Entitlement」表には、選択できるすべてのユーザー・グループが表示されます。この表には、ユーザー・フォームの名前とタイプが表示されます。この例では、javaformとfolderの2つのタイプがあります。javaformは、Javaベースのグラフィカル・インタフェースです。folderには、1つ以上のjavaformが含まれています。
Oracle Identity Managerには、4つのデフォルトのユーザー・グループ定義があります。
これらのユーザー・グループに関連付けられた権限は変更できます。他のユーザー・グループを作成することもできます。
「System Administrators」ユーザー・グループのメンバーは、Oracle Identity Managerでレコード（システム・レコード以外）を作成、編集および削除できる完全な権限を持っています。
「Operators」ユーザー・グループのメンバーは、「Organizational Defaults」フォームや「Policy History」フォームを表示したり、制限された機能をこれらのフォームで実行できます。
「All Users」ユーザー・グループのメンバーの権限は最小ですが、自身のユーザー・レコードにアクセスできるなどの機能があります。デフォルトでは、各ユーザーは自動的に「All Users」ユーザー・グループに所属します。
「All Users」グループからユーザーを削除することはできません。
「Self Operators」グループは、デフォルトでOracle Identity Managerに追加されます。このユーザー・グループには、XELSELFREGという1人のユーザーが含まれます。このユーザーは、Oracle Identity Manager管理およびユーザー・コンソールで自動登録操作を行う際、ユーザーが持つ権限の変更を担当します。
プロビジョニング・リクエストを管理するためのユーザーのグループを割り当てるには、キューと呼ばれるエンティティを使用します。キューは、グループ定義の集合です。キューは、他のキュー内にネストできます。
「Administrative Queues」フォームは、キューの作成と管理のために使用します。キューをリクエストに割り当てるには、「Requests」フォームの「Queues」タブを使用します。
管理キューを使用すると、リクエストの効率と管理性が向上します。管理キューを使用することにより、同じ操作を少ない回数のマウス・クリックで実行できます。リクエストに割り当てたキューは、他のリクエストで再利用できます。
リクエストでは、キュー内の各グループに対して異なった管理権限を指定できます。たとえば、3つのユーザー・グループを持つキューをリクエストに割り当てる場合を考えます。3つのグループのメンバーは、リクエストに対してそれぞれ異なった管理権限を持つことができます。
1番目のユーザー・グループは、リクエストの読取り、変更および削除を許可されています。
2番目のユーザー・グループは読取りと変更だけを許可されており、3番目のユーザー・グループは、リクエストの読取りと削除だけを許可されています。
「Administrative Queues」フォームを図5-3に示します。このフォームは「User Management」フォルダに表示されます。
次の表は、「Administrative Queues」フォームのフィールドについて説明しています。
| フィールド名 | 説明 |
|---|---|
|
Queue Name |
管理キューの名前。 |
|
Parent Queue |
この管理キューが所属するキュー。 |
|
Description |
管理キューについての説明情報。 |
親キューおよびネストされたキューを作成できます。次の手順は管理キューを作成する方法を説明します。
管理キューを作成するには、次の手順を実行します。
「Lookup」ダイアログ・ボックスから、このキューがメンバーであるキューを選択します。キューが別のキュー（親キュー）に所属しない場合は、次の手順に進んでください。
「Administrative Queues」キューを起動してキューを作成すると、このフォームのタブが使用可能になります。
「Administrative Queues」フォームには、次のタブが含まれます。
「Members」タブは、現在の管理キューに対するユーザー・グループの追加や削除を行うために使用します。「Members」タブを、図5-4に示します。
図5-4では、「User Group Permissions for Requests」キューが次のように設定されています。
キューにユーザー・グループを割り当てるには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
ユーザー・グループが「Members」タブに表示されます。
それ以外の場合は手順5に進みます。
それ以外の場合は手順6に進みます。
ユーザー・グループが管理キューに割り当てられます。
キューが割り当てられているリクエストの情報をユーザー・グループが読取り、変更または削除できなくなった場合、管理キューからそのユーザー・グループを削除します。
管理キューからユーザー・グループを削除するには、次の手順を実行します。
このタブは、現在の管理キューを読取り、変更および削除できるユーザー・グループを選択するために使用します。図5-5を参照してください。
図5-5では、「SYSTEM ADMINISTRATORS」ユーザー・グループに対して、「Write Access」および「Delete Access」チェック・ボックスが選択されています。これにより、ユーザー・グループは「User Group Permissions for Requests」管理キューの読取り、変更および削除を行うことができます。
管理キューにユーザー・グループを追加すると、グループのメンバーに管理権限が与えられます。
管理キューにユーザー・グループを追加するには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
ユーザー・グループが「Administrators」タブに表示されます。
それ以外の場合は手順5に進みます。
それ以外の場合は手順6に進みます。
これで、このユーザー・グループは管理キュー内の管理グループになりました。
現在の管理キューをユーザー・グループが読取り、変更または削除できなくなった場合、管理キューからそのユーザー・グループを削除します。
管理キューから管理者ユーザー・グループを削除するには、次の手順を実行します。
このフォームは「User Management」フォルダにあります。このフォームを使用すると、ターゲット・リソースおよび信頼できるソースから受け取ったリコンシリエーション・イベントの情報の表示、分析、修正、リンクおよび管理ができます。指名されたユーザーは、リコンシリエーション・イベントの情報を、手動で分析およびリンクすることができます。分析やリンクを、定義したアクション・ルールに基づいてOracle Identity Managerが自動実行することもできます。そのルールは、イベントが既存のレコードに関連付けられているかどうか、新規アカウントを表しているかどうか、またはイベントの情報のリンクを手動で開始できるかどうかに基づいています。
ユーザーにより定義されるリコンシリエーション・クラスは、ターゲット・リソースおよび信頼できるソースを定期的にポーリングします。これらのシステムに関する変更はすべて、リコンシリエーション・マネージャに書き込まれたリコンシリエーション・イベントを生成します。Oracle Identity Managerは、関連するプロビジョニング・プロセスで定義されたマッピングに従ってイベント情報を分析します。
図5-6に「Reconciliation Manager」フォームを示します。
「Reconciliation Manager」フォームの機能は次のとおりです。
自動的にユーザーまたは組織に関連付けられた情報の場合は、それを確認できます。
自動的にユーザーに関連付けられた情報の場合は、それを確認できます。信頼できるソースの場合、イベントのデータは新規ユーザー・アカウントを作成するために使用されます。ターゲット・リソースの場合、イベントのデータは、関連するリソース固有のプロセス・フォームにデータを移入するために使用されます。
自動的に組織に関連付けられた情報の場合は、このフォームを使用して確認できます。
信頼できるソースの場合、ユーザーのOracle Identity Managerアカウントが削除され、ターゲット・リソースでそのユーザーに対するプロビジョニングの際に使用されたすべてのアカウントが失効します。
ターゲット・リソースの場合、Oracle Identity Managerは、そのシステム上のユーザー・アカウントが失効したことを認識します。
「Reconciliation Manager」フォームの上部には次の項目が含まれます。
次の手順は、リコンシリエーション・イベントを表示および管理する方法です。
リコンシリエーション・イベントを表示および管理するには、次の手順を実行します。
「Object Name」フィールドに関連付けられているリソースや、「Status」フィールドのステータスを基準にして、リコンシリエーション・イベントを問い合せることもできます。
問合せ対象が削除済イベントの場合、つまり、対応するレコードがターゲット・リソースまたは信頼できるソースから削除されている場合、「Delete Event」フラグに対して「Yes」オプションが選択されています。それ以外の場合は「No」オプションが選択されています。
各タブの情報については、「Reconciliation Manager」フォームのタブに関する項で説明します。Oracle Identity Managerが生成した一致を評価する際は、次のことができます。
この操作を実行するには、該当するタブの「Link」ボタンをクリックします。または、検出された一致が1つだけの場合にOracle Identity Managerが自動的にデータをリンクするようにルールを定義している場合もあります。
この操作を実行するには、「Create User」ボタンをクリックします。または、一致が検出されなかった場合に、Oracle Identity Managerが自動的にユーザーを作成するようにアクション・ルールを定義している場合もあります。
この操作を実行するには、「Create Organization」ボタンをクリックします。または、一致が検出されなかった場合に、Oracle Identity Managerが自動的に組織を作成するようにアクション・ルールを定義している場合もあります。
この操作を実行するには、適用できるリコンシリエーション・ルールの精度を上げ、保存してから、「Re-apply Matching Rules」ボタンをクリックします。
調べるリコンシリエーション・イベントが見つかったら、タブを使用して次の操作を実行できます。
このタブのデータは、「Processed Data」と「Unprocessed Data」の2つのブランチのいずれかの下に表示されます。
「Processed Data」ブランチのフィールドは、関連付けられているリソースの「Reconciliation Fields」タブ上で定義されます。リコンシリエーション・イベントで、これらのフィールドは正常に処理されています。たとえば、データ型要件に違反していません。正常に処理された各フィールドには、次の内容が表示されます。
処理済データ・フィールドは、たとえば次のように表示されます。
Location [String] = Newark
「Unprocessed Data」ブランチにリストされたフィールドは、処理できなかったリコンシリエーション・イベント項目です。これらはたとえば、定義されていない項目や、関連付けられているリソースの「Reconciliation Fields」タブで設定されているデータ型と矛盾する項目などです。各未処理フィールドについて、次の情報が表示されます。
未処理データ・フィールドは、たとえば次のように表示されます。
user_securityid = capital <Not Numeric>
リコンシリエーション・イベントの未処理フィールドを修正したり、該当するリソースで定義されるとおりに、関連フィールドにマップするには、次の手順を使用します。
未処理フィールドをマップまたは修正するには、次の手順を実行します。
複数値フィールドの場合、適切な子プロセス・フォームにマップするか、個別のコンポーネント・フィールドをチェックする必要があることがあります。
複数値フィールドの場合、コンポーネント・フィールドをダブルクリックして修正します。
「Edit Reconciliation Field Data」ダイアログ・ボックスが表示されます。
未処理フィールドの値を修正するには、正しい値を「Corrected Value」フィールドに入力し、「Save」をクリックして、「Edit Reconciliation Field Data」ダイアログ・ボックスを閉じます。
フィールドのデータが正常に処理されると、「Unprocessed Data」ブランチのエントリはリンク先のフィールドを反映して更新されます。そのフィールドの新しいエントリが、「Processed Data」ブランチに追加されます。
リコンシリエーション・イベントの必須データ要素（該当するリソース定義の「Object Reconciliation」タブ）に「Reconciliation Data」タブで処理済のマークが付けられると、Oracle Identity Managerには次のように表示されます。
該当するユーザーまたは組織に一致する、リソースに関連付けられているリコンシリエーション・ルールのロジックで指定されているリコンシリエーション・イベントの関連データに一致するすべてのユーザー・レコードまたは組織レコード。これらの候補は、ソース所有者の可能性のあるユーザーがユーザー一致ルールの適用に基づいてOracle Identity Managerに検出された（ユーザー更新）、信頼できるソース上のアカウントを表します。一致するユーザーが検出されなかった場合、リコンシリエーション・イベントは、信頼できるソースでの新規ユーザー・アカウントの作成（つまりユーザー作成）を表します。
すべてのキー・フィールドの値（該当するプロセス定義の「Reconciliation Field Mappings」タブで設定された値）がリコンシリエーション・イベントのすべてのキー・フィールドの値に一致するような、すべてのプロビジョニング・プロセス・フォーム・インスタンス。これは、一致している可能性があるアカウントがOracle Identity Managerに検出された（アカウント更新）ターゲット・システムのアカウントを表します。
これらの値に一致するプロセス・インスタンスがない場合、Oracle Identity Managerは該当するユーザーまたは組織に一致するリコンシリエーション・ルールを評価し、リコンシリエーション・イベントのデータと一致するユーザーまたは組織を表示します。これらの一致は、一致するアカウント・レコードが、リコンシリエーション・エンジンによりOracle Identity Managerに検出されなかったターゲット・システム上のアカウントを表しています。つまり、Oracle Identity Managerは、ユーザーに対してそのシステムのアカウントがプロビジョニングされていることを認識していないが、そのアカウントの所有者になる可能性のあるユーザーを検出しました（アカウント作成）。複数の一致候補が検出された場合は通常、レコードの調査と、Oracle Identity Managerアカウントのリンク先の決定を管理者に依頼します。一致が検出されない場合、信頼できるソースとターゲット・アプリケーションのデータに不一致があることがあります。このイベントは、ターゲット・システムのローグ・アカウントを示しているか、既存の従業員に対してターゲット・システム上で新規アカウントがプロビジョニングされたことを示している可能性があります。ただし、Oracle Identity Managerはそのアカウントがどのユーザーに関連付けられているか判断できません。
関連付けられているリソースの「Reconciliation Fields」タブで定義されているすべての必須フィールドの処理が完了すると、タブには、すべてのキー・フィールドの値がリコンシリエーション・イベントのすべてのキー・フィールドの値に一致するような、すべてのプロビジョニング・プロセス・フォーム・インスタンスが表示されます。
一致したプロビジョニング・プロセスには、次の内容が表示されます。
一致したプロビジョニング・プロセスは、たとえば次のように表示されます。
Windows2000_prov [445] for User=jdoe
このタブにリストされるプロビジョニング・プロセスがない場合、リコンシリエーション・イベントのキー・フィールドの値を、そのリソースに関連付けられたプロセス・フォーム・インスタンスのフィールドの値に一致させることができなかったことを意味します。この場合、Oracle Identity Managerは、リソースに対して定義されている、いずれかのユーザーまたは組織の一致ルールを適用するよう試みます。一致が検出されると、「Matched Users or Matched Organizations」タブに表示されます。
プロビジョニング・プロセス・インスタンスをリコンシリエーション・イベントにリンクするには、次の手順を実行します。
また、そのプロセスの「Reconciliation Update Received」タスクも挿入されます。
このタブには、リソースのリコンシリエーション・ルールの基準で指定されたとおりに、リコンシリエーション・イベントの関連データに一致するユーザー・レコードが表示されます。
信頼できるソースの場合、Oracle Identity Managerはこれらのルールを評価し、すべての必須フィールド（関連付けられているリソースの「Reconciliation Fields」タブで定義）の処理が完了すると、一致しているユーザー・レコードをすべて表示します。
ターゲット・リソースの場合、Oracle Identity Managerはルールを評価し、すべての必須フィールド（関連付けられているリソースの「Reconciliation Fields」タブで定義）が処理され、一致が「Processes Matched Tree」タブに生成されなかった場合にかぎり、一致しているユーザー・レコードをすべて表示します。
一致している各レコードについては、Design ConsoleはユーザーID、名および姓を表示します。
次の手順は、リコンシリエーション・イベントにユーザー・レコードをリンクする方法を説明しています。
リコンシリエーション・イベントにユーザー・レコードをリンクするには、次の手順を実行します。
「Link」をクリックして、リコンシリエーション・イベントの対象が信頼できるソースである場合、Oracle Identity Managerは次の操作を実行します。
このタブには、リソースのリコンシリエーション・ルールで指定されたとおりに、リコンシリエーション・イベントのデータに一致するOracle Identity Manager組織レコードが表示されます。
信頼できるソースの場合、Oracle Identity Managerはこれらのルールを評価し、すべての必須フィールド（関連付けられているリソースの「Reconciliation Fields」タブで定義）の処理が完了すると、一致している組織レコードをすべて表示します。
ターゲット・リソースの場合、Oracle Identity Managerはルールを評価し、すべての必須フィールド（関連付けられているリソースの「Reconciliation Fields」タブで定義）が処理され、一致が「Processes Matched Tree」タブに生成されなかった場合にかぎり、一致している組織レコードをすべて表示します。
一致している各レコードについては、Oracle Identity ManagerはユーザーID、名および姓を表示します。
次の手順は、リコンシリエーション・イベントに組織レコードをリンクする方法を説明しています。
リコンシリエーション・イベントに組織レコードをリンクするには、次の手順を実行します。
リコンシリエーション・イベントの対象が信頼できるソースである場合、Oracle Identity Managerは次の操作を実行します。
このタブには、このリコンシリエーション・イベントで実行されたアクションの履歴が表示されます。各アクションについて、アクションが実行された日付と時刻がリストされます。Oracle Identity Managerにより、次のリコンシリエーション・イベント・アクションが追跡および記録されます。
|
 Copyright © 1991, 2007 Oracle Corporation. All Rights Reserved. |
|