Oracle Identity Manager Oracle E-Business User Management Connectorガイド リリース9.1.0 B56038-01 |
|
![]() 戻る |
![]() 次へ |
コネクタをデプロイしたら、要件に合せて構成する必要があります。この章では、次のコネクタ構成手順を説明します。
注意: これらの項では、コネクタの構成に関する概念および手順の両方を説明します。概念情報を確認してから手順を実行することをお薦めします。 |
使用しているコネクタに応じて、構成情報を含む次の参照定義の一部のエントリにデコード値を指定する必要があります。
参照定義のエントリにデコード値を設定するには、次のようにします。
Design Consoleで、「Administration」を開き、「Lookup Definition」をダブルクリックします。
変更する参照定義を検索して開きます。
設定する「Code Key」の「Decode」列に値を入力します。
「Save」アイコンをクリックします。
値を指定する必要があるコード・キー・エントリの詳細は、使用しているコネクタに応じて、次のいずれかの項を参照してください。
User Managementコネクタを使用している場合は、Lookup.EBS.UM.Configurations参照定義の次のエントリにデコード値を指定します。
USE_CONNECTION_POOLING
コネクタで接続プーリングを使用する場合は、USE_CONNECTION_POOLINGコード・キーの値をYes
に設定します。この機能の詳細は、1.4.12項「接続プーリング」を参照してください。
User Management with HR Foundationコネクタを使用している場合は、Lookup.EBS.UMHRMS.Configurations参照定義の次のエントリにデコード値を指定します。
USE_CONNECTION_POOLING
コネクタで接続プーリングを使用する場合は、USE_CONNECTION_POOLINGコード・キーの値をYesに設定します。この機能の詳細は、1.4.12項「接続プーリング」を参照してください。
UD_EBSH_USR_BIZGRPIDおよびUD_EBSH_USR_PERTYPEID
ビジネス・グループIDと個人タイプIDは、プロセス・フォームの属性のうちの2つです。これらの属性の値を入力することで、コネクタ操作の対象とする必要があるHRMS個人レコードのサブセットを指定します。これらのフィールドの値は、ダイレクト・プロビジョニングを実行するときに管理およびユーザー・コンソールで入力できます。または、これらの属性の値をLookup.EBS.UMHRMS.Configurations参照定義のUD_EBSH_USR_BIZGRPIDエントリおよびUD_EBSH_USR_PERTYPEIDエントリに設定することもできます。プロビジョニング操作時には、プロセス・フォームのこれらの属性に値を入力しないと、コネクタによってUD_EBSH_USR_BIZGRPIDエントリおよびUD_EBSH_USR_PERTYPEIDエントリのデコード値が使用されます。
注意: 参照定義のこれらのエントリは、リクエストベースのプロビジョニングでも使用されます。 |
UD_EBSH_USR_BIZGRPIDコード・キーのデコード値を判別するには、ターゲット・システム・データベースで次の問合せを実行します。
SELECT business_group_id FROM hr_all_organization_units WHERE business_group_id = organization_id and hr_all_organization_units.name = 'ORGANIZATION_NAME'
UD_EBSH_USR_PERTYPEIDコード・キーのデコード値を判別するには、ターゲット・システム・データベースで次の問合せを実行します。
SELECT person_type_id, user_person_type FROM per_person_types WHERE business_group_id =
BUSINESS_GROUP_ID AND system_person_type = 'EMP'
UD_EBSH_USR_BIZGRPIDコード・キーの問合せから返される値で、この問合せのBUSINESS_GROUP_IDを置き換えます。この問合せでは、EMPタイプ(たとえば、従業員、退職者および契約社員)のレコードの個人タイプIDが返されます。
User Management with TCA Foundationコネクタを使用している場合は、Lookup.EBS.UMTCA.Configurations参照定義の次のエントリにデコード値を指定します。
USE_CONNECTION_POOLING
コネクタで接続プーリングを使用する場合は、USE_CONNECTION_POOLINGコード・キーの値をYesに設定します。この機能の詳細は、1.4.12項「接続プーリング」を参照してください。
eBusiness UM参照定義のリコンシリエーション・スケジュール済タスクは、参照フィールドの同期に使用されます。
注意: このスケジュール済タスクの構成手順は、このマニュアルで後述します。一部の属性の説明では、デフォルト値を変更しないように指示しています。 ただし、このスケジュール済タスクのコピーを作成した場合は、コピーを作成したスケジュール済タスクのターゲット・システム・インストールに固有の属性値を入力することができます。コネクタ・オブジェクトのコピーを作成する方法の詳細は、4.6項「ターゲット・システムの複数のインストールに対するコネクタの構成」を参照してください。 デフォルト値が値の入力という文字列の属性には、値を指定する必要があります。 |
表3-1に、このスケジュール済タスクの属性の説明を示します。
表3-1 eBusiness UM参照定義のリコンシリエーション・スケジュール済タスクの属性
属性 | 説明 |
---|---|
問合せプロパティ・ファイル |
実行する参照定義同期問合せが格納されているファイルのフルパスと名前を入力します。 サンプル値: |
ITリソース名 |
2.3.3.6項「ITリソースの構成」の手順を実行して構成するITリソースの名前を入力します。 サンプル値: EBS-APPS12 |
参照定義名 |
ターゲット・システムと同期する参照定義の名前を入力します。次のいずれかの参照定義を指定できます。
|
タスク名 |
この属性は、スケジュール済タスクの名前を保持します。 値: 注意: このスケジュール済タスクの場合、この属性の値を変更しないでください。ただし、このスケジュール済タスクのコピーを作成した場合は、そのスケジュール済タスクに、そのスケジュール済タスクの一意の名前を属性の値として入力する必要があります。 |
モード |
デフォルト値: 注意: デフォルト値は変更しないでください。 |
注意: コネクタによって同期される参照フィールド・データに含まれる文字が、Oracle Identity Managerで無効とみなされる場合、IllegalInputException例外がスローされます。無効な文字を含むレコードが検出されると、コネクタはそのレコードの処理を行わずに、他のレコードをリコンサイルします。ログで文字列 Oracle Identity Managerでサポートされる特殊文字の詳細は、『Oracle Identity Managerグローバリゼーション・ガイド』を参照してください。 |
このガイドで前述したように、リコンシリエーションとは、ターゲット・システム上でのユーザー・アカウントの作成および変更を、Oracle Identity Managerで複製することです。この項では、リコンシリエーションの構成に関する次の項目について説明します。
この項では、スケジュール済タスクの最終実行時間属性について説明します。
最終実行時間属性は、前回のリコンシリエーション実行が開始したときのタイムスタンプを保持します。この属性は、「問合せの名前」属性によって指定されるリコンシリエーション問合せと組み合せて使用されます。リコンシリエーション実行時には、最終実行時間属性に格納されたタイムスタンプ値よりも後に追加または変更されたターゲット・システム・レコードのみが、リコンシリエーションのためにOracle Identity Managerにフェッチされます。
最終実行時間属性の値を決めるときには、次のガイドラインを適用します。
特定のリコンシリエーション・モードで、すべてのターゲット・システム・レコードをリコンシリエーションのためにフェッチする場合、この属性の値を0に設定します。
タイムスタンプを指定する場合は、まず次の問合せを実行してタイムスタンプを必要な書式に変更します。
SELECT (TO_DATE('DATE_TO_BE_CONVERTED','DD-MON-YYYY') -
TO_DATE('01011970', 'DDMMYYYY')) *24*60*60*1000 as ts FROM DUAL
この問合せのDATE_TO_BE_CONVERTEDを、タイムスタンプとして使用する日付で置き換えます。たとえば、タイムスタンプとして5-Dec-2008を使用する場合は次の問合せを実行します。
SELECT (TO_DATE('5-Dec-2008','DD-MON-YYYY') - TO_DATE('01011970', 'DDMMYYYY')) *24*60*60*1000 as ts FROM DUAL
この問合せによって次の値が返されます。
1228435200000
この値を最終実行時間属性の値として指定します。
最終実行時間属性は、リコンシリエーション実行のたびに更新されます。たとえば、最終実行時間属性は実行開始時のタイムスタンプに設定されます。
リコンシリエーションの実行中に、ターゲット・システム・レコードのすべての変更内容がOracle Identity Managerにリコンサイルされます。リコンサイルされるレコード数によっては、このプロセスに長い時間がかかる場合があります。また、リコンシリエーション中に接続が中断すると、プロセスの完了にはさらに時間がかかります。
これらの問題を避けるため、バッチ・リコンシリエーションを構成できます。
バッチ・リコンシリエーションを構成するには、ユーザー・リコンシリエーションの「バッチ・サイズ」スケジュール済タスク属性に値を指定する必要があります。指定する値は、各バッチに含める必要があるレコード数です。デフォルト値は1000
です。
注意: この項では、オプションの手順を説明します。この手順は、リコンシリエーションにフィルタ・パラメータを追加する場合にのみ実行します。この手順を実行するかわりに、実行するリコンシリエーション問合せのWHERE句に条件を直接追加することもできます。 |
デフォルトでは、前回のリコンシリエーションの実行後に追加または変更されたすべてのターゲット・システム・レコードが、現在のリコンシリエーションの実行中にリコンサイルされます。リコンサイルする必要のある追加または変更されたターゲット・システム・レコードのサブセットを指定して、このプロセスをカスタマイズできます。これを行うには、フィルタ・パラメータをリコンシリエーション問合せに追加し、Lookup.EBS.UM.QueryFiltersなどの参照定義にそのパラメータの値を指定します。
たとえば、UM_USER_RECON問合せのWHERE句にパラメータを追加して、参照定義に指定したユーザー名を含むFND_USERレコードが返されるようにできます。
リコンシリエーション問合せにフィルタ・パラメータを追加するには、次のようにします。
注意: プロパティ・ファイルの問合せを変更する前に、その問合せを標準データベース・クライアントを使用して実行し、ターゲット・システム・データベースで実行したときに必要な結果が生成されることを確認する必要があります。 |
次のようにして問合せを変更します。
テキスト・エディタでプロパティ・ファイルを開きます。
変更する問合せのWHERE句に条件を追加します。
注意: パラメータ名の先頭には接頭辞のコロン(:)を付ける必要があります。また、コロンとパラメータ名の間やパラメータ名そのものの中にスペースを含めることはできません。 |
たとえば、UM_USER_RECON問合せの次のスニペットでは、太字の変数の条件が追加されています。
round((rolegrp.LAST_UPDATE_DATE - to_date('01011970', 'ddmmyyyy')) * 1440 * 60 * 1000)>
:lastExecutionTime \
GROUP BY rolegrp.USER_NAME, fnd.EMPLOYEE_ID, fnd.USER_ID, fnd.DESCRIPTION,
fnd.EMAIL_ADDRESS,fnd.FAX, \
fnd.START_DATE, fnd.END_DATE) \
) usr where UPPER(USER_NAME) = UPPER(:username)
ファイルを保存して閉じます。
次のようにしてLookup.EBS.UM.QueryFilters参照定義を構成します。
Design Consoleにログインします。
「Administration」を開き、「Lookup Definition」をダブルクリックします。
Lookup.EBS.UM.QueryFilters参照定義を検索して開きます。
行を追加するには、「Add」をクリックします。
「Code Key」列に、プロパティ・ファイルに指定した変数名を入力します。コロン(:)は含めないでください。たとえば、「Code Key」列にusername
と入力します。
「Decode」列に、今後のリコンシリエーション実行でパラメータに割り当てる値を入力します。次のいずれかの書式を使用して値を指定します。
value
|DATE|
DATE_FORMAT
サンプル値: 1-Dec-1975|DATE|DD-Mon-YYYY
注意: ユーザー名の例では、次のサンプル値を入力できます。 |
value
|STRING
サンプル値: jdoe|STRING
value
|NUMBER
サンプル値: 33|NUMBER
「Save」アイコンをクリックします。
変更した問合せを次に実行すると、追加した条件が追加のフィルタとしてリコンシリエーション時に適用されます。
次のスケジュール済タスクが、ユーザー・データのリコンサイルに使用されます。
eBusiness UMターゲット・リソースのユーザー・リコンシリエーション・スケジュール済タスクは、User Managementコネクタで使用されます。
eBusiness UMターゲット・リソースのユーザーHRMSリコンシリエーション・スケジュール済タスクは、User Management with HR Foundationコネクタで使用されます。
eBusiness UMターゲット・リソースのユーザーTCAリコンシリエーション・スケジュール済タスクは、User Management with TCA Foundationコネクタで使用されます。
表3-2に、これらのスケジュール済タスクの属性の説明を示します。
注意:
|
表3-2 eBusiness UMターゲット・リソースのユーザー・リコンシリエーション・スケジュール済タスクの属性
属性 | 説明 |
---|---|
リコンシリエーション参照定義 |
この属性は、ターゲット・システムとプロセス・フォーム・フィールドのマッピングを含む参照定義の名前を保持します。
注意: この値を変更しないでください。 |
ターゲット日付書式 |
ターゲット・システム・データベースに格納されている日付値の書式を入力します。 デフォルト値: |
問合せプロパティ・ファイル |
実行するユーザー・リコンシリエーション問合せが含まれるファイルのフルパスと名前を入力します。 サンプル値: |
問合せの名前 |
リコンシリエーション問合せファイル内の実行する問合せの名前を入力します。 デフォルト値:
|
ITリソース名 |
2.3.3.6項「ITリソースの構成」の手順を実行して構成するITリソースの名前を入力します。 サンプル値: |
最終実行時間 |
この属性は、前回のリコンシリエーションの実行が開始したときのタイムスタンプを保持します。 デフォルト値: 最終実行時間属性に値を設定する方法の詳細は、3.3.1項「リコンシリエーションのタイムスタンプ」を参照してください。 |
バッチ・サイズ |
ターゲット・システムからフェッチされる各バッチに含めるレコード数を入力します。デフォルト値: この属性は、3.3.2項「バッチ・リコンシリエーション」で説明しています。 |
タスク名 |
この属性は、スケジュール済タスクの名前を保持します。
注意: このスケジュール済タスクの場合、この属性の値を変更しないでください。ただし、このスケジュール済タスクのコピーを作成した場合は、そのスケジュール済タスクに、新しいスケジュール済タスクの一意の名前を「タスク名」属性の値として入力する必要があります。 |
リソース・オブジェクト名 |
この属性は、コネクタのリソース・オブジェクトの名前を保持します。
注意: デフォルト値は変更しないでください。ただし、リソース・オブジェクトのコピーを作成した場合は、新しいリソース・オブジェクトの名前を「リソース・オブジェクト」属性の値として入力できます。 |
問合せフィルタ参照定義 |
この属性は、リコンシリエーション・フィルタ・パラメータの情報を含む参照定義の名前を保持します。
注意: この参照定義のフィルタ・パラメータが、「問合せの名前」属性で指定する問合せと一緒に適用できることを確認する必要があります。この条件を満たさない場合にはエラーが検出されます。 |
この項では、スケジュール済タスクの構成手順について説明します。この手順は、参照フィールド同期およびリコンシリエーションのスケジュール済タスクを構成する場合に適用できます。
スケジュール済タスクを構成するには、次のようにします。
管理およびユーザー・コンソールにログインします。
「リソース管理」を展開します。
「スケジュール済タスクの管理」をクリックします。
「スケジュール済タスクの管理」ページで、スケジュール済タスクの名前を検索基準として入力し、「検索」をクリックします。
このスクリーンショットは、「スケジュール済タスクの管理」ページを示します。
検索結果の表で、スケジュール済タスクの「編集」列の編集アイコンをクリックします。このスクリーンショットは、「スケジュール済タスクの詳細」ページを示します。
「スケジュール済タスクの詳細」ページで「編集」をクリックすると、スケジュール済タスクの次の詳細を変更できます。
ステータス: タスクを有効な状態のままにするかどうかを指定します。有効な状態では、タスクは使用できる状態にあります。
最大再試行数: このフィールドには整数値を入力します。この数は、Oracle Identity Managerがタスクの完了を試行する回数です。この数を超えると、ERRORステータスがタスクに割り当てられます。デフォルト値は2です。
次回開始: 日付エディタを使用してタスクを実行する日付を指定します。日付エディタで日付値を選択した後に、「次回開始」フィールドに自動的に表示される時間値を変更できます。
頻度: タスクを実行する頻度を指定します。
「編集」をクリックすると、「スケジュール済タスクの編集」ページが表示されます。
前のステップに示したスケジュール済タスクの詳細について値を変更した後、「続行」をクリックします。
スケジュール済タスクの属性の値を指定します。そのためには、「属性」リストから各属性を選択し、表示されたフィールドに値を指定して「更新」をクリックします。
注意:
|
次のスクリーンショットは、「属性」ページを示しています。変更のために選択したスケジュール済タスクの属性がこのページに表示されます。
「変更の保存」をクリックして、データベースに対してすべての変更をコミットします。
注意: 実行中にスケジュール済タスクを停止する場合は、Design ConsoleのStop Execution機能を使用します。この機能の詳細は、『Oracle Identity Managerデザイン・コンソール・ガイド』の「Task Scheduler」フォームに関する項を参照してください。 |
この項では、新しいリソースまたは権限のプロビジョニングの際に、管理およびユーザー・コンソールで値を設定できるリソースと権限の属性を示します。リソース更新プロビジョニング操作または権限更新プロビジョニング操作の際には、リソースまたは権限のすべての属性を更新できます。
この項では、次の項目について説明します。
3.5.2項「User Management with TCA Foundationコネクタを使用するリソース・プロビジョニング」
3.5.3項「User Management with HR Foundationコネクタを使用するリソース・プロビジョニング」
User Managementコネクタを使用している場合は、リソースをプロビジョニングするときに次の属性の値を設定できます。
プロビジョニング操作を実行するターゲット・システム・インストールを表すITリソース
個人ID
説明
電子メール
FAX
SSOユーザーID
User Management with TCA Foundationコネクタを使用している場合は、リソースをプロビジョニングするときに次の属性の値を設定できます。
プロビジョニング操作を実行するターゲット・システム・インストールを表すITリソース
説明
電子メール
FAX
SSOユーザーID
「ユーザー名」フィールドと「パスワード」フィールドには、OIMユーザー・データが事前に移入されます。有効期間開始日属性には、現在の日付が移入されます。有効期間終了日、パスワードの有効期限タイプおよびパスワードの有効期間属性には値を設定できません。
また、OIMユーザーは、この項の後で示すロールと職責の属性の値を設定できます。
User Management with HR Foundationコネクタを使用している場合は、リソースをプロビジョニングするときに次の属性の値を設定できます。
プロビジョニング操作を実行するターゲット・システム・インストールを表すITリソース
説明
電子メール
FAX
SSOユーザーID
性別
従業員番号
「ユーザー名」、「パスワード」、「名」および「姓」フィールドには、OIMユーザー・データが事前に移入されます。有効期間開始日フィールドおよび「入社日」フィールドには、現在の日付が移入されます。ビジネス・グループID属性と個人タイプID属性には、デフォルト値(それぞれ202と13)が含まれます。有効期間終了日、パスワードの有効期限タイプおよびパスワードの有効期間フィールドは、値なしでプロビジョニングされます。OIMユーザーは、新しいリソースのリクエストを送信するときはこれらの属性に値を入力できません。
3つのコネクタのいずれかを使用している場合は、リソースのために設定する値に加えて次の権限属性の値を設定できます。
アプリケーション名
ロールまたは職責名
開始日
「有効期限」属性は、値なしでプロビジョニングされます。エンドユーザーは、新しいリソースのプロビジョニング時にはこの属性に値を設定できません。
OIMユーザーへのリソースのプロビジョニングでは、Oracle Identity Managerを使用して、ユーザーのOracle E-Business Suiteアカウントが作成されます。
コネクタ・インストーラを実行すると、Oracle E-Business Suiteユーザー・アカウントのダイレクト・プロビジョニングとリクエストベースのプロビジョニング両方に対する構成がインストールされます。このため、ダイレクト・プロビジョニングの際には、プロセス・フォームが抑制されてオブジェクト・フォームが表示されます。ダイレクト・プロビジョニングの際にプロセス・フォームを使用できるようにするには、次のようにします。
注意: この手順を実行すると、リクエストベースのプロビジョニングが無効になります。 |
リソース・オブジェクトを開きます。
リソース・オブジェクトからオブジェクト・フォームをデタッチするには、「表名」フィールドからフィールド名を削除します。
「セルフ・リクエストを許可」チェック・ボックスを選択解除します。
「保存」アイコンをクリックします。
プロビジョニング・タイプのプロセス定義を開きます。
「自動保存」チェック・ボックスを選択解除します。
データ・フロー・タブで、表示されているすべてのマッピングを削除します。
「保存」アイコンをクリックします。
次にプロビジョニング操作のタイプを示します。
関連項目: プロビジョニングのタイプの詳細は、『Oracle Identity Manager Connector概要』を参照してください。 |
この項では、次の項目について説明します。
SoD有効環境で実行されるプロビジョニング操作では、次の一連の手順が行われます。
プロビジョニング操作によって、適切なアダプタがトリガーされます。
アダプタが、プロビジョニング・データをターゲット・システム上の対応するBAPIに渡します。
OIMユーザーにプロビジョニングされるアカウントまたは権限を選択すると、SoDチェックが開始します。SoDCheckerタスクが、ユーザー・アカウントと権限の詳細を職務リストのフォームでOracle Application Access Controls Governorに送信します。つまり、SoD検証プロセスが非同期で行われます。
ユーザーが、SoDチェック結果の取得(プロビジョニング)またはSoDチェック結果の取得(承認)スケジュール済タスクを実行します。
スケジュール済タスクが、権限データをOracle Application Access Controls GovernorのWebサービスに渡します。
Oracle Application Access Controls Governorが権限データについてSoD検証プロセスを実行した後、プロセスのレスポンスがOracle Identity Managerに返されます。
レスポンスを受け取ったプロセス・タスクのステータスは、レスポンスそのものによって異なります。権限データがSoD検証プロセスを通過すると、プロセス・タスクのステータスが「完了」に変わります。これは、権限がユーザーに付与されることを意味します。SoD検証プロセスから失敗のレスポンスが返されると、プロセス・タスクのステータスは「取消」に変わります。
ダイレクト・プロビジョニングの手法を使用してリソースをプロビジョニングするには、次のようにします。
管理およびユーザー・コンソールにログインします。
ターゲット・システム・アカウントを既存のOIMユーザーにプロビジョニングする場合は、「ユーザー」メニューから「管理」を選択します。
「作成」を選択した場合は、「ユーザーの作成」ページでOIMユーザーのフィールドに値を入力して、「ユーザーの作成」をクリックします。次のスクリーンショットは、「ユーザーの作成」ページを示しています。
「管理」を選択した場合は、OIMユーザーを検索し、検索結果に表示されたユーザー・リストからユーザーのリンクを選択します。
「ユーザーの詳細」ページで、ページの一番上のリストから「リソース・プロファイル」を選択します。次のスクリーンショットは、「ユーザーの詳細」ページを示しています。
「リソース・プロファイル」ページで「新しいリソースのプロビジョニング」をクリックします。次のスクリーンショットは、「リソース・プロファイル」ページを示しています。
「ステップ1: リソースの選択」ページで、プロビジョニングするリソースをリストから選択し、「続行」をクリックします。次のスクリーンショットは、「ステップ1: リソースの選択」ページを示しています。
「ステップ2: リソースの選択の検証」ページで「続行」をクリックします。次のスクリーンショットは、「ステップ2: リソースの選択の検証」ページを示しています。
プロセス・データの「ステップ3: リソース・データの指定」ページで、ターゲット・システムで作成するアカウントの詳細を入力し、「続行」をクリックします。次のスクリーンショットは、追加されたユーザーの詳細を示しています。
職責データの「ステップ3: リソース・データの指定」ページで、アカウントのアプリケーション名、職責名および有効期間開始日を入力し、「追加」をクリックします。複数の職責を追加する場合は、この手順を繰り返します。その後、「続行」をクリックします。次のスクリーンショットにこのページを示します。
ロール・データの「ステップ3: リソース・データの指定」ページで、ロール割当てのアプリケーション名、ロール名および開始日を入力し、「追加」をクリックします。複数のロールを追加する場合は、この手順を繰り返します。その後、「続行」をクリックします。次のスクリーンショットにこのページを示します。
「ステップ4: リソース・データの検証」ページで、指定したデータを確認して「続行」をクリックします。次のスクリーンショットは、「ステップ4: リソース・データの検証」ページを示しています。
「プロビジョニングは開始されています。」メッセージが表示されます。「「ユーザー・リソース・プロファイル」に戻る」をクリックします。「リソース・プロファイル」ページに、リソースがユーザーにプロビジョニングされたことが示されます。次のスクリーンショットにこのページを示します。
「プロセス・フォーム」列の「表示」リンクをクリックすると、プロセス・フォームが表示されます。次のスクリーンショットにこのページを示します。
このスクリーンショットでは、「SODCheckStatus」フィールドにSODCheckPendingが表示されています。このフィールドの値は、SoDCheckResultPendingまたはSoDCheckCompletedになります。
注意: Oracle Identity ManagerがSoD有効ではない場合、「SODCheckStatus」フィールドにはSODCheckNotInitiatedと表示されます。 |
リソースをクリックすると、「リソース・プロビジョニングの詳細」ページが表示されます。次のスクリーンショットにこのページを示します。
このページには、実行したプロセス・タスクの詳細が表示されます。ホルダー・タスクとSODCheckerタスクの状態は「保留」です。これらのタスクの状態は、SoDチェックのステータスがSoDエンジンから返されると変化します。ユーザーへの職責の追加タスクおよびユーザーへのロールの追加タスクは、このユーザーへの割当てのために選択された職責とロールに対応します。
注意: Oracle Application Access Controls GovernorによるSoD検証は非同期です。検証プロセスは完了するとすぐに結果を返します。 |
SoDチェック結果の取得(プロビジョニング)スケジュール済タスクが実行されると、SoD検証プロセスの結果がOracle Identity Managerに渡されます。「プロセス・フォーム」列の「表示」リンクをクリックすると、プロセス・フォームが表示されます。次のスクリーンショットにこのページを示します。
このスクリーンショットでは、「SODCheckStatus」フィールドにSoDCheckCompletedが表示されています。この特定の例では、SoDエンジンで違反が検出されたために、「SoDCheckViolation」フィールドに違反の詳細が表示されます。
また、「リソース・プロビジョニングの詳細」ページに、SODCheckerタスクとホルダー・タスクのステータス「完了」が表示されます。
次のスクリーンショットにこのページを示します。
このスクリーンショットでは、ユーザー・ロールの追加タスクのステータスは、リクエストがSoD検証プロセスを通過しなかったため「取消」になっています。
リソースをユーザーに割り当てる管理者は、違反が検出されたときにプロセスを停止するか、割当てデータを変更して再送信することができます。割当てデータを変更するには、まず「リソース・プロファイル」ページの「プロセス・フォーム」列の「編集」リンクをクリックします。
表示される「フォームの編集」ウィンドウで、前に選択したロールとプロファイルのデータを変更することができます。
注意: 「フォームの編集」ウィンドウで一連の権限を変更するには、まずすべての権限を削除してから、使用する権限を追加してください。 |
次のスクリーンショットでは、前に選択したロールの1つが削除対象としてマークされています。
SoDチェック結果の取得(プロビジョニング)スケジュール済タスクを再実行して、SoD検証プロセスを開始します。
SoDチェック結果の取得(プロビジョニング)スケジュール済タスクが実行されると、SoD検証プロセスの結果がOracle Identity Managerに渡されます。「プロセス・フォーム」列の「表示」リンクをクリックすると、プロセス・フォームが表示されます。次のスクリーンショットにこのページを示します。
このスクリーンショットでは、「SODCheckStatus」フィールドにSoDCheckCompletedが表示されています。SoDエンジンで違反が検出されなかったため、「SoDCheckResult」フィールドには「パス」
と表示されます。
また、「リソース・プロビジョニングの詳細」ページに、SODCheckerタスクとホルダー・タスクのステータス「完了」が表示されます。
次のスクリーンショットにこのページを示します。
「リソース・プロビジョニングの詳細」ページでは、ユーザーへのロールの追加タスクの状態が「完了」になります。
リクエストベースのプロビジョニング操作には、エンドユーザーと承認者の両方が関係します。通常、承認者はリクエスト発行者の上司です。この項で説明するリクエストベースのプロビジョニング・プロセスは、両者が実行するステップを含んでいます。
この項の例では、エンドユーザーがターゲット・システムの2つのロールに対するリクエストを作成します。リクエストはSoD検証を通過し、承認者によって承認されます。
リクエストベースのプロビジョニングでのエンドユーザーの役割
リクエストベースのプロビジョニングのタイプは次のとおりです。
アカウントのリクエストベースのプロビジョニング: OIMユーザーが作成されますが、作成時にターゲット・システム・リソースはプロビジョニングされません。かわりに、ユーザー自身がアカウントのプロビジョニングのリクエストを発行します。
権限のリクエストベースのプロビジョニング: (ダイレクト・プロビジョニングまたはリクエストベース・プロビジョニングによって)ターゲット・システム・リソースがプロビジョニングされたOIMユーザーが、権限のプロビジョニングのリクエストを発行します。
次の手順は、リクエストベースのプロビジョニング操作でエンドユーザーによって実行されます。
注意: リクエストベース・プロビジョニングの手順はアカウントと権限でほぼ同じです。相違点は次の手順の中で示しています。 |
管理およびユーザー・コンソールにログインします。
「マイ・リソース」を展開し、「新しいリソースのリクエスト」をクリックします。
「ステップ1: リソースの指定」ページで、「追加」ボタンを使用して次のいずれかを選択します。
eBusiness Suiteユーザー: ターゲット・システム・アカウントのリクエストを作成する場合
eBusiness Suiteユーザーの職責またはeBusiness Suiteユーザーのロール: ターゲット・システムの権限のリクエストを作成する場合
次のスクリーンショットでは、eBusiness Suiteユーザーの職責権限が選択されています。
「ステップ2: リソース・データの指定」ページで、「続行」をクリックします。
次のスクリーンショットにこのページを示します。
「ステップ2: リソース・データの指定」ページの2ページ目で、選択した権限を設定するターゲット・システム・インストールに対応するITリソースを選択します。
次のスクリーンショットにこのページを示します。
「ステップ2: リソース・データの指定」ページの3ページ目で、職責データを追加するために、職責のアプリケーション名、職責名、有効期間開始日を指定し、「追加」をクリックします。複数の職責を追加する場合は、この手順を繰り返します。その後、「続行」をクリックします。
次のスクリーンショットでは、このページで2つのロールが選択されています。
「ステップ3: 情報の検証」ページで、指定した情報を確認し、リクエストを送信します。次のスクリーンショットにこのページを示します。
「すぐに送信」をクリックすると、「リクエストが送信されました」ページにリクエストIDが表示されます。次のスクリーンショットにこのページを示します。
リクエストIDをクリックすると、「リクエストの詳細」ページが表示されます。次のスクリーンショットにこのページを示します。
このスクリーンショットでは、「SODCheckStatus」フィールドにSODCheckPendingが表示されています。このフィールドの値は、SoDCheckResultPendingまたはSoDCheckCompletedになります。
注意: Oracle Identity ManagerがSoD有効ではない場合、「SODCheckStatus」フィールドにはSODCheckNotInitiatedと表示されます。 |
承認の詳細を表示するには、ページの一番上のリストから「承認タスク」を選択します。「承認タスク」ページが表示されます。次のスクリーンショットにこのページを示します。
このページでは、SODCheckerタスクのステータスは「保留」です。
保留中の権限リクエストのSoD検証を開始するには、承認者がSoDチェック結果の取得(承認)スケジュール済タスクを実行する必要があります。
SoDチェック結果の取得(承認)スケジュール済タスクが実行されると、「承認タスク」ページでは、SODCheckerタスクのステータスが「完了」になり、「承認」タスクのステータスが「保留」になります。このページには、このときリクエストを承認する必要がある管理者の詳細も表示されます。
次のスクリーンショットは、リクエストがSoD検証プロセスを通過した後の「承認タスク」ページを示します。
リクエストベースのプロビジョニングでの承認者の役割
この項では、リクエストベースのプロビジョニング操作での承認者の役割について説明します。
リクエストが割り当てられている承認者は、「保留中の承認」機能を使用してリクエストの詳細を確認することができます。
また、承認者は「表示」リンクをクリックして、SoD検証プロセスの詳細を確認できます。
承認者は、SoDエンジンがリクエストを受け入れたか拒否したかに関係なく、リクエストの承認または拒否を決めることができます。承認者はリクエストの権限を変更することもできます。
次に、承認者が実行できる手順について説明します。
承認者がリクエストを編集または承認するには「編集」リンクをクリックします。
「フォームの編集」ウィンドウで、変更する権限リクエスト・データをウィンドウの一番上のリストから選択し、必要な変更を行います。次のスクリーンショットでは、リクエスト発行者がリクエストに含めたロールの1つが削除されています。
「フォームの編集」ウィンドウを閉じ、承認するタスクのチェック・ボックスを選択して、「承認」をクリックします。
「確認」ページで、「確認」をクリックします。
次のスクリーンショットにこのページを示します。
「リクエストの詳細」ページで、SoDステータス列に「SODCheckCompleted」と表示されます。
リクエスト送信者のプロファイルを検索して開くと、そのユーザーに付与された権限が「プロビジョニング済」の状態であることが表示されます。これを次のスクリーンショットに示します。