リリース9.1.0.1
B53898-01
 目次 |
 索引 |
| Oracle Identity Manager デザイン・コンソール・ガイド リリース9.1.0.1 B53898-01 |
|
この章では、Design Consoleを使用してOracle Identity Managerを管理する方法を説明します。次の内容について説明します。
Design Consoleの「Administration」フォルダには、システム管理者がOracle Identity Manager管理機能を管理するためのツールがあります。このフォルダには次のフォームがあります。
また、このフォームを使用して、Design Consoleエクスプローラに表示されるフォルダおよびフォルダ項目を変更することもできます。
プロパティ値を適用するユーザーとユーザー・グループを指定することも、値をすべてのユーザーに適用するように指定することもできます。
図7-1に示す「Form Information」フォームは、Design Consoleの「Administration」フォルダにあります。このフォームは、クラス名、Design Consoleエクスプローラに表示するラベル、フォーム・タイプ、フォーム・アイコン、およびOracle Identity Managerフォームに関連付けるヘルプを指定するために使用します。また、このフォームを使用して、Design Consoleエクスプローラに表示されるフォルダおよびフォルダ項目を変更することもできます。
表7-1に、このフォームのデータ・フィールドの説明を示します。
Oracle Identity Managerのフォームまたはフォルダを追加するには、次の手順を実行します。
「childform」タイプのフォームの場合、この値は親フォームの名前を含み、parent_form_name.child_form_nameというネーミング規則に準じている必要があります。
フォームがアクティブになっているときにユーザーが[F1]を押すと、このファイルが表示されます。
フォームが追加され、「Key」フィールドにフォームまたはフォルダ用のシステム生成IDが表示されます。
Design Consoleエクスプローラと、そのフォルダおよびフォルダ項目のレイアウトは、様々なユーザー・グループ・レベルに基づいて変更できます。
ユーザーがアクセスできるフォルダおよびフォルダ項目は、そのユーザーがメンバーとなっているユーザー・グループに基づいています。たとえば、IT DEPARTMENTというユーザー・グループは「System Configuration」フォームを開くことができ、HR DEPARTMENTというユーザー・グループは「Lookup Definition」フォームを起動できるとします。この両方のユーザー・グループに属しているユーザーは、「System Configuration」フォームと「Lookup Definition」フォームにアクセスできます。
参照定義は次のいずれかを表します。
これらの項目は参照値と呼ばれ、テキスト・フィールド、参照フィールドまたはボックスに関連する情報を含みます。ユーザーは、次の2つのいずれかの場所から参照定義にアクセスできます。
図7-2に示す「Lookup Definition」フォームは、Design Consoleの「Administration」フォルダにあります。このフォームは、参照定義を作成および管理するために使用します。
表7-2に、「Lookup Definition」フォームのデータ・フィールドの説明を示します。
| フィールド名 | 説明 |
|---|---|
|
Code |
参照定義の名前。 |
|
Field |
テキスト・フィールド、参照フィールドまたはボックス・フィールドにアクセスできるフォームまたはタブの表の列名。 |
|
Lookup Type/Field Type |
これらのオプションは、参照定義がテキスト・フィールド、参照フィールドまたはボックスのどれを表すかを指定します。 「Field Type」オプションを選択した場合、参照定義はテキスト・フィールドを表します。 「Lookup Type」オプションを選択した場合、参照定義は参照フィールドまたはボックスのいずれかを表し、さらにその参照フィールドまたはボックスからアクセス可能な値を表します。 注意:Oracle Identity Managerとともにパッケージ化されているフォームまたはタブの場合、参照定義は参照フィールドまたはボックスのいずれかとしてすでに設定されています。これを変更することはできません。ただし、参照フィールドまたはボックスからアクセスできる値を追加または変更することはできます。 ユーザーが定義したフォームまたはタブの場合、ユーザーが「Form Designer」フォームの「Additional Columns」タブを使用して、参照定義が参照フィールドまたはボックスのいずれを表すかを指定します。 参照定義のデータ型指定の詳細は、「「Additional Columns」タブ」を参照してください。 |
|
Required |
このチェック・ボックスを選択すると、参照定義が必須として指定されます。その結果、その参照定義が表すフィールドまたはボックスにデータが入力されるまで、Oracle Identity Managerでは対応するフォームまたはタブの内容の保存が許可されません。 |
|
Group |
参照定義を表示するOracle Identity Managerフォームまたはユーザー定義フォームの名前。 |
次の項では、参照定義を作成する方法について説明します。
参照定義を作成するには、次の手順を実行します。
参照定義がテキスト・フィールドを表す場合は、「Field Type」オプションを選択します。
「Code」、「Field」および「Group」の各フィールドに入力するテキストは、ネーミング規則に準じている必要があります。
参照定義が作成されます。関連付けられたテキスト・フィールド、参照フィールドまたはボックスが、指定したOracle Identity Managerまたはユーザー定義のフォームまたはタブに表示されます。
「Lookup Code Information」タブは、「Lookup Definition」フォームの下部にあります。このタブは、選択した参照定義の詳細情報を作成および管理するために使用します。この情報には、参照定義に関連する値の名前、説明、言語コードおよび国コードが含まれます。これらの項目は参照値と呼ばれます。
次の手順は、参照値を作成、変更および削除する方法について説明しています。
参照値を作成または変更するには、次の手順を実行します。
「Lookup Code Information」タブに空行が表示されます。
参照値を変更する場合は、編集する参照値を選択します。
このフィールドには参照値の名前が含まれます。
また、「Lookup Type」オプションが選択されている場合、このフィールドは、ユーザーが選択を行ったときに参照フィールドまたはボックスに表示される内容も表します。
このフィールドには参照値の説明が含まれます。
「Lookup Type」オプションが選択されている場合、このフィールドは次のいずれかも表します。
このフィールドには、参照値の2文字の言語コードが含まれます。
このフィールドには、参照値の2文字の国コードが含まれます。
これで、作成または変更した参照値に、入力した設定が反映されます。
参照値を削除するには、次の手順を実行します。
Oracle Identity Managerによりデフォルトで提供されるフィールドを補足する場合があります。様々なOracle Identity Managerフォームに対して新しいフィールドを作成したり、追加することができます。これらのフィールドはユーザー定義フィールドと呼ばれます。
ユーザー定義フィールドは、「Form Name」データ・フィールドに示されたフォームの「User Defined Fields」タブに表示されます。たとえば、図7-3では、「Organizations」フォームの「User Defined Fields」タブに「Access Code Number」ユーザー定義フィールドが追加されています。
図7-3に示す「User Defined Field Definition」フォームは、Design Consoleの「Administration」フォルダにあります。このフォームは、「Organizations」、「Users」、「Requests」、「Resource Objects」、「User Groups」および「Form Designer」フォームのユーザー定義フィールドを作成および管理するために使用します。
表7-3に、「User Defined Field Definition」フォームのデータ・フィールドの説明を示します。
次の項では、ユーザー定義フィールドのターゲット・フォームを選択する方法について説明します。
ユーザー定義フィールドのターゲット・フォームを選択するには、次の手順を実行します。
Lookupウィンドウが表示されたら、作成するユーザー定義フィールドが表示されるOracle Identity Managerフォーム（「Organizational Defaults」、「Policy History」、「Group Entitlements」、「Resource Objects」または「Form Designer」）を選択します。
ユーザー定義フィールドの追加先のフォームが選択されます。
「User Defined Field Definition」フォームを起動し、ユーザー定義フィールドのターゲット・フォームを選択すると、このフォームのタブが使用可能になります。
「User Defined Field Definition」フォームには次のタブが含まれます。
これらのタブについては、以降の項でそれぞれ詳しく説明します。
このタブは、次のことを行うために使用します。
フィールドの順序番号によって、ユーザー定義フィールドがフォームに表示される順序が決まります。図7-4では、Access Code Numberユーザー定義フィールドの順序番号が
1であるため、Organizationsフォームの「User Defined Fields」タブにはこのフィールドが最初に表示されています。
図7-4に、「User Defined Field Definition」フォームの「User Defined Columns」タブを示します。
次の項では、Oracle Identity Managerフォームにユーザー定義フィールドを追加する方法と、Oracle Identity Managerフォームからユーザー定義フィールドを削除する方法について説明します。
ユーザー定義フィールドを追加するには、次の手順を実行します。
図7-5に示すように、「User Defined Fields」ダイアログ・ボックスが表示されます。
表7-4に、「User Defined Fields」ダイアログ・ボックスのフィールドの説明を示します。
図7-6では、Access Code Numberユーザー定義フィールドが、Organizationsフォームの「User Defined Fields」タブの最初に表示されています。このフィールドのデータ型はStringであり、ユーザーはこのフィールドに最大25桁を入力できます。
ユーザー定義フィールドが、「User Defined Columns」タブに表示されます。ターゲット・フォームが起動されると、通常、このユーザー定義フィールドがそのフォームの「User Defined Fields」タブに表示されます。ユーザーのユーザー定義フィールドはユーザーのプロファイル情報に関連しているため、「Users」フォームの「User Profile」タブに表示されます。
ユーザー定義フィールドを削除するには、次の手順を実行します。
このタブは、様々なOracle Identity Managerフォームの「User Defined Fields」タブに表示されるデータ・フィールドにプロパティおよびプロパティ値を割り当てるために使用します。
この例では、「Requests form」の「User Defined Fields」タブに、「Issue Tracking Item」という1つのデータ・フィールドが表示されます。このデータ・フィールドには次のプロパティが含まれます。
このデータ・フィールドでは「Required」プロパティと「Visible Field」プロパティの値はtrueであるため、「Requests」フォームが起動されると、「User Defined Fields」タブに「Issue Tracking Item」データ・フィールドが表示されます。また、このフィールドに値を移入しないと、フォームは保存されません。
図7-7に、「User Defined Field Definition」フォームの「Properties」タブを示します。
次の項では、データ・フィールドにプロパティおよびプロパティ値を追加する方法と、データ・フィールドからこれらを削除する方法について説明します。
図7-8に、「User Defined Field Definition」フォームの「Administrators」タブを示します。
このタブは、「User Defined Field Definition」フォームの現在のレコードに対する管理権限を持つユーザー・グループを指定するために使用します。このフォームの「Write」および「Delete」チェック・ボックスは、これらの管理グループが、現在のユーザー定義フィールド（UDF）定義に関する情報の変更または削除、あるいはその両方を行えるかどうかを指定します。
次の項では、UDF定義のユーザー・グループに管理権限を割り当てる方法と、UDF定義のユーザー・グループから管理権限を削除する方法について説明します。
UDF定義のユーザー・グループに管理権限を割り当てるには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
ユーザー・グループが「Administrators」タブに表示されます。
ユーザー・グループがUDF定義に割り当てられます。
管理権限を削除するには、次の手順を実行します。
図7-9に示す「System Configuration」フォームは、Design Consoleの「Administration」フォルダにあります。このフォームは、Oracle Identity Managerのアクションを制御するプロパティの値を定義および設定するために使用します。プロパティ値を適用するユーザーとユーザー・グループを指定することも、プロパティ値をすべてのユーザーに適用するように指定することもできます。
表7-5に、このフォームのデータ・フィールドの説明を示します。
次の項では、プロパティ定義のインスタンスを定義する方法、これらのインスタンスにユーザーまたはグループを割り当てる方法、およびこのインスタンスからユーザーまたはグループを削除する方法について説明します。
プロパティ定義の新しいインスタンスを作成する、または既存のインスタンスを編集するには、次の手順を実行します。
「Name」および「Keyword」フィールドの値が、このプロパティ定義のすべてのインスタンスについて同じであることを確認します（たとえば、「Record Read Limit」、「XL.READ_LIMIT」）。
プロパティ定義の既存のインスタンスを編集する場合は、プロパティ定義を問い合せます。
これが、定義のこのインスタンスのプロパティ値になります。
プロパティ定義のインスタンスが作成または変更されます。
プロパティ定義のインスタンスにユーザーまたはグループを割り当てるには、次の手順を実行します。
「Assignment」ダイアログ・ボックスが表示されます。
プロパティ定義のインスタンスが、手順6で選択したユーザーまたはグループに割り当てられます。
プロパティ定義のインスタンスからユーザーまたはグループを削除した場合、そのプロパティとユーザーまたはグループとの関連はなくなります。
プロパティ定義のインスタンスからユーザーまたはグループを削除するには、次の手順を実行します。
ユーザーまたはグループがプロセス定義のインスタンスから削除されます。
Remote Managerは軽量のネットワーク・サーバーであり、これを使用すると、ネットワークで通信できないAPIを持つターゲット・システムや、ネットワーク対応であってもセキュアではないターゲット・システムと統合できます。Remote Managerはターゲット・システム上でサーバーとして動作し、Oracle Identity Managerサーバーはそのクライアントとして動作します。Oracle Identity ManagerサーバーはRemote Managerのリクエストを送信して、ターゲット・システム自体でターゲット・システムAPIをインスタンス化し、ターゲット・システムにかわってメソッドを起動します。
図7-10に示す「Remote Manager」フォームは、Design Consoleの「Administration」フォルダにあります。このフォームには次の情報が表示されます。
この例では、Oracle Identity Managerと通信できる2つのリモート・マネージャ（Australia ServerとUKSERVER）を定義します。
Australia Serverというリモート・マネージャのIPアドレスは、215.0.255.192です。このリモート・マネージャはOracle Identity Managerとハンドシェイクできますが、「Running」チェック・ボックスが選択解除されているため、リモート・サーバーは使用できません。最後に、「IT Resource」チェック・ボックスが選択されています。これは、このリモート・マネージャがOracle Identity Managerで使用できるITリソースを表していることを示します。
UKSERVERというリモート・マネージャのIPアドレスは、192.168.0.45です。「Running」チェック・ボックスが選択されているため、リモート・サーバーは動作可能です。しかし、
「IT Resource」チェック・ボックスが選択解除されているため、このリモート・マネージャはOracle Identity Managerで使用できるITリソースではありません。
「Password Policies」フォームは、Design Consoleの「Administration」/「Policies」フォルダにあります。このフォームを使用して、次の操作を実行できます。
図7-11に、「Password Policies」フォームを示します。
パスワード・ポリシーを作成するには、先に「Password Policies」フォームの次のフィールドに必須の値を入力する必要があります。
次の各項では、「Password Policies」フォームの使用方法について説明します。
パスワード・ポリシーを作成するには、次の手順を実行します。
このフォームのタブは、パスワード・ポリシーを作成すると使用可能になります。次の各項では、これらのタブについて説明します。
「Policy Rules」タブは、パスワード・ポリシーの基準（たとえば、パスワードの最小長と最大長）を指定するために使用します。
パスワードの制限を設定するには、次のいずれか（または両方）の方法を使用できます。
c:¥xellerate¥userlimits.txt）を入力します。このファイルには、パスワードとして使用できない事前定義済の用語が指定されています。これらの語は、「Password File Delimiter」フィールド内に指定されたデリミタによって区切られます。
図7-11に、「Password Policies」フォームの「Policy Rules」タブを示します。
表7-6に、「Policy Rules」タブのデータ・フィールドの説明を示します。これらのフィールドにパスワード・ポリシーの基準を指定します。
「Password Policies」フォームの「Policy Rules」タブでは、複雑なパスワードまたはカスタム・パスワード・ポリシーのいずれかを構成できます。「Complex Password」オプションを選択すると、「Custom Policy」オプション設定は使用できず、パスワードは「Policy Rules」タブで入力した複雑なパスワードの基準に対して評価されます。
次の各項では、「Policy Rules」タブの残りのフィールドについて説明します。
複雑なパスワードの基準は次のとおりです。
ユーザーの氏名と照合する際、カンマ、ピリオド、ダッシュ/ハイフン、アンダースコア、空白、ポンド記号、タブなどの文字は、名前を個々の文字のセットに区切るデリミタとして扱われます。3文字以上から成る文字のセットがそれぞれパスワード内で検索されます。文字のセットがパスワード内に存在する場合、そのパスワード変更は却下されます。たとえば、John Richard-Doeは、John、RichardおよびDoeの3つの文字のセットに分割されます。このユーザーは、パスワードのどこかが、John、RichardまたはDoeのいずれかの連続する3文字で構成されるパスワードを使用できません。しかし、パスワードには部分文字列のd-Dを含めることができます。これは、ハイフン（-）が部分文字列のRichardとDoeの間のデリミタとして扱われるためです。また、パスワード内の文字のセットの検索では大/小文字が区別されません。
「Custom Policy」オプションを選択すると、表7-7に示すフィールドを使用してカスタム・パスワード・ポリシーを設定できます。
「System Configuration」フォームで、XL.ForcePasswordChangeAtFirstLoginキーワードを含むForce Password Change At First Loginプロパティの値をTrueに設定して、初回ログイン時にユーザーにパスワードを変更させることができます。XL.ForcePasswordChangeAtFirstLoginキーワードがすでにTrueに設定された状態でユーザーが作成された場合のみ、初回ログイン時にパスワードの変更を強制されることに注意してください。
Force Password Change At First Loginプロパティの値を変更するたびに、サーバーを再起動するかキャッシュを消去して変更を有効にする必要があります。キャッシュを消去する場合、キャッシュ・カテゴリはServerCachedPropertiesです。
いずれかの「Password」フィールドを使用してプロセス・フォームをリソースにアタッチできます。パスワード・ポリシーを同じリソースに適用し、そのリソースに対してアクセス・ポリシーを作成する場合は、プロセス・フォームにユーザーが入力したパスワードは、パスワード・ポリシー・ルールと照合されません。これは、リソースがユーザーにプロビジョニングされるとき、リソースに適用されるパスワード・ポリシー・ルールと照合されるパスワードをユーザーが指定する必要があるためです。
パスワード・ポリシーの基準を設定するには、次の手順を実行します。
このタブは、現在のパスワード・ポリシーに関連付けられているルールおよびリソース・オブジェクトを表示するために使用します。
たとえば、図7-12は、「Solaris」というパスワード・ポリシーを示しています。「Password Validation Rule」が「The Solaris Resource Object」に割り当てられています。
図7-12に、「Password Policies」フォームの「Usage」タブを示します。
図7-13に示す「Task Scheduler」フォームは、「Administration」/「Job Scheduling Tools」フォルダにあります。このタブは、次のことを定義するために使用します。
|
注意: 前述のように、「Task Scheduler」フォームは、タスクが実行される時間を指定するために使用します。ただし、このタスクの実行をトリガーするOracle Identity Managerプログラムはスケジューラ・デーモンと呼ばれます。 スケジューラ・デーモンが稼働していない場合は、指定された機能を実行できないため、スケジューラ・デーモンがアクティブになっていることを確認する必要があります。 システム・プロパティの値の変更の詳細は、「「System Configuration」フォーム」を参照してください。 |
表7-8に、「Task Scheduler」フォームのフィールドの説明を示します。
次の各項では、スケジュール済タスクについて詳しく説明します。
表7-9に、このリリースのOracle Identity Managerで使用可能な事前定義済のスケジュール済タスクを示します。
スケジュール済タスクの作成に加えて、タスクに属性が必要な場合は、属性を設定する必要があります。そうしない場合、スケジュール済タスクは機能しません。
既存のタスク属性が不要になった場合は、スケジュール済タスクからその属性を削除する必要があります。
次の手順は、スケジュール済タスクを作成する方法について説明しています。後述の手順では、スケジュール済タスクに属性を追加する方法と、スケジュール済タスクからタスク属性を削除する方法を示しています。
スケジュール済タスクを作成するには、次の手順を実行します。
ERRORステータスをタスクに割り当てるまでにタスクの完了を試行する回数を表します。
Date & Timeウィンドウが表示されたら、タスクを実行する日時を設定します。（「Recurring Intervals」オプションを選択して）繰返しベースでタスクを実行するように指定した場合、関連付けられたタスクの次回の実行日時を決定する際に、このフィールドに表示された日時が参照されます。
スケジュール済タスクが作成されます。さらに、タスクは現在実行中ではないため、「Status」フィールドに「INACTIVE」が表示されます。ただし、手順6で設定した日時が現在の日時に一致した時点で、スケジューラ・デーモンはスケジュール済タスクをトリガーします。
タスク属性を追加するには、次の手順を実行します。
タスク属性がスケジュール済タスクに追加されます。
タスク属性を削除するには、次の手順を実行します。
スケジュール済タスクを削除するには、次の手順を実行します。
|
 Copyright © 2009 Oracle Corporation. All Rights Reserved. |
|