リリース9.1.0.1
B53898-01
 目次 |
 索引 |
| Oracle Identity Manager デザイン・コンソール・ガイド リリース9.1.0.1 B53898-01 |
|
この章では、Design Consoleのリソース管理について説明します。内容は次のとおりです。
「Resource Management」フォルダには、Oracle Identity Managerのリソースを管理するツールがあります。このフォルダには次のフォームがあります。
「IT Resources Type Definition」フォームは「Resource Management」フォルダにあります。「IT Resources Type Definition」フォームは、ITリソース・タイプ（たとえば、AD、Microsoft Exchange、Solaris）を分類するために使用します。Oracle Identity Managerは、ユーザーと組織に対してプロビジョニングされるリソース・オブジェクトにリソース・タイプを関連付けます。
このフォームで定義されたITリソース・タイプは、リソースを定義する際に選択できます。タイプは「IT Resources」フォームの「Type」フィールドに表示されます。
ITリソース・タイプは、それを参照するITリソース定義のテンプレートです。ITリソース定義がITリソース・タイプを参照する場合、リソースはITリソース・タイプのパラメータと値をすべて継承します。ITリソース・タイプは、一般的なITの分類です（たとえば、Solaris）。リソースは、このタイプのインスタンス（たとえば、Solaris for Statewide Investments）となります。
すべてのITリソース定義をITリソース・タイプに関連付ける必要があります。
図5-1に、「IT Resources Type Definition」フォームを示します。
表5-1に、「IT Resources Type Definition」フォームのフィールドの説明を示します。
| フィールド名 | 説明 |
|---|---|
|
Server Type |
ITリソース・タイプの名前。 |
|
Insert Multiple |
このITリソース・タイプを複数のITリソースによって参照できるかどうかを指定します。 |
ITリソース・タイプを定義するには、次の手順を実行します。
ITリソース・タイプが定義されました。これは、「IT Resources」フォームでITリソースを定義するときに、「Type」フィールドから選択できます。
新規ITリソース・タイプの基本情報を保存すると、問合せでITリソース・タイプが返されたとき、「IT Resources Type Definition」フォーム下方の領域のタブにあるフィールドが有効になります。
「IT Resources Type Definition」フォームには次のタブがあります。
図5-1に示すように、「IT Resource Type Parameter」タブは、そのITリソース・タイプのすべての接続パラメータにデフォルト値と暗号化設定を指定するために使用します。パスワードおよび暗号化されたフィールドにはデフォルト値を指定しないことをお薦めします。このタブのパラメータと値は、このITリソース・タイプを参照するすべてのITリソースによって継承されます。
新規パラメータを定義する場合、パラメータとその値、および暗号化設定が、現在のITリソース・タイプ、およびこのITリソース・タイプを参照する新規または既存のITリソース定義に追加されます。新規パラメータは、該当するリソース定義で、「IT Resources」フォームの「Parameters」タブに表示されます。
ITリソース・タイプにパラメータを追加するには、次の手順を実行します。
新しい行が「IT Resource Type Parameter」タブに表示されます。
この値は、このITリソース・タイプを参照するすべてのITリソースによって継承されます。
このチェック・ボックスでは、このパラメータの値をマスクして、フォーム・フィールドにアスタリスク（*）で表示するかどうかを指定します。
パラメータの値をマスクするには、このチェック・ボックスを選択します。
ITリソース・タイプからパラメータを削除するには、次の手順を実行します。
このタブには、選択されたITリソース・タイプを参照するITリソースが表示されます。このタブのすべてのITリソースは同一のパラメータを共有しますが、値は各ITリソースで一意であるようにできます。
「IT Resource Type Definition」表には、次の情報が表示されます。
| フィールド名 | 説明 |
|---|---|
|
Server Type |
「IT Resource Type Definition」フォームで定義された、リソース・アセット・タイプの名前。 |
|
Insert Multiple |
このITリソース定義のインスタンスを複数作成できるかどうかを指定します。 |
「IT Resources」フォームは「Resource Management」フォルダにあります。このフォームは、ITリソースを設定するために使用します。通常、ITリソース定義は、1つ以上のリソースが存在するサーバーやコンピュータなどのハードウェアを表します。各ITリソース定義がITリソース・タイプのインスタンスを表します。
プロビジョニング・イベントでは、リソース・オブジェクトがITリソース定義を参照します。その定義は、リソースがある場所と接続方法を指定しています。リソース・オブジェクトは、ITリソース定義に関連付けられる必要があります。
Oracle Identity Managerアダプタの変数は、ITリソースの任意のパラメータの値にマップできます。パラメータは、たとえば、サーバー・ドメイン名やITリソースにアクセスするユーザーのIDなど、ハードウェアに関する情報を表します。
表5-2に、「IT Resources」フォームのフィールドの説明を示します。
| フィールド名 | 説明 |
|---|---|
|
Name |
ITリソースの名前。 |
|
Type |
「IT Resources Type Definition」フォームで定義された、ITリソースの分類タイプ。 |
|
Remote Manager |
リモート・マネージャを使用してITリソースにアクセスできる場合は、このフィールドにリモート・マネージャの名前が表示されます。そうでない場合は、このフィールドは空です。 |
ITリソースを定義するには、次の手順を実行します。
「IT Resource Type definition」フォームを使用してITリソース・タイプを定義します。
リモート・マネージャを使用してITリソースにアクセスしない場合は、手順6に進みます。
保存されたITリソースは、関連付けられているITリソース・タイプ用の「IT Resources Type Definition」フォームの「IT Resource」タブに表示されます。ITリソース分類タイプのパラメータとデフォルト値は「Parameters」タブに表示されます。
「Administrators」タブで、管理グループのアクセス権限およびITリソースAPIのセキュリティ・レベルを指定します。
アクセス権限を設定するには、次の手順を実行します。
デフォルトで、このITリソース・インスタンスに関連付けられている管理グループが表示されます。
たとえば、「ramone」ITリソース・インスタンスの管理グループとして「G2」を割り当てることができます。
| 権限 | 説明 |
|---|---|
|
Read |
選択すると、「Group Name」に指定された管理グループは、現在のITリソース・インスタンスの読取りが可能になります。 |
|
Write |
選択すると、該当するグループ名は、現在のITリソース・インスタンスのパラメータ値の読取りおよび変更が可能になります。 |
|
Delete |
選択すると、関連付けられた管理グループは、現在のITリソース・インスタンスを削除できます。 |
ルールとは、Oracle Identity Managerで条件を一致させたり、それに基づいて対処することを可能にする基準です。特定のリソース・オブジェクトまたはプロセスにルールを割り当てることも、すべてのリソース・オブジェクトまたはプロセスにルールを適用することもできます。
ルールの使用方法の例を次に示します。
図5-2に示す「Rule Designer」フォームは「Resource Management」フォルダにあります。このフォームは、リソースとともに使用されるルールを作成および管理するために使用します。
ルールには4つのタイプがあります。
General: Oracle Identity Managerが自動的にユーザー・グループにユーザーを追加したり、リソース・オブジェクトに割り当てるパスワード・ポリシーを決定したりできるようにします。
Process Determination: リクエストの承認プロセスや、リソース・オブジェクトの承認およびプロビジョニング・プロセスを決定します。
Task Assignment: ユーザーまたはプロセス・タスクに割り当てられるユーザー・グループを指定します。
Prepopulate: フォーム・フィールドに対して実行される事前移入アダプタを決定します。
ルールには次の項目が含まれます。
ルール要素: 属性、演算子および値で構成されています。図5-2では、属性はUser Login、演算子は==、値はXELSYSADMです。
ネストされたルール: ロジック上の理由で、1つのルールを別のルールの内部に配置する必要がある場合、内部ルールはネストされたルールと呼ばれます。図5-2では、Rule to Prevent Solaris AccessがRule for Solaris内にネストされています。
演算: ルールに複数のルール要素またはネストされたルールが含まれる場合、演算がコンポーネント間の関係を示します。図5-2では、AND演算を選択した場合、ルールに適合するには、User Login==XELSYSADMルール要素と、ネストされたルールRule to Prevent Solaris Accessの両方がtrueになる必要があります。
表5-3に、「Rule Designer」フォームのフィールドの説明を示します。
| フィールド名 | 説明 |
|---|---|
|
Name |
ルールの名前。 |
|
AND/OR |
外部ルール要素およびネストされたルールがすべてtrueの場合にのみルールに適合すると規定するには、「AND」オプションを選択します。いずれかの外部ルール要素またはネストされたルールがTRUEであれば適合すると規定するには、「OR」オプションを選択します。
重要: これらのオプションは、ネストされたルールの中に含まれるルール要素の演算を反映しません。図5-2では、AND演算は |
|
Type |
ルールの分類ステータス。ルールは4つのタイプのいずれかに属することができます。 |
|
Sub-Type |
タイプがProcess Determination、Task AssignmentまたはPrepopulateのルールは、4つのサブタイプのいずれかに分類できます。
ルール・タイプが「Task Assignment」または「Prepopulate」の場合、「Approval」と「Standard Approval」項目は「Sub-Type」ボックスに表示されません。ルール・タイプが「General」の場合、「Sub-Type」ボックスはグレー表示されます。 |
|
Object |
このルールが割り当てられるリソース・オブジェクト。 |
|
All Objects |
選択すると、ルールをすべてのリソース・オブジェクトに割り当てることができます。 |
|
Process |
このルールが割り当てられるプロセス。 |
|
All Processes |
選択すると、ルールをすべてのプロセスに割り当てることができます。 |
|
Description |
ルールについての説明。 |
ルールを作成するには、次の手順を実行します。
|
注意:
次の手順で、ネストされたルール内部のルール要素にはオプションが適用されないことに注意してください。たとえば、図5-2のAND演算は |
いずれかのルール要素またはネストされたルールがtrueであれば適合すると規定するには、「OR」オプションを選択します。
Process Determinationの場合は、「Sub-Type」をクリックして、ルールに関連付ける分類ステータス（「Organization Provisioning」、「User Provisioning」、「Approval」または「Standard Approval」）を選択します。
Task AssignmentまたはPrepopulateの場合は、「Sub-Type」をクリックして、ルールに関連付ける分類ステータス（「Organization Provisioning」または「User Provisioning」）を選択します。
「Type」ボックスから「General」を選択した場合は、手順7に進みます。
ルールをすべてのリソース・オブジェクトに使用できるようにする場合は、「All Objects」オプションを選択します。
ルールをすべてのプロセスに使用できるようにする場合は、「All Processes」オプションを選択します。
|
注意: 「All Processes」オプションを選択して、手順5で1つのリソース・オブジェクトを選択した場合、このルールは、選択したリソース・オブジェクトに関連付けられたすべてのプロセスに使用できます。 |
「Rule Designer」フォームには、次のタブが含まれます。
それぞれのタブについて、次の各項で説明します。
このタブからは、ルールの要素やネストされたルールを作成および管理できます。たとえば、図5-3では、Rule for SolarisにUser Login==XELSYSADMルール要素が含まれています。また、Rule to Prevent Solaris Accessがネストされています。図5-3に、「Rule Designer」フォームの「Rule Elements」タブを示します。
図5-3のルールは、Solarisリソース・オブジェクトのプロビジョニング・プロセスに適用できます。このリソース・オブジェクトがリクエストに割り当てられると、ルールがトリガーされます。ターゲット・ユーザーのログインがXELSYSADMで、リソース・オブジェクトの名前がSolarisの場合、Solarisリソース・オブジェクトはユーザーに対してプロビジョニングされています。そうでない場合、ユーザーはSolarisにアクセスできません。
ルール要素またはネストされたルールが有効でなくなったら、ルールから削除します。
その手順を次に示します。
ルールにルール要素を追加するには、次の手順を実行します。
「Edit Rule Element」ダイアログ・ボックスが表示されます。
「Edit Rule Element」ダイアログ・ボックス上のボックスにあるカスタム・メニューは、「Rule Designer」フォームの「Type」ボックスと「Sub-Type」ボックスにある項目に対応しています。
表5-4に、「Edit Rule Element」ダイアログ・ボックスのデータ・フィールドの説明を示します。
この例では、ターゲット・ユーザーのログインIDがXELSYSADMであれば、ルール要素はtrueになります。それ以外の場合はfalseです。
ルール要素が「Rule Designer」フォームの「Rule Elements」タブに表示されます。
ルール要素がルールに追加されます。
ルールの中にルールをネストするには、次のようにします。
「Select Rule」ダイアログ・ボックスが表示されます。
ネストされたルールが「Rule Designer」フォームの「Rule Elements」タブに表示されます。
ネストされたルールがルールに追加されます。
ルール要素またはネストされたルールを削除するには、次の手順を実行します。
このタブは「Rule Designer」フォームに表示されます。「Usage」タブの情報は、ルールの分類タイプを反映しています。たとえば、ルール・タイプが事前移入の場合、このルールが適用される、ユーザーが作成したフィールドが、このタブに表示されます。
図5-5に「Usage」タブを示します。
このタブには次の項目が表示されます。
このコードはプロセス決定ルールでのみ表示されます。
図5-5のRule to Approve Solaris定義は、The Solaris Resource ObjectとProcess to Approve Solarisに割り当てられています。これは承認ルールなので、分類タイプはAです。このルールの優先順位は1で、対応するリソース・オブジェクトがリクエストに割り当てられた後、Oracle Identity Managerによって評価される最初の承認ルールであることを示しています。
図5-6に示す「Rule Designer」表には、「Rule Designer」フォームで定義されている使用可能なすべてのルールが表示されます。
表5-5に、「Rule Designer」表に表示される情報を示します。
「Resource Objects」フォームは「Resource Management」フォルダにあります。このフォームは、組織またはユーザーに対してプロビジョニングするOracle Identity Managerリソースのリソース・オブジェクトを作成および管理するために使用します。リソース・オブジェクトの定義は、リソース・プロビジョニングのテンプレートです。ただし、リソースの承認およびプロビジョニングは、リソース・オブジェクトにリンクする承認およびプロビジョニング・プロセスの設計により異なります。
表5-6に、「Resource Objects」フォームのデータ・フィールドの説明を示します。
リソース・オブジェクトを作成するには、次の手順を実行します。
組織のリソース・オブジェクトをリクエストするには、「Order For Organization」を選択します。
このフォームのフィールドに（ツールバーの「Pre-Populate」ボタンをクリックして）手動でデータを移入する場合は、「Auto Pre-Populate」オプションの選択を解除します。
「Lookup」ダイアログ・ボックスが表示されたら、リソース・オブジェクトに関連付ける分類ステータス（「Application」、「Generic」または「System」）を選択します。
それ以外の場合は手順9に進みます。
リソース・オブジェクトが作成されます。
「Resource Objects」フォームを起動してリソース・オブジェクトを作成すると、このフォームのタブが使用可能になります。
「Resource Objects」フォームには、次のタブが含まれます。
このタブから、Oracle Identity Managerが、現在のリソース・オブジェクトをプロビジョニングする前にプロビジョニングする必要があるリソース・オブジェクトを選択できます。「Depends On」タブに表示されているリソース・オブジェクトを先にプロビジョニングせずに現在のリソース・オブジェクトをプロビジョニングできる場合、タブからそのリソース・オブジェクトを削除する必要があります。
「Depends On」タブに関連するトピックには次のものがあります。
依存しているリソース・オブジェクトを選択するには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
依存しているリソース・オブジェクトが選択されます。
依存しているリソース・オブジェクトを削除するには、次の手順を実行します。
このタブでは、このリソースのオブジェクト認可ユーザー・グループを指定します。タスク割当てのターゲットとして、「Object Authorizers」グループのメンバーであるユーザーを選択できます。
「Object Authorizers」タブ上の各ユーザー・グループには優先順位番号があります。割当てのターゲットがObject Authorizer user with highest priorityの場合、Oracle Identity Managerは優先順位番号を使用して、タスクに割り当てるユーザーを決定します。優先順位番号は、グループに割り当てられたタスクが対応されずにエスカレーションの対象になる場合にも、参照されることがあります。このタブでは、どのユーザー・グループの優先順位番号も変更できます。
たとえば、SYSTEM ADMINISTRATORSユーザー・グループのメンバーを、オブジェクト認可ユーザーに設定する場合を考えます。また、このリソース・オブジェクトに関連付けられているプロセス・タスクにタスク割当てルールがアタッチされており、割当て基準がObject Authorizer User with Highest Priorityであるとします。このプロセス・タスクを完了する権限がある最初のユーザーは、優先順位番号が1なので、SYSTEM ADMINISTRATORSユーザー・グループに所属する中で最も優先順位が高いユーザーです。ユーザーによって指定された時間内にユーザーがプロセス・タスクを完了しなかった場合、Oracle Identity ManagerはSYSTEM ADMINISTRATORSユーザー・グループで次に優先順位が高いユーザーにタスクを再割当てします。
ユーザー・グループをリソース・オブジェクトに割り当てるには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
ユーザー・グループが選択されます。
リソース・オブジェクトからユーザー・グループを削除するには、次の手順を実行します。
ユーザー・グループの優先順位番号を変更するには、次の手順を実行します。
選択したユーザー・グループの優先順位番号を1つ下げるには、「Decrease」をクリックします。
ユーザー・グループの優先順位番号を、より大きく増減するには、該当するボタンを繰り返しクリックします。たとえば、ユーザー・グループの優先順位番号を2つ上げるには、「Increase」ボタンを2度クリックします。
ユーザー・グループの優先順位番号が、選択した値に変更されます。
リクエストは、ユーザーまたは組織にリソースをプロビジョニングするメカニズムです。ユーザーは、ターゲットのユーザーまたは組織へのリソースのプロビジョニングを承認するリクエストを操作します。各リクエストは、リソース・オブジェクトを割り当てられる必要があります。各リソース・オブジェクトは、1つ以上のプロビジョニング・プロセスと、1つ以上の承認プロセスから構成されます。
リソース・オブジェクトは、ユーザーまたは組織にリソースをプロビジョニングする際のテンプレートです。このテンプレートは、複数の承認プロセスやプロビジョニング・プロセスにリンクできます。リソースがリクエストまたは直接プロビジョニングされると、Oracle Identity Managerはプロセス決定ルールを使用して承認プロセスとプロビジョニング・プロセスを選択します。
プロセス決定ルールには、次の基準があります。
承認プロセスおよびプロビジョニング・プロセスには、プロセス決定ルールがあります。ルールおよびプロセスの組合せには、それぞれ優先順位番号があり、Oracle Identity Managerが評価する順序を表します。
ルールの条件がfalseの場合、Oracle Identity Managerは次に高い優先順位を持つルールを評価します。ルールがtrueの場合、Oracle Identity Managerはそれに関連付けられているプロセスを実行します。たとえば、リソースがリクエストまたは直接プロビジョニングされると、Oracle Identity ManagerはRule to See if Solaris is NeededおよびRule to Check Provisioning of Solaris for IT Deptを評価します。どちらのルールも、最も高い優先順位を持っています。これらのルールの条件がtrueになると、Oracle Identity Managerはそれらに関連付けられたプロセス（この例では、「Check if Solaris is Needed」承認プロセスと、「Provision Solaris for IT Dept」プロビジョニング・プロセス）を実行します。
この例の変形として、リソースがリクエストまたは直接プロビジョニングされ、「Rule to Check Provisioning of Solaris for IT Dept.」ルールがfalseの場合、Oracle Identity Managerは「Rule to Check Provisioning of Solaris for Developers」ルールを評価します。このルールがtrueの場合、Oracle Identity Managerは、そのルールに関連付けられている「Provision Solaris for Devel.」プロビジョニング・プロセスを実行します。
リソース・オブジェクトにプロセス決定ルールを追加するには、次の手順を実行します。
これにより、Oracle Identity Managerがルールとプロセスの組合せを評価する順序が決定されます。
ルールとプロセスの組合せがリソース・オブジェクトに追加されます。
リソース・オブジェクトからプロセス決定ルールを削除するには、次の手順を実行します。
リソース・オブジェクトのプロビジョニング・プロセスに、自動的に完了する必要があるタスクが含まれます。この場合、リソース・オブジェクトにイベント・ハンドラまたはアダプタを割り当てる必要があります。イベント・ハンドラは、この特殊な情報を処理するソフトウェア・ルーチンです。アダプタはJavaコードを生成する特殊なタイプのイベント・ハンドラであり、アダプタにより、Oracle Identity Managerの通信および外部リソースとの対話が可能になります。
イベント・ハンドラまたはリソース・オブジェクトに割り当てられたアダプタが有効でなくなったら、リソース・オブジェクトから削除する必要があります。
この例では、adpAUTOMATEPROVISIONINGPROCESSアダプタがSolarisリソース・オブジェクトに割り当てられました。このリソース・オブジェクトがリクエストに割り当てられると、Oracle Identity Managerによりアダプタがトリガーされ、関連付けられたプロビジョニング・プロセスが自動的に実行されます。
イベント・ハンドラをアダプタまたはリソース・オブジェクトに割り当てるには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
イベント・ハンドラがリソース・オブジェクトに割り当てられます。
リソース・オブジェクトからイベント・ハンドラまたはアダプタを削除するには、次の手順を実行します。
Design Consoleの「Resource Objects」フォームが拡張されて、Resource Audit Objectivesという新しいリソース属性が含まれるようになりました。このリソース属性を使用すると、リソースをリンクして委任を管理することが簡単にできます。
Resource Audit Objectivesリソース属性の値のために新しい参照が定義されます。「Resource Audit Objectives」リストに事前に定義されている値は、次のとおりです。
このリストは、Design Consoleの「Lookup Definition」フォームを使用してLookups.Resource Audit Objective.Type参照を編集すると拡張できます。
Design Consoleの「Resource Profile」フォームにある新しい「Resource Audit Objectives」タブを使用して、この属性の値を選択できます。
このタブは、リソース・オブジェクトのプロビジョニング・ステータスを設定するために使用します。プロビジョニング・ステータスは、リソース・オブジェクトがターゲット・ユーザーまたは組織にプロビジョニングされるまで、リソース・オブジェクトのライフ・サイクルを通じてステータスを示します。「Currently Provisioned」タブの「Status」領域から、リソース・オブジェクトのプロビジョニング・ステータスを表示できます。
リソース・オブジェクトのプロビジョニング・ステータスはすべて、関連するプロビジョニング・プロセスのタスク・ステータスに関連付けられます。Oracle Identity Managerは、リソース・オブジェクトがリクエストに割り当てられるときに、プロビジョニング・プロセスを選択します。たとえば、Provision for Developersプロセスが選択され、このプロセスのステータスが「Completed」になると、対応するリソース・オブジェクトのステータスが「Provisioned」に設定されます。こうして、リソース・オブジェクトとプロビジョニング・プロセスの関連を、素早く簡単に確認できます。
リソース・オブジェクトには、次の事前定義済のステータスがあります。
リソースがリクエストに割り当てられ、リソース・オブジェクトのステータスが「Ready」になると、Oracle Access Managerは、プロセス決定ルールを評価して承認プロセスとプロビジョニング・プロセスを決定します。これが実行されると、リソース・オブジェクトのステータスは「Provisioning」に変更されます。
それぞれのプロビジョニング・ステータスには、対応する「Launch Dependent」チェック・ボックスがあります。チェック・ボックスが選択され、リソース・オブジェクトがそのプロビジョニング・ステータスになると、Oracle Identity Managerにより、依存するリソース・オブジェクトが独自のプロビジョニング・プロセスを起動できるようになります。
たとえば、「Exchange」リソース・オブジェクトでは、「Provisioned」および「Enabled」プロビジョニング・ステータスに対応する「Launch Dependent」チェック・ボックスが選択されています。このリソース・オブジェクトのプロビジョニング・ステータスが「Provisioned」および「Enabled」に変更されると、Oracle Identity Managerは、「Exchange」リソース・オブジェクトがさらに別のリソース・オブジェクトに依存しているかどうかを確認します。他の依存オブジェクトがある場合、Oracle Identity Managerは、それらの承認プロセスとプロビジョニング・プロセスを起動します。続いて、「Exchange」の承認およびプロビジョニング・プロセスを選択します。
プロビジョニング・プロセスの各種のタスク・ステータスを反映するには、追加のプロビジョニング・ステータスをリソース・オブジェクトに追加する方法があります。たとえば、あるプロビジョニング・プロセスに所属するタスクのステータスが「Rejected」のとき、リソース・オブジェクトの対応するプロビジョニング・ステータスを「Revoked」に設定することもできます。
同様に、既存のプロビジョニング・ステータスが有効でなくなった場合は、リソース・オブジェクトからそのステータスを削除する必要があります。
次の項では、リソース・オブジェクトにプロビジョニング・ステータスを追加する方法と、リソース・オブジェクトからプロビジョニング・ステータスを削除する方法を説明します。
リソース・オブジェクトにプロビジョニング・ステータスを追加するには、次の手順を実行します。
プロビジョニング・ステータスがリソース・オブジェクトに割り当てられます。
次の手順では、リソース・オブジェクトからプロビジョニング・ステータスを削除する方法について説明します。
このタブは、現在のリソース・オブジェクトを表示、変更および削除できるユーザー・グループを選択するために使用されます。
「Write」チェック・ボックスを選択すると、それに対応するユーザー・グループが現在のリソース・オブジェクトを変更できます。「Delete」チェック・ボックスを選択すると、関連付けられているユーザー・グループが現在のリソース・オブジェクトを削除できます。
たとえば、SYSTEM ADMINISTRATORSユーザー・グループは、Solarisリソース・オブジェクトを表示、変更および削除できます。OPERATORSユーザー・グループは、このリソース・オブジェクトの表示および変更のみを行えます（「Delete」チェック・ボックスは選択解除されています）。
次の項では、リソース・オブジェクトにユーザー・グループを割り当てる方法と、リソース・オブジェクトからユーザー・グループを削除する方法を説明します。
ユーザー・グループをリソース・オブジェクトに割り当てるには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
ユーザー・グループが「Administrators」タブに表示されます。このグループのすべてのメンバーは、デフォルトで、アクティブなレコードを表示できます。
それ以外の場合は手順5に進みます。
それ以外の場合は手順6に進みます。
ユーザー・グループがリソース・オブジェクトに割り当てられます。
リソース・オブジェクトからユーザー・グループを削除するには、次の手順を実行します。
タイプがApplicationのリソース・オブジェクトをユーザーまたは組織に対してプロビジョニングする場合は、そのユーザーまたは組織がパスワード条件を満たしていることを確認してから、リソース・オブジェクトにアクセスできるようにします。このパスワード条件は、パスワード・ポリシーのフォームで作成および管理されます。このポリシーは「Password Policies」フォームを使用して作成されます。
リソース・オブジェクト定義は、リソースのプロビジョニング方法を管理する単なるテンプレートであるため、Oracle Identity Managerは、実際の条件およびルールに基づいてリソースをどのようにプロビジョニングするかを決定できる必要があります。これらの条件は、リソースが実際にリクエストされるまで明らかではありません。このため、リソースに関連付けられている様々なプロセスやパスワード・ポリシーにルールをリンクする必要があります。これにより、Oracle Identity Managerはいかなる状況でも起動対象を決定できるようになります。
Oracle Identity Managerは、特定のユーザーのアカウントを作成または更新する際に、リソースに適用するパスワード・ポリシーを決定します。この決定は、リソースのパスワード・ポリシー・ルールを評価し、適合した最初のルールに関連付けられているポリシーの基準を適用することによって行われます。ルールには優先順位番号があり、Oracle Identity Managerが評価する順序を表します。
この例では、Oracle Identity Managerは「Rule to Prevent Solaris Access」ルールをトリガーします（優先順位が最も高いため）。このルールがTRUEであれば、Oracle Identity Managerは「Restrict Solaris」パスワード・ポリシーの基準を、作成または更新されるアカウントのパスワードに適用します。
このルールがfalseなら、Oracle Identity Managerは、次に高い優先順位を使用してルールを評価します。このルールがtrueの場合、Oracle Identity Managerはそのルールに関連付けられているパスワード・ポリシーを、作成または更新されたアカウントのパスワードに適用します。
次の各項では、リソース・オブジェクトに対してパスワード・ポリシー・ルールを追加および削除する方法について説明します。
パスワード・ポリシー・ルールをリソース・オブジェクトに追加するには、次の手順を実行します。
このフィールドには、ルールの優先順位番号が含まれます。
パスワード・ポリシー・ルールがリソース・オブジェクトに追加されます。
リソース・オブジェクトからパスワード・ポリシーを削除するには、次の手順を実行します。
このタブは、「Resource Objects」フォームで作成されたユーザー定義フィールドを表示およびアクセスするために使用します。作成されたユーザー定義フィールドはこのタブに表示され、データを入出力することができます。
|
関連項目
既存のOracle Identity Managerフォームでユーザー定義フィールドを作成する方法の詳細は、「「User Defined Field Definition」フォーム」を参照してください。 |
「Process」タブには、現在のリソース・オブジェクトに関連付けられているすべての承認およびプロビジョニング・プロセスが表示されます。このタブにある「Default」チェック・ボックスは、どの承認プロセスまたはプロビジョニング・プロセスがリソースのデフォルトであるかを示します。
たとえば、Solarisリソース・オブジェクトに1つの承認プロセスと1つのプロビジョニング・プロセス（Provision Solaris for Devel.）が関連付けられている場合を考えます。Provision Solaris for Devel.は、このリソース・オブジェクトのデフォルトのプロビジョニング・プロセスに指定されています。
「Object Reconciliation」タブの「Object Initial Reconciliation Date」フィールドに、リソースに対して最初のリコンシリエーションが実行された日付が表示されます。
「Object Initial Reconciliation Date」フィールドに格納された日付値は、最初のリコンシリエーションと後続のリコンシリエーション・イベントを区別するために使用されます。この日付値は、リリース9.1.0で導入された2つの例外レポートで使用されます。これらの例外レポートには、ユーザーが実際にターゲット・システムで保持しているものと比較して、保持する必要がある権限における差異が表示されます。権限における差異は、リコンシリエーション・データとともに他のデータ項目を使用して特定されます。例外レポートは、「Object Initial Reconciliation Date」フィールドに格納された日付より後に作成されたリコンシリエーション・イベントにのみ関連付けられたデータを返します。また、例外データは、「Object Initial Reconciliation Date」フィールドに過去の日付値が表示されている場合にのみ生成されます。必要に応じて、例外レポートが生成されるようにこのフィールドに日付値を入力できます。
「Object Reconciliation」タブには、「Reconciliation Fields」と「Reconciliation Action Rules」の2つのサブタブがあります。
このタブは、Oracle Identity Managerの情報とリコンサイルされる（マッピングなど）ターゲット・リソースまたは信頼できるソース上のフィールドを定義するために使用されます。ターゲット・システムまたは信頼できるソースの各フィールドには、次の情報がリストされます。
次にターゲット・システム・フィールド定義の例を示します。
TargetField1 [String], Required
「Reconciliation Fields」タブでは、次の操作を実行できます。
次の手順を実行すると、ターゲット・システムまたは信頼できるソースから、Oracle Identity Managerの情報とリコンサイルされるフィールドのリストに、フィールドが追加されます。信頼できるソースの場合、これはユーザー・リソース定義である必要があります。
リコンシリエーション・フィールドを追加するには、次の手順を実行します。
「Add Reconciliation Field」ダイアログ・ボックスが表示されます。
これは、Oracle Identity Managerでターゲット・リソースまたは信頼できるソースのフィールドを参照する名前です。
このチェック・ボックスを選択した場合は、リコンシリエーション・フィールドが「Reconciliation Manager」フォームの「Reconciliation Data」タブで処理されていないと、Oracle Identity Managerは、プロビジョニング・プロセス、ユーザーまたは組織をリコンシリエーション・イベントに一致させる作業を開始できません。このチェック・ボックスの選択を解除した場合、リコンシリエーション・イベントでこのフィールドを処理できなくても、一致作業は開始されます。
フィールドは、リソースのデフォルトのプロビジョニング・プロセスでのマッピングに使用できます。
次の手順を実行すると、ターゲットのシステム・フィールドが、Oracle Identity Managerの情報とリコンサイルされたフィールドのリストから削除されます。信頼できるソースの場合、これはユーザー・リソース定義である必要があります。
リコンシリエーション・フィールドを削除するには、次の手順を実行します。
このタブを使用すると、リコンシリエーション・イベント・レコード内に複数の一致があるときに、Oracle Identity Managerが実行するアクションを指定できます。このタブの各レコードは次の組合せです。
選択する条件とアクションは事前に定義されています。一致条件によっては適用できないアクションもあります。表5-7に、使用できるオプションの詳細なリストを示します。
リコンシリエーション・アクション・ルールの追加
リコンシリエーション・アクション・ルールを追加するには、次の手順を実行します。
「Add a new Action Rule」ダイアログ・ボックスが表示されます。
これは、関連付けられた処理が実行されるようにする一致条件です。各一致条件は、1つのルール・アクションにのみ割り当てることができます。
これは、一致条件が満たされたときに実行されるアクションです。
リコンシリエーション・アクション・ルールの削除
リコンシリエーション・アクション・ルールを削除するには、次の手順を実行します。
リコンシリエーション・アクション・ルールが削除され、条件に関連付けられているアクションが自動的に実行されなくなります。
以前のリリースでは、アイデンティティをリコンサイルするために信頼できるソースとして設定できるのは、Xellerate Userリソース・オブジェクトのみでした。現在では、Xellerate Userリソース・オブジェクトおよびプロセス定義に対して、リコンシリエーション・フィールド、リコンシリエーション・アクション・ルール、フィールド・マッピングおよび一致ロールを作成することで、これを達成できるようになりました。
アイデンティティをリコンサイルしてOIMユーザーを作成するための元となる信頼できるソースが2つある場合は、両方の信頼できるソースに対して単一のリソース・オブジェクト（Xellerate User）を構成することはできません。両方の信頼できるソースに対してリコンシリエーション・フィールドをXellerate Userリソース・オブジェクトに作成したとしても、対応するリコンシリエーション・フィールド・マッピングをXellerate Userプロセス定義に作成することはできません。
リリース9.1.0からは、Xellerate User以外のリソース・オブジェクトを、アイデンティティのリコンシリエーション用の信頼できるソースとして構成できます。この構成を行うには、リソース・オブジェクトを作成する際に「Resource Objects」フォームの「Trusted Source」チェック・ボックスを選択します。
Trusted Sourceフラグがアタッチされたリソース・オブジェクトには、ターゲット・システム・フィールドを示すリコンシリエーション・フィールドを複数作成できます。また、リコンシリエーション・アクション・ルールを構成して、プロセス一致が検出されない場合に、アイデンティティ作成のためにユーザーを作成したり、管理者または認可者にデータを送信したりすることもできます。プロセス一致が検出された場合は、リンクが確立されます。
信頼できるソースのリソースに対するプロビジョニング・プロセスを定義する場合は、ユーザー定義フォームをアタッチしないでください。このようなプロビジョニング・プロセスでは、リソースに定義されたリコンシリエーション・フィールドとOIMユーザーの属性の間にリコンシリエーション・フィールド・マッピングを作成できます。
このリリースにおけるもう1つの追加機能は、属性を信頼できるソースです。これは、アイデンティティそのものではなく、アイデンティティの属性に対してのみ信頼できるソースを意味します。属性を信頼できるソースのリコンシリエーションは、適切なリコンシリエーション・アクション・ルールを作成することで構成できます。プロセス一致が検出されない場合は、管理者に割り当てられます。これにより、一致が検出されなくても、ユーザーが誤って作成されません。プロセス一致が検出された場合は、リコンシリエーション・アクション・ルールによってリンクが確立されます。
次の各項では、複数の信頼できるソースのリコンシリエーションを実装できる2つの使用例について説明します。
次の各項では、MTS互換コネクタを使用して複数の信頼できるソースのリコンシリエーションを実装できる使用例について説明します。
ここでは、ユーザー・タイプとは、リコンサイルするレコードを所有するユーザーのタイプを指します。ユーザー・タイプには、たとえばEmployeeやCustomerがあります。
ユーザー・タイプによって信頼できるソースのリコンシリエーションを実装するには、信頼できるソースとして構成する各ターゲット・システムのコネクタのデプロイ時に、信頼できるソースのリコンシリエーションを実装する手順を実行します。
リコンシリエーション時に、指定されたユーザー・タイプのターゲット・システム・レコードはすべてリコンサイルされます。ターゲット・システムに複数のユーザー・タイプがある場合は、Limited Reconciliation機能を使用すると、各ターゲット・システムからリコンサイルする必要があるレコードのユーザー・タイプを指定できます。
複数のターゲット・システムから特定のOIMユーザーの属性用に信頼できるソースのリコンシリエーションを構成することもできます。これを実装する手順は、次の使用例を利用して説明します。
あるターゲット・システム（たとえば、TS1）からアイデンティティをリコンサイルし、これらのアイデンティティの特定の属性（たとえば、attr1、attr2およびattr3）を別のターゲット・システム（たとえば、TS2）からリコンサイルします。つまり、TS1はアイデンティティに対する信頼できるソースであり、TS2はこれらのアイデンティティそのものではなく、アイデンティティの特定の属性に対する信頼できるソースです。TS1は、OIMユーザーを正常に作成するために、OIMユーザーの必須属性をすべて提供する必要があります。TS2は、TS2が信頼できるソースであるOIMユーザーの属性（必須または任意のOIMユーザーの属性）のみを提供します。OIMユーザーの必須属性をTS2からリコンサイルする場合は、この属性の値により、OIMユーザーがTS1から作成された後のこの属性に含まれる値は上書きされます。OIMユーザーの任意属性のみをTS2からリコンサイルする場合は、OIMユーザーの作成時に、TS1からこれらの属性をリコンサイルしなくてもかまいません。
TS1コネクタの場合:
attr1、attr2およびattr3）をすべて削除します。
リコンシリエーション・フィールドを削除するかわりに、リコンシリエーション時に作成されるOIMユーザーに値をリコンサイルしないフィールドのリコンシリエーション・フィールド・マッピングを削除することもできます。
Rule Condition: No Matches Found
Action: Create User
TS2コネクタの場合:
attr1、attr2およびattr3以外のTS2の属性をすべて削除します。また、OIMユーザーを既存のTS2のアカウントと一致させるために使用する属性を残しておきます。つまり、リコンシリエーション・ルールの評価に使用する属性のみを残しておきます。たとえば、Oracle Identity Managerのusername属性を使用して、TS1のfirst name属性の値と一致させます。
リコンシリエーション・フィールドを削除するかわりに、リコンシリエーション時に作成されるOIMユーザーに値をリコンサイルしないフィールドのリコンシリエーション・フィールド・マッピングのみを削除することもできます。
Rule Condition: No Matches Found
Action: Create User以外のもの
MTS互換ではないコネクタの場合、複数の信頼できるソースのリコンシリエーションの設定でコネクタを使用するには、次の前提条件に対処する必要があります。
i. 信頼できるソース・リソース・オブジェクトのうち、Xellerate Userにできるのは1つのみです。使用する動作環境で、Xellerate Userリソース・オブジェクトが、すでに信頼できるソースのリコンシリエーション用にコネクタで使用されている場合、構成する信頼できるソース・コネクタに対して、新しいリソース・オブジェクトとプロセス定義を作成する必要があります。
ii. コネクタのスケジュール済タスクには、信頼できるソース・ユーザーのリコンシリエーションに使用されるリソース・オブジェクトの名前をその値として受け入れる属性が必要です。
次の各項では、非MTS互換コネクタを使用して複数の信頼できるソースのリコンシリエーションを実装できる使用例について説明します。
ここでは、ユーザー・タイプとは、リコンサイルするレコードを所有するユーザーのタイプを指します。ユーザー・タイプには、たとえば、ContractorやEmployee、Customerがあります。
Microsoft Active DirectoryおよびOracle e-Business Suiteを信頼できるソースとして動作環境で使用します。Active Directoryは、Contractorユーザー・タイプに属するアイデンティティに関する情報の格納に使用します。Oracle e-Business Suiteは、CustomerおよびEmployeeユーザー・タイプに属するアイデンティティに関する情報の格納に使用します。ContractorのレコードをActive Directoryから、EmployeeのレコードをOracle e-Business Suiteからリコンサイルします。そのためには、次の手順を実行します。
Active Directoryの場合:
信頼できるソースのリコンシリエーション用にコネクタXMLファイルをインポートすると、Active Directory固有の情報がXellerate Userリソース・オブジェクトおよびプロセス定義に追加されます。
ActDirリソース・オブジェクトを作成します。
リソース・オブジェクトには、どのような名前でも割り当てることができます。この手順では、リソース・オブジェクトに割り当てられる名前として
リソース・オブジェクトの作成手順の詳細は、「「Resource Objects」フォーム」を参照してください。
注意:
ActDirを使用します。
リソース・オブジェクトの作成時に、次の操作を実行します。
Rule Condition: No Matches Found
Action: Create User
Xellerate Userリソース・オブジェクトから削除します。
ActDirプロセス定義を作成します。 プロセス定義の作成手順の詳細は、「「Process Definition」フォーム」を参照してください。Xellerate Userプロセス定義のリコンシリエーション・フィールド・マッピングに基づいて、「Reconciliation Field Mappings」タブで、ActDirプロセス定義用のリコンシリエーション・フィールド・マッピングを追加します。
Xellerate Userリソース・オブジェクトでActive Directory固有のフィールド・マッピングを削除します。
Xellerate Userリソース・オブジェクトの値にマップされています。
Oracle e-Business Suiteに対し、Active Directoryに対して実行した手順をすべて繰り返します。Oracle e-BusinessのEmployee Reconciliationコネクタに対しては、その手順の次のステップを別に実行します。
EmpReconリソース・オブジェクトを作成します。Rule Condition: No Matches Found
Action: Create User
Limited Reconciliation機能を使用して、Employeeユーザー・タイプに属するアイデンティティのみをリコンサイルする必要があることを指定します。
Xellerate Userリソース・オブジェクトに作成されたOracle e-Business Suite固有のフィールドおよび対応するルールを削除します。
EmpReconプロセス定義を作成します。プロセス定義の作成手順の詳細は、「「Process Definition」フォーム」を参照してください。Xellerate Userのリコンシリエーション・フィールド・マッピングに基づいて、「Reconciliation Field Mappings」タブで、EmpReconプロセス定義用のフィールド・マッピングを追加します。
Xellerate Userリソース・オブジェクトでOracle e-Business Suite固有のフィールド・マッピングを削除します。
Xellerate Userリソース・オブジェクトの値にマップされています。
Active DirectoryとOracle e-Business Suiteの両方に対して、信頼できるソースのリコンシリエーションの構成に必要な残りの手順を実行します。たとえば、コネクタごとにリコンシリエーションのスケジュール済タスクを構成する際に、信頼できるソース・ユーザーのリコンシリエーション時に使用する必要がある信頼できるソース・リソース・オブジェクトの名前を指定します。
スケジュール済タスク属性の現在の値はXellerate Userであるため、該当するコネクタに対して信頼できるソース・ユーザーのリコンシリエーション用に構成された新しいリソース・オブジェクトの名前で更新する必要があります。
図5-7に、ユーザー・タイプに基づいた信頼できるソースのリコンシリエーションの設計時の実装を示します。
複数のターゲット・システムから特定のOIMユーザーの属性用に信頼できるソースのリコンシリエーションを構成することもできます。これを実装する手順は、次の使用例を利用して説明します。
Microsoft Active DirectoryおよびIBM Lotus Notesをターゲット・システムとして使用します。Active Directoryからアイデンティティをリコンサイルし、（Active DirectoryからOracle Identity Managerにリコンサイルされた）各アイデンティティのe-mail address属性の値のみをLotus Notesからリコンサイルします。そのためには、次の手順を実行します。
Active Directoryコネクタの場合:
信頼できるソースのリコンシリエーション用にコネクタXMLファイルをインポートすると、Active Directory固有の情報がXellerate Userリソース・オブジェクトおよびプロセス定義に追加されます。
ActDirリソース・オブジェクトを作成します。
リソース・オブジェクトには、どのような名前でも割り当てることができます。この手順では、リソース・オブジェクトに割り当てられる名前として
リソース・オブジェクトの作成手順の詳細は、「「Resource Objects」フォーム」を参照してください。
注意:
ActDirを使用します。
リソース・オブジェクトの作成時に、次の操作を実行します。
i. 「Resource Object」タブで「Trusted Source」チェック・ボックスを選択します。
ii. 「Object Reconciliation」→「Reconciliation Fields」タブでXellerate Userリソース・オブジェクトを参照し、リコンサイルするActive Directory固有のフィールドをActDirに追加します。OIMユーザーの必須フィールドはすべて、このタブで追加するフィールドで網羅される必要があります。
Rule Condition: No Matches Found
Action: Create User
Xellerate Userリソース・オブジェクトから削除します。
ActDirプロセス定義を作成します。プロセス定義の作成手順の詳細は、「「Process Definition」フォーム」を参照してください。Xellerate Userプロセス定義のリコンシリエーション・フィールド・マッピングに基づいて、「Reconciliation Field Mappings」タブで、ActDirプロセス定義用のフィールド・マッピングを作成します。
Xellerate Userリソース・オブジェクトでActive Directory固有のフィールド・マッピングを削除します。
Xellerate Userリソース・オブジェクトの値にマップされています。
IBM Lotus Notesに対し、Active Directoryに対して実行した手順をすべて繰り返します。Lotus Notesコネクタに対しては、その手順の次のステップを別に実行します。
LotNotesリソース・オブジェクトを作成します。e-mail address属性のみを追加します。
Xellerate Userリソース・オブジェクトに作成されたLotus Notes固有のフィールドおよび対応するルールを削除します。
LotNotesプロセス定義を作成します。プロセス定義の作成手順の詳細は、「「Process Definition」フォーム」を参照してください。Xellerate Userのリコンシリエーション・フィールド・マッピングに基づいて、「Reconciliation Field Mappings」タブで、LotNotesプロセス定義用のフィールド・マッピングを追加します。
Xellerate Userリソース・オブジェクトでLotus Notes固有のフィールド・マッピングを削除します。
Active DirectoryとLotus Notesの両方に対して、信頼できるソースのリコンシリエーションの構成に必要な残りの手順を実行します。たとえば、コネクタごとにリコンシリエーションのスケジュール済タスクを構成する際、リコンシリエーション時に使用する必要がある信頼できるソース・リソース・オブジェクトの名前を指定します。
スケジュール済タスク属性の現在の値はXellerate Userであるため、該当するコネクタに対して信頼できるソース・ユーザーのリコンシリエーション用に構成された新しいリソース・オブジェクトの名前で更新する必要があります。
図5-8に、特定のOIMユーザーの属性の信頼できるソースのリコンシリエーションの設計時の実装を示します。
Oracle Identity Managerでは、サービス・アカウントがサポートされています。サービス・アカウントは、メンテナンス目的で使用される汎用の管理者アカウント（たとえば、admin1、admin2、admin3など）で、通常は複数のユーザーにより共有されます。サービス・アカウントの管理とプロビジョニングのモデルは、通常のプロビジョニングと多少異なります。
サービス・アカウントは、通常のアカウントと同様に、リクエスト、プロビジョニングおよび管理できます。また、通常のアカウントと同じリソース・オブジェクト、プロビジョニング・プロセス、およびプロセス・フォームとオブジェクト・フォームを使用します。サービス・アカウントは内部フラグで通常のアカウントと区別されます。
ユーザーに対してサービス・アカウントがプロビジョニングされると、Oracle Identity ManagerはそのユーザーのIDからサービス・アカウントへのマッピングを管理します。リソースが失効するかユーザーが削除されても、サービス・アカウントのプロビジョニング・プロセスは取り消されません（取り消されると、取消しタスクが起動されます）。かわりに、プロビジョニング・プロセスにタスクが挿入されます（Oracle Identity Managerでの「Disable」および「Enable」アクションの処理と同様です）。このタスクは、ユーザーからサービス・アカウントへのマッピングを削除し、サービス・アカウントを、使用できるアカウントのプールに返します。
この管理機能はAPIを通じて使用できます。
|
 Copyright © 2009 Oracle Corporation. All Rights Reserved. |
|