ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity Manager管理者ガイド
11g リリース2 (11.1.2.2.0)
B69535-08
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

6 アイデンティティの証明の管理

この章では、アイデンティティの証明に関連する概念、アイデンティティの証明に必要な構成タスクについて説明します。内容は次のとおりです。

6.1 証明の概念

アイデンティティの証明に関連する概念について、次の各項で説明します。

6.1.1 ライン・オブ・ビジネスと明細項目

LOBとは、業界またはビジネスの機能のカテゴリです。たとえば、LOBマネージャは、販売など、企業内のビジネス機能に向けられています。

明細項目とは、証明の1ページ目に表示されるデータの行です。各明細項目には、証明のタイプに従って、特定のアイデンティティまたは権限に関連する一連の権限割当てが収集されるか、またはまとめられます。レビューアは、任意の明細項目を開いて、その明細項目の詳細を表示できます。たとえば、ユーザー証明のフェーズ1の中では、各明細項目はユーザーを表しています。ユーザーの詳細を開くと、そのユーザーのアクセス権限が表示されます。

6.1.2 証明タスク

証明タスクは、証明プロセスの中で行う一連の作業で構成されています。あるレビューアに割り当てられている明細項目の各セットによって、サービス指向アーキテクチャ(SOA)のタスクが開始されます。このタスクは、特定の明細項目セットを含み、そのレビューアのSOA受信箱にルーティングされます。SOAコンポーネントはまた、レビューアに対し、そのレビューアに証明タスクが割り当てられたことを通知します。

6.1.3 証明オブジェクト

証明オブジェクトとは、生成され、特定の証明者または主要なレビューアに割り当てられる証明です。各証明オブジェクトの構成は次のとおりです。

  • 一意の証明ID

  • 一連の明細項目で、それぞれの明細項目には一連の詳細が含まれている

6.1.4 証明の定義

証明の定義とは、名前を付けられたパラメータ・セットで、このセットは、証明オブジェクトを生成するための証明ジョブへの入力として使用されます。証明の定義で指定されるものは次のとおりです。

  • 生成する証明のタイプ(ユーザー証明、ロール証明、アプリケーション・インスタンス証明、権限証明など)

  • どの明細項目(たとえばユーザー)を選択するかを記述した選択基準

  • 各明細項目でどの詳細を選択するかを記述したコンテンツ制限基準

  • 証明オブジェクトの生成またはレビュー・タスクの動作を制御する、その他のパラメータ

6.1.5 証明ジョブ

証明ジョブは、リクエストに応じて、またはスケジュール設定されたものとして、証明を作成するために使用されます。証明ジョブとは、バックグラウンドで実行されるタスクで、このタスクでは、指定された証明の定義に基づいて証明オブジェクトを生成します。証明ジョブに対してできる操作は次のとおりです。

  • 必要に応じて、毎週、毎月、毎四半期など、一定の間隔で実行するようにスケジュール設定する

  • Oracle Identity System Administrationの「スケジューラ」セクションからただちに実行する

  • イベント・リスナーのアクションからトリガーする

証明生成ジョブを作成および実行し、リクエストに応じて、またはスケジュール設定されたものとして、証明を作成できます。リスク集計ジョブを有効にして実行し、ユーザー、アカウント、ロール割当て、権限割当てなどのエンティティのリスク値を計算できます。

6.1.6 クローズド・ループ是正

クローズド・ループ是正とは、Oracle Identity Managerのプロビジョニング・システムを利用し、Oracle Identity Managerの証明プロセスの結果に基づいて、アカウント、ロールおよび権限を自動的に失効させる機能です。

6.1.7 是正の追跡

リクエスト・カタログを使用して、失効されたアカウント、アカウント内のアクセスまたはロールの是正ステータスを追跡します。これは、それぞれの失効リクエストが満たされているかどうか、またいつ満たされたかを記録します。

6.1.8 イベント・リスナー

イベント・リスナーとは、ユーザーの変更に対応するサービスです。イベント・リスナーは、すべての証明タイプでサポートされています。

証明に対する各イベント・リスナーの構成は次のとおりです。

  • 管理者によって指定される選択基準

  • 対応して使用する証明の定義

6.1.9 証明の認可

次に示すOracle Identity Managerの管理ロールにより、証明機能の管理および証明インスタンスの進捗のモニターに必要な権限が、割当て先に付与されます。

  • 証明管理者: 証明管理者の管理ロールにより、証明機能に対するスーパーユーザー権限が、割当て先に付与されます。特に、この管理ロールでは、Oracle Identity Manager System Administrationにおける証明構成およびスケジューラに対するアクセス権限が付与されます。このロールでは、証明に対する完全なアクセス権も付与され、いずれの証明に対しても、表示やアクションの実行が可能となります。

  • 証明ビューア: 証明ビューアは読取り専用のロールで、このロールが付与されたコンプライアンス管理者は、新規、進行中および完成した証明を表示できます。

証明管理者および証明ビューアの管理ロールの権限および関係付けられた認可ポリシーの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のセキュリティ・アーキテクチャに関する項を参照してください。

6.2 証明の構成

この項には次のトピックが含まれます:

6.2.1 証明を構成するための前提条件

証明を構成する際に前提条件となるステップは次のとおりです。


注意:

構成前のステップの一部では、リクエスト・カタログを使用することが必要になります。リクエスト・カタログの詳細は、次の各項を参照してください。

6.2.1.1 カタログ項目を証明可能とマーク

ユーザー・アカウント、ロール割当て、ロール・メンバーシップ、アプリケーション・インスタンス、権限などのリクエスト可能エンティティは、リクエスト・カタログで証明可能とマークされた後でのみ証明に使用できます。証明可能とマークされていないエンティティは、証明には表示されません。

エンティティを証明可能とマークする手順は次のとおりです。

  1. Oracle Identity Self Serviceにログインします。

  2. 左ペインの「リクエスト」で、「カタログ」をクリックします。

  3. 証明可能と設定するロール、アプリケーション・インスタンスまたは権限を検索して選択します。

  4. 「詳細情報」で「証明可能」オプションを選択します。

  5. 「適用」をクリックします。


注意:

デフォルトでは、カタログ内の項目はすべて、証明可能とマークされています。そのエンティティに対して証明タスクを生成しない場合は、「証明可能」オプションの選択を解除できます。

6.2.1.2 リクエスト・カタログでの証明者の設定

あるユーザーをエンティティの証明者に設定し、「ロール証明者」や「アプリケーション・インスタンス証明者」など、レビューアを選択するためのオプションのいくつかを選択すると、そのユーザーは自動的に、そのエンティティを証明するための証明者または主要なレビューアに設定されます。たとえば、ユーザーJohn Doeが、ビジョン開発者ロールの証明者として選択されている場合、証明作成の「レビューア」画面での選択に応じて、John Doeは、ビジョン開発者ロールを証明する際の主要なレビューアに自動的に設定されます。この例では、そのユーザーがビジョン開発者ロールの証明者に設定された後、ロール証明の作成時に、「ロール証明者」オプションを選択すると、このフィールドが取得されます。


注意:

「ロール証明者」や「アプリケーション・インスタンス証明者」など、証明作成画面でレビューアを選択するためのオプションのいくつかを使用する場合には、リクエスト・カタログで証明者を設定することが必要になります。

カタログでの証明者を設定する手順は次のとおりです。

  1. Oracle Identity Self Serviceで「カタログ」ページに移動します。

  2. 証明者を設定するロール、アプリケーション・インスタンスまたは権限を検索して選択します。

  3. 「証明者ユーザー」フィールドの参照アイコンをクリックします。参照から、選択したエンティティの証明者に設定するユーザーを検索して選択します。


    注意:

    カタログの「詳細情報」セクションに用意されている「証明者ロール」フィールドは、Oracle Identity Manager 11gリリース2 (11.1.2.2.0)では使用されません。

  4. 「適用」をクリックします。

6.2.1.3 ユーザー・マネージャおよび組織証明者の設定

ユーザー・マネージャおよび組織証明者は、証明作成プロセスにおいて、主要なレビューアとして選択できます。

ユーザー・マネージャとは、Oracle Identity Self Serviceで、「ユーザーの詳細」ページの「属性」タブの「マネージャ」フィールドで選択されたユーザーです。Jane DoeがTerence Hillのマネージャに指定されている場合、「証明の定義の作成」で説明しているように、ユーザー証明の定義を作成するときにこのユーザー・マネージャを主要なレビューアに選択すると、Jane Doeは、Terence Hillに対して生成される証明タスクの主要なレビューアに自動的に設定されます。

組織証明者とは、Oracle Identity Self Serviceで、「組織の詳細」ページの「属性」タブの「証明者ユーザー・ログイン」フィールドで選択されたユーザーです。Robert KleinがVision North組織の組織証明者に指定されている場合、証明の定義を作成するときに組織証明者を主要なレビューアに選択すると、Robert Kleinは、Vision Northに対して生成される証明タスクの主要なレビューアに自動的に設定されます。


注意:

  • 「レビューア」オプションとして「ユーザー・マネージャ」または「組織証明者」を使用する場合には、ユーザー・マネージャまたは組織証明者を設定することが必要になります。それ以外の場合は不要です。

  • ロールの組織証明者は、「階層対応」オプションをサポートしせん。組織証明者の場合、そのロールは組織内に用意されている必要があります。言い換えれば、ロールには具体的な組織が指定されている必要があります。それ以外の場合は、証明は生成されません。ロールと組織がリンクされていて、組織には証明者ユーザーが割り当てられているようにしてください。


6.2.1.4 個々のエンティティのリスク・レベルの設定

個々のエンティティのリスク・レベルを設定する手順は次のとおりです。

  1. Oracle Identity Self Serviceで「カタログ」ページに移動します。

  2. リスク・レベルを設定するロール、アプリケーション・インスタンスまたは権限を検索して選択します。

  3. 「詳細情報」の「リスク・レベル」リストから、「高リスク」「中リスク」または「低リスク」を選択します。

  4. 「適用」をクリックします。

個々のエンティティのリスク・レベルを設定したら、リスク集計スケジュール済ジョブを実行して、新しい証明の作成時に新しいリスク・レベルが適切に選択されるようにする必要があります。既存の証明オブジェクトには、新しいリスク・レベルが反映されないことに注意してください。

6.2.1.5 属性のタグ付け

Design Consoleで、証明のためにアカウント、ITリソースおよび権限にタグを付ける必要があります。タグを付けなかったら、エンティティの証明は生成されません。

アカウントおよびITリソースのタグ付けを構成する手順は次のとおりです。

  1. Design Consoleにログインします。

  2. 「開発ツール」で「フォーム・デザイナ」をクリックします。

  3. 最上部にある検索アイコンをクリックします。「フォーム・デザイナ」表が表示され、使用可能なすべてのフォームのリストが示されます。

  4. 子プロセス・フォームを開き、「新しいバージョンの作成」をクリックします。

  5. 「プロパティ」タブをクリックします。

  6. フォームごとに権限フィールドを1つのみ探して「プロパティの追加」をクリックし、Entitlement = trueプロパティ設定を追加します。

    権限の子フォームが複数ある場合は、権限フォームごとにEntitlement = trueプロパティ設定を1つ追加します。

  7. 子フォームを保存してバージョンをアクティブにするをクリックします。


    注意:

    子フォームが複数ある場合は、ステップ4から7を繰り返すことによって、それらの子フォームのすべてを更新してから次のステップに進んでください。

  8. インストールされているコネクタごとに親フォームを選択します。親フォームには、UD_ADUSERやUD_EBS_USERなどのアカウント名をターゲット・システムに格納するための「ユーザーID」フィールドがあります。

  9. フォームを選択します。新しい「フォーム・デザイナ」タブが開きます。

  10. 「新しいバージョンの作成」をクリックします。ポップアップで名前(たとえばv2)を入力します。保存アイコンをクリックします。ポップアップを閉じます。

  11. 「現在」バージョン・リストで、新規作成したバージョンv2が選択されていることを確認します。

  12. 「プロパティ」タブをクリックします。

  13. ターゲット・システム内のアカウントを一意に特定するフィールドを探します。このフィールドには、UserID、UserName、AccountNameなどがあり、これらはデフォルトのコネクタで代表的なフィールドです。「プロパティの追加」をクリックし、AccountName = trueプロパティ設定を追加します。

  14. ITリソース・フィールドを探します。ほとんどのコネクタでは、これは、ターゲット・システムのプロパティとしてのテキストITResourceLookupFieldで識別されます。「プロパティの追加」をクリックし、ITResource = trueプロパティ設定を追加します。

  15. 親フォームを保存します。「バージョンをアクティブにする」をクリックします。

  16. ITリソースごとにステップ3から11を繰り返します。

6.2.1.6 アイデンティティ証明の可用性の構成

Oracle Identity Managerでは、レガシーのアテステーション機能とともに、アイデンティティ証明機能を使用できます。また、アテステーションと証明のいずれかを使用しない場合は、その機能を非表示にすることもできます。証明とアテステーションの使用を構成するには、「証明またはアテステーションを表示」システム・プロパティに次の値のいずれかを指定します。

  • both: この値は、アテステーションおよびアイデンティティ証明のナビゲーション・メニューとページがすべて、Oracle Identity Self ServiceとOracle Identity System Administrationで表示されることを示します。

  • attestation: デフォルト値です。この値は、アテステーション機能のみを使用できることおよび、アイデンティティ証明のナビゲーション・メニューとページがすべて、Oracle Identity Self ServiceとOracle Identity System Administrationで非表示になることを示します。

  • certification: この値は、アイデンティティ証明機能のみを使用できること、および、アテステーションのナビゲーション・メニューとページがすべて、Oracle Identity Self ServiceとOracle Identity System Administrationで非表示になることを示します。


注意:

「証明またはアテステーションを表示」システム・プロパティの値にbothまたはcertificationを設定するには、認証コンポーネントのライセンスが必要です。

このシステム・プロパティの値の設定後は、Oracle Identity Managerを再起動する必要があります。


注意:

システム・プロパティおよびシステム・プロパティの値の設定については、「システム・プロパティの管理」を参照してください。

6.2.1.7 証明のリマインダ、通知、エスカレーションおよび有効期限の構成(省略可能)

「SOA電子メール通知の構成」で説明されているように、電子メール通知がSOAで構成されている場合は、電子メール通知は、デフォルトで次のシナリオで送信されます。

  • タスクがユーザーに割り当てられた場合

  • タスクが完了した場合

デフォルトでは、証明が作成されてから1日後と2日後に、リマインダが1件ずつ送信されます。デフォルトでは、証明に対してエスカレーションも有効期限も設定されていません。

証明に対するデフォルトの構成を変更する手順は次のとおりです。

  1. weblogicなどの管理資格証明を使用してOracle SOA Composerにログインします。そのためには、次のURLに移動します。

    http://HOST_NAME:PORT_NUMBER/soa/composer

  2. 「オープン」をクリックし、「タスクを開く」を選択します。「開くタスクの選択」ダイアログ・ボックスが表示されます。

  3. 「CertificationProcess_rev1.0」を選択し、「オープン」をクリックします。「CertificationTask : イベント駆動構成」ページが表示されます。

  4. 「通知設定」セクションで、次の操作を行います。

    1. タスクの割当て先は、割当てタスクおよび完了タスクの通知の受信者として選択されています。デフォルト設定を変更するために、「タスク・ステータス」列でタスクのステータスを選択し、「受信者」列で通知の受信者を選択することができます。デフォルトの通知メッセージを編集するタスクごとに鉛筆アイコンをクリックし、「OK」をクリックできます。

    2. 次のドロップダウンで、リマインダのデフォルト設定を変更します。

  5. 「有効期限およびエスカレーション・ポリシー」セクションで、エスカレーションおよび有効期限のデフォルト値を変更できます。

  6. 「OK」をクリックします。

  7. 「保存」をクリックし、「コミット」をクリックします。

6.2.2 Identity System Administrationでの証明オプションの構成

証明のタイプに基づく証明作成時に使用される、Oracle Identity System Administrationでのデフォルトのオプションを設定できます。これらのオプションは、証明の定義ごとの証明作成プロセスで変更できます。

Identity System Administrationで証明オプションを構成する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「証明構成」をクリックします。「証明構成」ページが表示されます。

  2. 表6-1にリストされているように、構成プロパティを設定します。


    注意:

    表6-1にリストされているすべてのオプションにより、証明のタイプに基づく証明作成時に選択されるデフォルトの構成が設定されます。これらは、証明の定義ごとの証明作成プロセスで変更できます。

    表6-1 構成プロパティ

    プロパティ 説明

    サインオフ時にパスワードが必要

    証明を完了するためにユーザーにサインオフさせる必要がある場合に選択します。

    証明操作に対するコメントを許可

    証明操作が選択されているときに、ユーザーがコメントを入力できるようにする場合に選択します。デフォルトでは、コメントが必要です。

    証明以外のすべての操作に対するコメントを許可

    失効操作が選択されているときに、ユーザーがコメントを入力できるようにする場合に選択します。デフォルトでは、コメントが必要です。

    従業員のアクセスを確認

    ユーザー証明ビューでページ1を表示するかどうかを制御する場合に選択します。デフォルトで、このオプションは選択されています。このオプションは、ユーザー証明で使用されます。

    自己証明の防止

    レビューアが自分のアクセス権を証明できないようにする場合に選択します。このオプションを有効にすると、証明作成者は、証明を他のレビューアに割り当てることができます。

    「自己証明の防止」が有効になっていると、デフォルトで「ユーザー・マネージャ」オプションが選択されます。これは、割当て先がユーザーのマネージャになるということです。

    他のユーザーを選択するには、「ユーザーの選択」を選択します。検索アイコンをクリックし、他のレビューアを検索して選択します。

    ユーザーとアカウントの選択

    次のいずれかを選択します。

    • アクティブなユーザーとアクティブなアカウントのみを含める:

    • アクティブなアカウントがあるユーザーを含める:

    • すべてのユーザーとすべてのアカウントを含める:

    拡張委任の許可

    明細項目を他の人たちに委任する機能を有効にする場合に選択します。このオプションは、デフォルトでは選択されていません。

    委任が有効になっているときには検証ステージがあり、そこでは、委任のすべての意思決定、および最終的なサインオフに向けての主要なレビューア自身の意思決定とともに、証明が主要なレビューアにルーティングされます。

    複数フェーズ・レビューの許可

    共同証明を有効にする場合に選択します。共同証明のフェーズ1ではビジネス・レビューが完了され、それに続くフェーズ2ではテクニカル・レビューが行われ、場合によってはその後で最終レビューが行われます。この最終レビューは、再びビジネス・レビューアが完了します。これは、ユーザー証明でのみ使用されます。

    再割当ての許可

    証明のページ1に含まれる明細項目を別のユーザーに再割当てする機能を有効にする場合に選択します。明細項目が再割当てされると、それらの項目は証明タスクから削除され、元の証明オブジェクトのレビュー・サイクルでは表示されなくなります。再割当てされた明細項目を含む新しい証明オブジェクトが作成されます。新しい割当て先が、新しい証明オブジェクトのプライマリ・レビューアになります。

    自動要求の許可

    ページ1内の項目をすべて、デフォルトで要求されるようにマークする場合に選択します。デフォルトでは、自動要求は有効になっています。このオプションの選択を解除した場合、ユーザーは各項目を手動で要求する必要があります。この操作を行うと、項目詳細を表示できるようになります。

    クローズド・ループ型の是正を実行

    証明が完了したときにクローズド・ループ型の是正を指定する場合に選択します。

    インタラクティブExcelの有効化

    ユーザー証明にADFデスクトップ統合(DI)を有効化する場合に選択します。このDIは、証明データをMicrosoft Excelワークシートにダウンロードし、オフライン・モードで操作するというオプションをユーザーに提供するものです。オフライン・モードでの証明の操作については、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のオフライン・モードでのユーザー証明の完了に関する項を参照してください。

    証明レポートの有効化

    証明レポートの作成を有効にして、「証明」ダッシュボードの「詳細情報」セクションに「レポート」タブを表示する場合に選択します。

    コンポジット名

    証明ワークフローのSOAコンポジットを選択します。デフォルトのコンポジットは、default/CertificationProcessです。他のバージョンのコンポジットを選択すると、証明ワークフローで証明の監視を有効化できます。これを行うには、CertificationOverseerProcessコンポジットを選択します。このコンポジットにより、レビューアのマネージャが証明プロセスの監督者になることを指定します。


  3. 「保存」をクリックします。

6.3 証明の定義の管理

この項には次のトピックが含まれます:

6.3.1 証明の定義の作成

証明の定義の作成については、以降の項で説明します。

6.3.1.1 ユーザー証明の定義の作成

ユーザー証明の定義を作成する手順は次のとおりです。

  1. Oracle Identity System Administrationにログインします。

  2. 左ペインの「証明」で、「証明の定義」をクリックします。「証明の定義」ページが表示されます。

  3. 「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「新規証明」ウィザードの「一般の詳細」ページが表示されます。

  4. 次の値を入力します。

    • 証明名: 証明の名前を入力します。

    • タイプ: ユーザー証明を作成する場合は「ユーザー」を選択します。

    • 説明: 必要に応じて、新規のユーザー証明の説明を入力します。

  5. 「次へ」をクリックします。「新規証明」ウィザードの「基本選択」ページが表示されます。

  6. 「基本選択」セクションで、次のようにユーザー選択戦略を選択します。

    • すべての組織のユーザー: Oracle Identity Manager内のすべての組織からユーザーを選択します。

    • 選択した組織のユーザーのみ: 特定の組織を手動で選択できます。「追加」をクリックすることによって、組織を選択できます。選択した組織を削除するには、「削除」をクリックします。


      注意:

      証明の完了時、証明者には、組織の組織管理者でもある場合を除き、組織名など、その組織の詳細はわかりません。証明者が組織証明者でない場合は、その組織内のユーザーのみが表示されます。

    • すべてのユーザー: Oracle Identity Manager内のすべてのユーザーを選択します。

    • ユーザー基準: 指定された検索条件を満たすすべてのユーザーを選択します。検索については、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のユーザーの検索に関する項を参照してください。この選択の結果はプレビューできます。

    • 選択したユーザー: システム内のユーザーのリストから、特定のユーザーを選択できます。ユーザーを選択するには、「追加」をクリックします。選択したユーザーを削除するには、「削除」をクリックします。

  7. 基本選択に対する制約を指定するには、次のオプションのいずれかを選択します。

    • 任意のレベルのリスクを持つユーザー

    • 高リスクのサマリーを持つユーザーのみ

    • 高リスクのロールを持つユーザーのみ

    • 高リスクのアプリケーション・インスタンスを持つユーザーのみ

    • 高リスクの権限を持つユーザーのみ

  8. 「次へ」をクリックします。「コンテンツ選択」ページが表示されます。

  9. 次を選択します。

    • アカウントのないユーザーを含む: このオプションには、証明内にアクセス権のないユーザーが含まれます。

    • ユーザーごとに証明するロール割当てを制限します。: ユーザーごとのロールのリストは、選択されたオプションに制限できます。たとえば、選択されたロールを選択し、1つのロールを追加した場合、そのロールは、カタログで証明可能とマークされている場合にのみ証明内に表示され、それは、ユーザーに他のロールが付与されている場合でも同じです。

    • 証明可能な属性のないアカウントを含む: これには、選択されたアプリケーション・インスタンス内のアカウントが含まれ、それは、ターゲット・システム内に証明可能な権限(アクセス権)がない場合でも同じですこのオプションの選択を解除した場合、ターゲット・システム内にあるアカウントのうち、権限が付与されていないものは、証明内に表示されません。

    • ユーザーごとに証明するアプリケーションインスタンス割当てを制限します。: ロールと同様に、証明内に表示するアプリケーション・インスタンスを制限できます。

    • ユーザーごとに証明する権限割当てを制限します。: 証明内に表示できる権限を制限できます。

  10. 「次へ」をクリックします。「構成」ページが表示されます。

  11. 表6-1「構成プロパティ」で説明されているように、目的のオプションを選択して「次」をクリックします。「レビューア」ページが表示されます。

    拡張委任とともに複数フェーズ・レビューを有効にする場合は、「拡張委任の許可」オプションと「複数フェーズ・レビューの許可」オプションを選択します。

    証明ワークフローで証明の監視を有効にする場合は、検索アイコンをクリックし、使用可能なコンポジットを検索して、CertificationOverseerProcessコンポジットを選択してから「追加」をクリックします。

  12. 「レビューア」リストから、主要なレビューアを選択します。主要なレビューアは、ユーザー・マネージャや組織証明者など、選択した任意のユーザーにできます。

    複数フェーズ・レビューの場合は、次の操作を行います。

    1. 「フェーズ1」セクションで、次のいずれかを選択してフェーズ1のレビューアを選択します。

      • ユーザー・マネージャ: ユーザーのマネージャをフェーズ1のレビューアに選択します。

      • 組織証明者: 組織証明者をフェーズ1のレビューアに選択します。

      • ユーザーの検索: 参照アイコンをクリックすることによって、任意のユーザーを、検索して指定するフェーズ1のレビューアに選択します。

    2. 「フェーズ2 (オプション)」セクションで、「フェーズ2レビュー・プロセスの有効化」オプションを選択して、ロール割当て、アカウント割当て、権限割当てなどのユーザー権限ごとに、特権証明者がフェーズ2の主要なレビューアになることを指定します。

    3. 「最終レビュー(オプション)」セクションで、「最終レビュー・プロセスの有効化」オプションを選択して、最終的な検証およびサインオフに向けて、フェーズ1のレビューアによる最終レビュー・プロセスを有効にします。

  13. 「次へ」をクリックします。「増分」ページが表示されます。

  14. 「増分データの生成」で「有効」を選択します。この設定では、証明者は、証明または失効の対象を、証明に対して行われた変更または包含のみにできます。証明されたユーザーのアクセス権をレビューする必要はなくなります。

    増分証明が有効になっている場合は、次のパラメータが取られます。

    • 増分日付範囲(必須): 次のものが含まれます。

      • 最後のベース以降(デフォルト): このオプションが選択されていると、ユーザーの現在のアクセスが、増分を有効にしないで作成された同じタイプの前回の証明、およびそれ以降で証明が作成された現在日付までのすべての増分証明に対して比較されます。

      • 開始日: このオプションが選択されていると、ユーザーの現在のアクセスが、指定された日付以降で証明が作成された時点での、同じタイプの証明すべてに対して比較されます。

    • 以前の値を表示(オプション): 次のものが含まれます。

      • 無効(デフォルト): この選択が解除されていると、「増分日付範囲」パラメータに基づいて前の証明にすでに表示されていた値は、証明に含まれません。

      • 有効: これが選択されていると、前の証明に存在していたすべての現在値が、これらのアクセスに対して前回行われた意思決定とともに表示されます。

  15. 「次へ」をクリックします。「サマリー」ページが、ユーザー証明の詳細とともに表示されます。

  16. 「作成」をクリックして、ユーザー証明を作成します。メッセージが表示され、定義に基づいて証明ジョブを作成し、すぐに実行するかどうか尋ねられます。ジョブ名を編集し、「はい」をクリックして証明ジョブを実行できます。

    または、「いいえ」をクリックし、スケジュール設定されたジョブの作成と実行をしないで、証明の定義を作成します。このオプションを使用した場合は、証明ジョブを後で手動で作成する必要があります。

    新規のユーザー証明の定義は、「証明の定義」ページに表示されます。


注意:

拡張委任を使用した複数フェーズ・レビューの場合は、次のようになります。
  • 証明が100%完了となるのは、フェーズ2のレビューアまたはテクニカル・レビューアがすべてのレビューを完了したときです。2フェーズ・レビューにおいて、証明が行われているフェーズごとに、フェーズと完了の進捗度(パーセンテージ)が証明ステータスに表示されます。このステータスを表示するには、「受信箱」または「ダッシュボード」で「進行中」証明をクリックします。

  • 証明は、最終レビューのためにフェーズ1の主要なレビューアに渡されます。ページ2では、フェーズ1の主要なレビューアが、(グレー表示されている)最初と2番目のフェーズでユーザーの行ったアクション、およびシステムで生成されたデフォルトのアクション(フェーズ1の主要なレビューアによる無効化が可能)をレビューできます。


6.3.1.2 ロール証明の定義の作成

ロール証明の定義を作成する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「証明の定義」をクリックします。「証明の定義」ページが表示されます。

  2. 「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「新規証明」ウィザードの「一般の詳細」ページが表示されます。

  3. 次の値を入力します。

    • 名前: 証明の名前を入力します。

    • タイプ: ロール証明の定義を作成する場合は「ロール」を選択します。

    • 説明: 必要に応じて、新規のロール証明の定義の説明を入力します。

  4. 「次へ」をクリックします。「新規証明」ウィザードの「基本選択」ページが表示されます。

  5. このページの「基本選択」セクションで、次に示すように、リストからロール選択戦略を選択します。

    • すべての組織のすべてのロール: Oracle Identity Manager内のすべての組織のすべてのロールを選択します。

    • 選択した組織のロール: 指定した組織からロールを選択します。「追加」をクリックし、組織を検索して選択します。選択した組織を削除するには、「削除」をクリックします。


      注意:

      証明の完了時、証明者には、組織管理者でもある場合を除き、組織名など、その組織の詳細はわかりません。証明者が組織証明者でない場合は、その組織内のユーザーのみが表示されます。

    • すべてのロール: Oracle Identity Manager内のすべてのロールを選択します。

    • ロール基準: 指定された検索条件を満たすすべてのロールを選択します。この選択の結果はプレビューできます。


      ヒント:

      この検索を保存しておき、別のロール証明の定義を作成する際、ロール基準の指定に使用できます。保存された検索は、特定の証明にマップされません。別のロール証明の定義に、ロール基準の保存済検索を使用する手順は次のとおりです。
      1. 証明書の作成中、「ロール基準」オプションを選択して検索基準を指定したら、「結果の更新とプレビュー」をクリックする必要があります。これにより、選択した基準が定義に関連付けられます。

      2. この検索基準をテンプレートとして保存する場合は、「保存」をクリックします。保存しているテンプレートの名前を入力するように求められます。次に、このテンプレートを保存して再利用できます。

      3. 保存されたテンプレートは、ある証明に固有のものではありません。別の証明の作成中は、このテンプレートがデフォルトで表示されます。別のテンプレートを新規作成した場合は、そのテンプレートが表示されます。言い換えると、あるタイプの証明に関連付けられたすべての基準画面には、最新のテンプレートが表示されます。

      4. 生成されたテンプレートを使用しない場合は、保存済検索リスト内の値を、使用するものに変更します。


    • 選択したロール: ロールを手動で選択できます。

  6. 制約を指定するには、次のオプションのいずれかを選択します。

    • 任意のレベルのリスクを持つロール:

    • 高リスクのロールのみ:

  7. 「次へ」をクリックします。「コンテンツ選択」ページが表示されます。

  8. 「ポリシーの証明」を選択して、ポリシーの証明を指定します。「メンバーの証明」を選択して、ロール・メンバーの証明を指定します。

  9. 「次へ」をクリックします。「構成」ページが表示されます。

  10. 表6-1「構成プロパティ」で説明されているように、構成のオプションを選択して「次」をクリックします。「レビューア」ページが表示されます。

    「レビューア」リストから、主要なレビューアを選択します。主要なレビューアは、権限証明者やロール証明者など、選択した任意のユーザーにできます。

  11. 「次へ」をクリックします。「増分」ページが表示されます。

  12. 「増分データの生成」で「有効」を選択します。この設定では、証明者は、証明または失効の対象を、証明に対して行われた変更または包含のみにできます。証明されたユーザーのアクセス権をレビューする必要はなくなります。

    増分証明が有効になっている場合は、次のパラメータが取られます。

    • 増分日付範囲(必須): 次のものが含まれます。

      • 最後のベース以降(デフォルト): このオプションが選択されていると、ユーザーの現在のアクセスが、増分を有効にしないで作成された同じタイプの前回の証明、およびそれ以降で証明が作成された現在日付までのすべての増分証明に対して比較されます。

      • 開始日: このオプションが選択されていると、ユーザーの現在のアクセスが、指定された日付以降で証明が作成された時点での、同じタイプの証明すべてに対して比較されます。

    • 以前の値を表示(オプション): 次のものが含まれます。

      • 無効(デフォルト): この選択が解除されていると、「増分日付範囲」パラメータに基づいて前の証明にすでに表示されていた値は、証明に含まれません。

      • 有効: これが選択されていると、前の証明に存在していたすべての現在値が、これらのアクセスに対して前回行われた意思決定とともに表示されます。

  13. 「次へ」をクリックします。「サマリー」ページが、ユーザー証明の詳細とともに表示されます。

  14. 「作成」をクリックします。メッセージが表示され、定義に基づいて証明ジョブを作成し、すぐに実行するかどうか尋ねられます。ジョブ名を編集し、「はい」をクリックして証明ジョブを実行できます。

    または、「いいえ」をクリックし、スケジュール設定されたジョブの作成と実行をしないで、証明の定義を作成します。このオプションを使用した場合は、証明ジョブを後で手動で作成する必要があります。

    新規のロール証明の定義は、「証明の定義」ページに表示されます。

6.3.1.3 アプリケーション・インスタンス証明の定義の作成

アプリケーション・インスタンス証明の定義を作成する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「証明の定義」をクリックします。「証明の定義」ページが表示されます。

  2. 「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「新規証明」ウィザードの「一般の詳細」ページが表示されます。

  3. 次の値を入力します。

    • 名前: 証明の名前を入力します。

    • タイプ: アプリケーション・インスタンス証明の定義を作成する場合は「アプリケーション・インスタンス」を選択します。

    • 説明: 必要に応じて、新規のアプリケーション・インスタンス証明の定義の説明を入力します。

  4. 「次へ」をクリックします。「新規証明」ウィザードの「基本選択」ページが表示されます。

  5. このページの「基本選択」セクションで、次に示すように、リストからアプリケーション・インスタンス選択戦略を選択します。

    • すべてのアプリケーション・インスタンス: Oracle Identity Manager内のすべてのアプリケーション・インスタンスを選択します。

    • 選択したアプリケーション・インスタンスのみ: アプリケーション・インスタンスを手動で選択できます。「追加」をクリックし、アプリケーション・インスタンスを検索して選択します。選択した任意のアプリケーション・インスタンスを削除するには、「削除」をクリックします。

  6. 制約を指定するには、次のオプションのいずれかを選択します。

    • 任意のレベルのリスクを持つアプリケーション・インスタンス

    • 高リスクのアプリケーション・インスタンスのみ

  7. 「次へ」をクリックします。「コンテンツ選択」ページが表示されます。

  8. 次のいずれかを選択します。

    • すべての組織のユーザーのアカウント: Oracle Identity Manager内のすべての組織からユーザーのアカウントを選択します。

    • 選択した組織のユーザーのアカウント: ユーザーのアカウントを証明対象とする組織を手動で選択できます。

    • すべてのユーザーのアカウント: Oracle Identity Manager内のすべてのユーザーのアカウントを選択します。

    • 選択したユーザーのアカウント: アカウントを証明対象とするユーザーを手動で選択できます。

  9. 「次へ」をクリックします。「構成」ページが表示されます。

  10. 表6-1「構成プロパティ」で説明されているように、構成のオプションを選択して「次」をクリックします。「レビューア」ページが表示されます。

  11. 「レビューア」リストから、主要なレビューアを選択します。主要なレビューアは、アプリケーション・インスタンス証明者、ユーザー・マネージャ、組織証明者など、選択した任意のユーザーにできます。

  12. 「次へ」をクリックします。「増分」ページが表示されます。

  13. 「増分データの生成」で「有効」を選択します。この設定では、証明者は、証明または失効の対象を、証明に対して行われた変更または包含のみにできます。証明されたユーザーのアクセス権をレビューする必要はなくなります。

    増分証明が有効になっている場合は、次のパラメータが取られます。

    • 増分日付範囲(必須): 次のものが含まれます。

      • 最後のベース以降(デフォルト): このオプションが選択されていると、ユーザーの現在のアクセスが、増分を有効にしないで作成された同じタイプの前回の証明、およびそれ以降で証明が作成された現在日付までのすべての増分証明に対して比較されます。

      • 開始日: このオプションが選択されていると、ユーザーの現在のアクセスが、指定された日付以降で証明が作成された時点での、同じタイプの証明すべてに対して比較されます。

    • 以前の値を表示(オプション): 次のものが含まれます。

      • 無効(デフォルト): この選択が解除されていると、「増分日付範囲」パラメータに基づいて前の証明にすでに表示されていた値は、証明に含まれません。

      • 有効: これが選択されていると、前の証明に存在していたすべての現在値が、これらのアクセスに対して前回行われた意思決定とともに表示されます。

  14. 「次へ」をクリックします。「サマリー」ページが、ユーザー証明の詳細とともに表示されます。

  15. 「作成」をクリックします。メッセージが表示され、定義に基づいて証明ジョブを作成し、すぐに実行するかどうか尋ねられます。ジョブ名を編集し、「はい」をクリックして証明ジョブを実行できます。

    または、「いいえ」をクリックし、スケジュール設定されたジョブの作成と実行をしないで、証明の定義を作成します。このオプションを使用した場合は、証明ジョブを後で手動で作成する必要があります。

    新規のアプリケーション・インスタンス証明の定義は、「証明の定義」ページに表示されます。

6.3.1.4 権限証明の定義の作成

権限証明の定義を作成する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「証明の定義」をクリックします。「証明の定義」ページが表示されます。

  2. 「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「新規証明」ウィザードの「一般の詳細」ページが表示されます。

  3. 次の値を入力します。

    • 名前: 証明の名前を入力します。

    • タイプ: 権限証明の定義を作成する場合は「権限」を選択します。

    • 説明: 必要に応じて、新規の権限証明の定義の説明を入力します。

  4. 「次へ」をクリックします。「新規証明」ウィザードの「基本選択」ページが表示されます。

  5. このページの「権限選択戦略」セクションで、次に示すように、リストからロール選択戦略を選択します。

    • 選択した権限: 権限を手動で選択できます。「追加」をクリックし、権限を検索して選択します。選択した任意の権限を削除するには、「削除」をクリックします。

    • 選択した証明者が存在するすべての権限: ユーザーがカタログ内の証明者ユーザーであるすべての権限を含めて、ユーザーのリストを選択できます。

    • すべての権限: カタログからすべての権限を選択できます。

    • 権限の基準: 基準に基づいて権限を選択できます。

  6. 制約を指定するには、次のオプションのいずれかを選択します。

    • 任意のレベルのリスクを持つ権限

    • 高リスクの権限のみ

  7. 「次へ」をクリックします。「コンテンツ選択」ページが表示されます。

  8. 「次へ」をクリックします。「構成」ページが表示されます。

  9. 表6-1「構成プロパティ」で説明されているように、構成のオプションを選択して「次」をクリックします。「レビューア」ページが表示されます。

  10. 「レビューア」リストから、主要なレビューアを選択します。主要なレビューアは、権限証明者など、選択した任意のユーザーにできます。

  11. 「次へ」をクリックします。「増分」ページが表示されます。

  12. 「増分データの生成」で「有効」を選択します。この設定では、証明者は、証明または失効の対象を、証明に対して行われた変更または包含のみにできます。証明されたユーザーのアクセス権をレビューする必要はなくなります。

    増分証明が有効になっている場合は、次のパラメータが取られます。

    • 増分日付範囲(必須): 次のものが含まれます。

      • 最後のベース以降(デフォルト): このオプションが選択されていると、ユーザーの現在のアクセスが、増分を有効にしないで作成された同じタイプの前回の証明、およびそれ以降で証明が作成された現在日付までのすべての増分証明に対して比較されます。

      • 開始日: このオプションが選択されていると、ユーザーの現在のアクセスが、指定された日付以降で証明が作成された時点での、同じタイプの証明すべてに対して比較されます。

    • 以前の値を表示(オプション): 次のものが含まれます。

      • 無効(デフォルト): この選択が解除されていると、「増分日付範囲」パラメータに基づいて前の証明にすでに表示されていた値は、証明に含まれません。

      • 有効: これが選択されていると、前の証明に存在していたすべての現在値が、これらのアクセスに対して前回行われた意思決定とともに表示されます。

  13. 「次へ」をクリックします。「サマリー」ページが、ユーザー証明の詳細とともに表示されます。

  14. 「作成」をクリックします。メッセージが表示され、定義に基づいて証明ジョブを作成し、すぐに実行するかどうか尋ねられます。ジョブ名を編集し、「はい」をクリックして証明ジョブを実行できます。

    または、「いいえ」をクリックし、スケジュール設定されたジョブの作成と実行をしないで、証明の定義を作成します。このオプションを使用した場合は、証明ジョブを後で手動で作成する必要があります。

    新規の権限証明の定義は、「証明の定義」ページに表示されます。

6.3.2 証明の定義の変更

証明の定義を変更する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「証明の定義」をクリックします。「証明の定義」ページが、すべての証明の定義のリストとともに表示されます。

  2. 変更する証明の定義を選択します。


    注意:

    この定義に結び付けられている、定期的にスケジュール設定されたタスクがある場合は、そのスケジュール設定されたタスクの次回実行は、修正後の変更を使用して実行されます。

  3. 「アクション」メニューから「編集」を選択します。または、ツールバーにある「編集」をクリックします。

    メッセージが表示されて、スケジュール設定されたジョブおよびイベント・リスナーによって定義が参照されることが述べられ、確認が求められます。このメッセージは、証明ジョブを作成していない証明の定義を編集しようとした場合には表示されません。

  4. 「編集」をクリックして確定します。「証明の定義」ページが表示され、そこでフィールドの値を編集できます。

  5. 「次」ボタンと「戻る」ボタンをクリックすることによってページ間を移動し、フィールドを編集して証明の定義を変更します。

  6. 終了したら、「保存」をクリックします。メッセージが表示され、定義が正常に更新されたことが述べられます。

  7. 「OK」をクリックします。

6.3.3 証明の定義の削除

証明の定義を削除する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「証明の定義」をクリックします。「証明の定義」ページが、すべての証明の定義のリストとともに表示されます。

  2. 削除する証明の定義を選択します。

  3. 「アクション」メニューから「削除」を選択します。または、ツールバーにある「削除」をクリックします。

    メッセージが表示されて、スケジュール設定されたジョブおよびイベント・リスナーによって定義が参照されることが述べられ、確認が求められます。このメッセージは、証明ジョブを作成していない証明の定義を削除しようとした場合には表示されません。

  4. 「削除」をクリックして確認します。確認を求めるメッセージが表示されます。

  5. 「OK」をクリックします。

6.4 証明のスケジュール設定

証明は、証明作成プロセスの一環としてスケジュール設定されます。詳細は、「証明の定義の作成」を参照してください。証明は、一度実行するようにスケジュール設定することも、毎日、毎週または毎月繰り返すようにスケジュール設定することもできます。


注意:

証明の定義を作成する必要があり、作成が済んだらスケジュール設定できます。「証明の定義の作成」を参照してください。

「新規証明」ウィザードの「サマリー」ページで「作成」をクリックして証明の定義を作成したら、メッセージが表示され、証明ジョブを作成して実行するかどうか尋ねられます。スケジュール設定されたジョブ名は「ジョブ名」ボックスで編集できます。「はい」をクリックすると、新規証明の定義用に証明ジョブが作成されて実行されます。Oracle Identity System Administrationの「スケジューラ」セクションに移動してジョブを検索できます。ジョブのデフォルト名はCert_DEFINITION_NAMEです。

証明ジョブは、証明作成タスクというスケジュール済タスクに基づいて作成されます。このスケジュール済タスクは、定義された証明の定義用に証明ジョブを新規作成するために使用されます。ジョブが実行されると、証明の定義が使用され、証明が生成されます。

証明作成タスクというスケジュール済タスクについては、「事前定義済のスケジュール済タスク」を参照してください。証明ジョブは、Oracle Identity System Administrationの「スケジューラ」セクションから変更できます。詳細は、「ジョブの変更」を参照してください。

証明は、Oracle Identity System Administrationの「スケジューラ」セクションからスケジュール設定することもできます。そのためには、「ジョブの作成」に示す手順に従ってください。この方法では、「ジョブの作成」ページの「タスク」フィールドで証明作成タスクを選択します。

証明ジョブを変更するときには、「ジョブの詳細」ページの「証明の定義名」フィールドで証明の定義名を指定します。

6.5 リスク・サマリーの計算の理解

ロール、アプリケーション・インスタンスおよび権限に、また事前定義された特定のリスク係数に、高、中、低の各リスク・レベルを直接割り当てることができます。リスク集計ジョブでは、アイデンティティ証明をサポートするために必要な、レベルの高い残りのデータ・オブジェクトのリスクのサマリーが計算されます。これらのオブジェクトには、Oracle Identity Managerにおけるあらゆるユーザー、ユーザー・ロール割当て、アカウントおよび権限割当てが含まれます。アイデンティティ証明中に、証明者はリスクのサマリーを使用して、高リスクの証明項目を中リスクおよび低リスクの項目から切り離します。

この項では、システムがリスク・レベルをどのように処理してリスクのサマリーを導き出すかについて説明します。また、リスク集計ジョブについても説明します。このジョブは、手動で実行することも、スケジュールを設定して実行することもできます。


注意:

ロール、アプリケーション・インスタンスおよび権限がメタデータ・オブジェクトであるのに対し、ユーザー、アカウントおよび権限割当てはインスタンスデータ・オブジェクトです。

メタデータ・オブジェクトが、Oracle Identity Manager内の情報システムを表して記述した構造化オブジェクトであるのに対し、インスタンスデータ・オブジェクトは、システムに移入するアプリケーション・データの個別インスタンスです。たとえば、ロールが事前定義されていて、それによりユーザーがトラブル・チケット(権限)を作成できるカスタマ・サービス・アプリケーション(リソース)を考えてみます。この例では、1つのリソース・オブジェクトはアプリケーションを表し、1つの権限オブジェクトはそのアプリケーション内の特定の権限を表しています。

このリソースには膨大な数のユーザー・アカウントがある場合があり、そのうちの一部のサブセットには権限割当てがあり、それによってユーザーがトラブル・チケットを作成できると考えてみましょう。1つのリソース(メタデータ・オブジェクト)には複数のアカウント(インスタンスデータ・オブジェクト)が存在する場合があり、1つの権限(メタデータ・オブジェクト)には複数の割当てインスタンス(インスタンスデータ・オブジェクト)が存在する場合があります。Oracle Identity Managerでは、インスタンスデータ・オブジェクトのリスク・レベルが計算されます。あらゆるユーザー、アカウントおよび権限割当てのリスク・レベルを人間が繰り返し処理するというのは現実的でないからです。


6.5.1 項目リスクとリスク係数のマッピングの理解

項目リスクとリスク係数のマッピングは、直接制御の対象となる設定です。

6.5.1.1 項目リスクの設定

項目リスクとは、特定のロール、アプリケーション・インスタンスおよび権限に対して、様々な管理者が割り当てることのできるリスク・レベルのことです。


注意:

3つの帯は高リスク、2つの帯は中リスク、1つの帯は低リスクを示しています。

メタデータ・オブジェクトに項目リスク・レベルを直接割り当てない場合は、Oracle Identity Managerによって、デフォルトの項目リスク・レベルが割り当てられます。ロール、アプリケーション・インスタンス、権限それぞれにデフォルト値を設定できます。

メタデータ・オブジェクトのデフォルトの項目リスク・レベルを設定する手順は次のとおりです。

  1. Oracle Identity System Administrationにログインします。

  2. 左ペインの「証明」で、「リスク構成」をクリックします。

  3. 項目ごとに、「高」、「中」、「低」いずれかのリスクのラジオ・ボタンを選択します。

  4. 「保存」をクリックします。

高度に制限された権限をユーザーに付与するメタデータ・オブジェクトに対して、項目リスクの高レベルを予約する必要があります。オブジェクトに項目リスクの高レベルを設定すると、その親オブジェクトの「リスクのサマリー」にも高い値が設定されることに注意してください。同様に、オブジェクトに項目リスクの中レベルを設定すると、その親オブジェクトの「リスクのサマリー」に中以上の値が設定されます。レベルの高いオブジェクトに「リスクのサマリー」の低い値を設定するには、システム階層でその下にあるオブジェクトのすべてに低リスクを設定する必要があります。

6.5.1.2 リスク・レベルのマッピング(リスク係数)の理解

リスク係数のマッピングとは、事前定義された特定の条件にリスク・レベルをマップする設定です。たとえば、「オープン監査違反を有する項目」を高リスクとして構成し、「受けいれられたリスクとしてクローズされた項目」を中リスクとして構成するようなことがあります。

一般的に言えば、不規則または危険となる可能性のあるユーザーに権限が拡張される状況に対して、リスク係数の高いレベルを予約する必要があります。

Oracle Identity Managerにはリスク係数のカテゴリが3つあり、それぞれのカテゴリには複数の設定が含まれています。リスク係数のカテゴリについては、次の表で説明します。

表6-2 リスク係数

リスク係数 説明

プロビジョニング・シナリオ/割当てのシナリオ

プロビジョニング・シナリオは、ロール、アカウントまたは権限割当てをユーザーに割り当てる際に使用される方法またはメカニズムに関連付ける必要のあるリスク・レベルを定義します。

たとえば、管理者によって直接プロビジョニングされるオブジェクトには、リスク・レベルとして「中」を構成し、ロールに関連付けられているポリシーに基づいてプロビジョニングされるオブジェクトには、リスク・レベルとして「低」を構成するとします。リコンシリエーションを介してOracle Identity Managerに引き込まれるオブジェクトには、リスク・レベルとして「高」を構成するとします。

前回の証明アクション

検討中のアカウント、権限割当てまたはユーザー・ロール割当ての前回証明のステータスに基づいて、リスク・レベルを定義します。

たとえば、前回の証明決定が承認することであった任意の項目には、リスク・レベルとして「低」を構成し、前回の証明決定が「条件付きで証明」であった任意の項目には、リスク・レベルとして「中」を構成するとします。最後に、前回の証明決定が「棄権」または「失効」であった任意の項目には、値として「高」を構成するとします。



注意:

UIの「構成」ページでリスク・レベルのマッピングを変更すると、大きなさざ波効果が発生する可能性があり、発生したらOracle Identity Manager全体で「リスクのサマリー」に影響を与えます。初期設定において、「リスク・レベル」構成ページでマッピングを構成し、不要な変更を追加しなくて済むようにする必要があります。「リスクのサマリー」に影響を与えるさざ波効果の詳細は、「リスク構成値の変更がシステムに与える影響の理解」を参照してください。

6.5.2 リスク集計とリスクのサマリーの理解

リスク集計タスクというスケジュール済ジョブでは、項目リスク・レベルとリスク係数レベルが処理され、アイデンティティ証明をサポートするレベルの高いオブジェクトごとに、リスクのサマリーが計算されます。

リスク集計タスクは、事前定義済のリスク集計ジョブに情報を提供するために使用されます。このタスクを使用してジョブを新規作成する必要はありません。このタスク・タイプのジョブが実行されたら、Oracle Identity Manager内のすべてのユーザーの、前回更新以後のリスクが計算されます。このスケジュール済タスクの詳細は、「事前定義済のスケジュール済タスク」を参照してください。リスク集計タスクというスケジュール済ジョブは、「ジョブの無効化と有効化」に示す手順に従って有効化することができます。

リスク集計の最初のフェーズでは、リスク集計タスクというスケジュール済ジョブにより、それぞれの個別オブジェクトの項目リスク・レベルおよびその3つのリスク係数レベルが評価され、4つのうち最も高いレベルがオブジェクトの「リスクのサマリー」プロパティに割り当てられます。個別のユーザー・オブジェクト、ユーザー・ロール割当てオブジェクト、アカウント・オブジェクトおよび権限割当てオブジェクトごとに、リスクのサマリーの値が計算されます。次のダイアグラムに、このプロセスを示します。

oiaad_dt_001.gifについては周囲のテキストで説明しています。

あらゆるオブジェクトのリスクのサマリーが計算されたら、次の集計フェーズが開始されます。このフェーズでは、個別のオブジェクトそれぞれのリスクのサマリーが合算されて、そのオブジェクトを含む親オブジェクトのリスクのサマリーになります。

権限割当てレベルの上で、各データ・オブジェクトのリスクのサマリーの値が、そのオブジェクトを含む親オブジェクトのリスクのサマリーにつながります。たとえば、アカウント・オブジェクトは権限割当てオブジェクトより1階層上のレベルであり、ユーザー・オブジェクトはそこからさらに1階層上のレベルです。したがって、アカウント・オブジェクト内のあらゆる権限割当てオブジェクトのリスクのサマリーは、そのアカウントのリスクのサマリーにつながり、同様に、ユーザー・オブジェクト内のあらゆるアカウント・オブジェクトのリスクのサマリーは、そのユーザーのリスクのサマリーにつながります。

ユーザー・オブジェクトはまた、ユーザー・ロール割当てオブジェクトより1つ上のレベルなので、あらゆるユーザー・ロール割当てオブジェクトのリスクのサマリーは、そのユーザーのリスクのサマリーにつながります。

次のダイアグラムに、このプロセスを示します。

oiaad_dt_002.gifについては周囲のテキストで説明しています。

このダイアグラムでは、権限割当てのリスクのサマリーの値が合算されて、アカウント・オブジェクトになります。アカウントのリスクのサマリーの値とユーザー・ロール割当てのリスクのサマリーの値が合算されて、関連付けられている任意のユーザーのリスクのサマリーになります。

6.5.3 リスク構成値の変更がシステムに与える影響の理解

リスクのサマリーの値に影響を与える可能性のあるアクションまたはシステム・イベントが、大きく分けて3つあります。この影響は、アクションまたはシステム・イベントに応じて、軽度、中程度または重度となります。それぞれのアクションまたはイベントおよびその結果を、次の表で説明します。

表6-3 リスクのサマリーの値に影響を与える可能性のあるアクションまたはシステム・イベント

アクションまたはイベント 影響 説明

ユーザーまたはOracle Identity Manager、あるいはその両方が、個別の権限を変更する

軽度

アカウント、権限、ユーザー・ロール割当てなど、個別のデータ・オブジェクトに対する変更に該当します。これらの値は、頻繁に変化することが考えられます。たとえば、このカテゴリに含まれる変更のタイプは次のとおりです。

  • 権限がアカウントに追加されるか、またはアカウントから削除されます。

  • アカウントがユーザーに追加されるか、またはユーザーから削除されます。

  • ロール割当てがユーザーに追加されるか、またはユーザーから削除されます。

  • 個別のデータ・オブジェクトに対するリスク係数が変化します。

Oracle Identity Manager内での影響は相対的に小さなものとなります。変化は個別の各権限のレベルで発生するからです。

管理者が、ロール、リソースおよび権限に対して項目リスクの変更を行う

中程度

ロール、アプリケーション・インスタンスまたは権限のリスク・レベルを、様々な管理者が変更するという状況に該当します。

これらの変更のさざ波効果は、大きなものとなる可能性があります。メタデータ・オブジェクトに対するリスク・レベルを変更すると、そのメタデータ・オブジェクトに関連付けられているあらゆるデータオブジェクトに対する項目リスク・レベルが変更される場合があります。データオブジェクトに対するリスク・レベルを変更すると、そのリスクのサマリー、さらに、そのデータオブジェクトを含む他のあらゆるデータオブジェクトのリスクのサマリーに影響が及ぶ場合があります。

たとえば、権限定義に対するリスク・レベルを変更すると、その権限定義に対応するその権限のあらゆる割当てに対する項目リスクが変更されます。権限割当てに対する項目リスクを変更すると、そのリスクのサマリーが変更される場合があります。権限割当てのリスクのサマリーを変更すると、親アカウントのリスクのサマリーに影響が及ぶ場合があります。アカウントのリスクのサマリーを変更すると、そのアカウントを所有するユーザーのリスクのサマリーに影響が及ぶ場合があります。

管理者が、リスク・レベルのマッピングに対して構成の変更を行う

重度

Oracle Identity System Administrationの「リスク構成」ページでリスク・レベルのマッピングを、様々な管理者が変更するという状況に該当します。

特定のリスク係数の特定の値に関連付けられているリスク・レベルを変更すると、そのリスク係数の値を持つ、任意のユーザー・ロール割当て、アカウントまたは権限割当てのリスクのサマリーに影響が及ぶ可能性があります。任意のユーザー・ロール割当て、アカウントまたは権限割当てのリスクのサマリーを変更すると、影響を受けるユーザー・ロール割当て、アカウントまたは権限割当てに関連付けられるあらゆるユーザーに影響が及ぶ可能性があります。

このため、リスクレベルのマッピングを変更するのは、ごくまれにしてください。


6.6 クローズド・ループ是正および是正の追跡の理解

クローズド・ループ是正とは、証明プロセス中にロールおよび権限が失効される結果として、プロビジョニング・ソリューションからロールおよび権限を直接失効させることを可能にする機能です。

証明が完了し、主要なレビュー・タスクがすべてサインオフされたら、Oracle Identity Managerでは、失効させることを最終決定としていたユーザーおよび権限をすべて削除しようとします。リクエストが作成されることによって、失効される任意のロール割当ての割当てが解除され、失効される任意のアカウントのプロビジョニングが解除され、失効される任意の権限割当てが削除され、失効される任意のユーザーが削除または無効化されます。具体的には、次のようになります。

  • ユーザーを失効させると、そのユーザーが削除/無効化され、そのユーザーの権限がすべて削除されます。

  • ユーザーのロール割当てを失効させると、そのメンバーがロールから削除されます。これにより、最終的に、ロールによって付与されているアカウントおよび権限割当てが、プロビジョニングによって削除される場合があります(これらのアカウントおよび権限割当てが、そのユーザーに別の方法で付与されていない場合)。

  • ユーザーのアカウントを失効させると、そのアカウントが削除/無効化されます。そのアカウントに関連付けられている権限割当てがあれば、これによって暗黙的に削除/無効化されます。

  • ユーザーの権限割当てを失効させると、その割当てを含むアカウントから割当てが削除されます。

是正ステータスは、監査を目的として、リクエスト・カタログで追跡できます。それぞれの是正リクエストには、そのリクエストを生成した証明の証明IDが含まれており、それにより、ダッシュボードはOracle Identity Self Serviceの「リクエストのトラッキング」ページにリンクして、表示されている証明に関連付けられているすべてのリクエストのステータスを表示できます。

6.6.1 チャレンジ・ワークフローの構成

デフォルトでは、クローズド・ループ是正は次のように機能します。

  • 証明書をサインオフした人間(最終レビューア)がユーザー(受益者)のマネージャである場合は、リクエストは自動承認されます。

  • 最終レビューアがユーザーのマネージャでない場合は、リクエストはチャレンジ・ワークフローを通過していきます。具体的には次のように処理されます。

    1. アクセスが失効されているユーザー(受益者)にリクエストが送信されます。

    2. 受益者がリクエストを承認することによって失効を受け入れた場合には、クローズド・ループ是正が発生してアクセスが失効されます。

    3. 受益者がリクエストを却下することによって失効に異議を申し立てた場合には、証明をサインオフした人間(最終レビューア)にリクエストが返送されます。

      1. 最終レビューアがこの異議申立てを受け入れた場合には、プロセスは停止し、受益者のアクセスは失効されません。

      2. 最終レビューアがこの異議申立てを却下した場合には、クローズド・ループ是正が発生してアクセスが失効されます。

このロジックは、ルールを使用することによって、SOAのDefaultRequestApprovalコンポジット内で定義されます。すべてのクローズド・ループ是正リクエストが自動承認されるようにルールを変更できます。これを行うには、次のようにします。

  1. weblogicなどの管理資格証明を使用してOracle SOA Composerにログインします。そのためには、次のURLに移動します。

    http://HOST_NAME:PORT_NUMBER/soa/composer

  2. 「開く」をクリックし、「ルールを開く」を選択します。「開くディクショナリの選択」ダイアログ・ボックスが表示されます。

  3. DefaultRequestApproval_rev2.0コンポジットに対して、「コンテンツ」列で「Ruleset1」をクリックします。

  4. 「編集」をクリックします。

  5. 図6-1に示すように、Rule 1を展開します。

    図6-1 自動承認のルール

    図6-1の説明が続きます
    「図6-1 自動承認のルール」の説明

  6. 「THEN」の下で鉛筆アイコンをクリックします。

  7. ポップアップで、値を「challenge」からautoに変更します。この値では、すべてのクローズド・ループ是正リクエストが自動承認されることが指定され、チャレンジ・ワークフローは呼び出されません。

  8. 「OK」をクリックします。

  9. 「保存」をクリックし、「コミット」をクリックします。

6.7 イベント・リスナーの理解

イベント・リスナー・メカニズムによって、特定のビジネス・イベントが検出され、イベントの詳細が証明のために格納されます。格納されたイベントの詳細は、証明イベント・トリガーと呼ばれ、スケジュール済ジョブとして実行される証明イベント・トリガー・タスクによって、証明に加工されます。イベント・リスナーによって現在検出されているビジネス・イベントは、個別または一括による、OIMユーザーの変更です。

「証明の定義の管理」で説明しているように、いずれのイベント・リスナーにも、ルールセットと証明の定義が含まれています。ルールセットには1つ以上のルールが含まれており、それぞれのルールは1つ以上の条件をテストし、その条件が満たされた場合に行うアクションを指定しています。イベント・リスナーのルールに対する標準的なアクションは、証明イベント・トリガーを格納することであり、このトリガーによって特定されるのは、イベント・リスナー、変更されたユーザー、およびこのイベントに対応して生成される証明の定義です。

トリガーは、証明イベント・トリガー・ジョブの実行と実行の間に蓄積されます。ジョブが実行されると、そのイベント・リスナーの識別子によってグループ分けされ、対応するイベント・リスナーのプロパティに従って、各グループが処理されます。デフォルトでは、トリガー・ジョブにより、証明のテンプレートにリスナーの証明の定義を使用して、トリガーの各グループにおけるすべてのユーザーの証明が作成されます。この後で、完成したグループ内のトリガーが削除されます。

イベント・リスナーのトリガーがトリガー・ジョブによってどのように処理されるかに影響を与えるプロパティがいくつかあります。最初のプロパティによって、リスナーがアクティブな状態にあるか無効な状態にあるかが判別されます。リスナーが無効になっている場合は、ビジネス・イベントが発生したときにルールが評価されなくなるため、そのリスナーからトリガーは格納されません。リスナーがトリガーを格納してから無効になった場合は、次のトリガー・ジョブが実行され、格納されたトリガーは処理されずに削除されます。無効になっているリスナーが元のアクティブな状態に設定されると、トリガー・ジョブによって処理されるトリガーをもう一度格納できます。

トリガーの処理に影響を与える別のイベント・リスナーのプロパティは、そのイベント数です。これは、トリガー・ジョブの1回の実行中に、そのリスナーでいくつのトリガーを処理できるかを制限するものです。この設定はオプションです。これが指定されていない場合は、その数字は無制限です。イベント数が指定されている場合は、処理できるトリガーの最大数を表しています。トリガー・ジョブが実行されると、トリガーのバッチごとのリスナーのイベント数がチェックされ、トリガーの数がイベント数を超えている場合は、トリガーが破棄され、証明も生成されません。この機能は、ユーザーが一括で変更されたときに、膨大な数の証明が作成されないようにする際に役立ちます。

最終的に、トリガー・ジョブ自体は、特定のイベント・リスナーからのトリガーを処理し、それ以外のものは処理しないように構成できます。この機能は、イベント・リスナー名リストという、証明イベント・トリガー・タスクのパラメータによって制御されます。トリガー・ジョブの定義においてこのパラメータが空白のままになっている場合は、トリガー・ジョブが実行されたときに、すべてのリストからのトリガーが処理されます。名前リストが定義されている場合は、ジョブが実行されたときに、そのリストに含まれているリスナーのトリガーのみが処理されます。他のリスナーからのトリガーは無視され、その後のトリガー・ジョブ実行に備えて保持されます。スケジュール済ジョブの複数のインスタンスが証明イベント・トリガー・タスクに向けて定義されていると、イベント・リスナーの各リストにより、最も適切なスケジュールでトリガーを処理させることができます。


注意:

あるリスナー名が複数のイベント・リスナー名リストに表示されている場合、またはトリガー・ジョブのいずれかに空のイベント・リスナー名リストがある場合は、これらのうち、最初に実行するジョブでは、そのリスナーのトリガーがすべて消費されます。トリガーは、初めて処理された後で常に破棄されます。

6.8 イベント・リスナーおよび証明イベント・トリガー・ジョブの構成

この項には次のトピックが含まれます:

6.8.1 イベント・リスナーの作成

イベント・リスナーを新規作成する手順は次のとおりです。


注意:

イベント・リスナーを作成する前に、証明イベント・トリガー・ジョブが実行されたときに実行される、ユーザー証明の定義またはアプリケーション・インスタンス証明の定義を作成する必要があります。

  1. Oracle Identity System Administrationにログインします。

  2. 左ペインの「証明」で、「イベント・リスナー」をクリックします。「イベント・リスナー」ページが表示されます。

  3. 「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「イベント・リスナーの作成」ページが表示されます。

  4. 「リスナー・プロパティ」セクションで、イベントの識別に使用する名前、および説明を指定します。

  5. 「証明の定義」リストから、実行される証明の定義を選択します。

  6. 「イベント数」ボックスに、証明イベント・トリガー・ジョブが実行された時点でこのリスナーで処理するイベントの最大数を入力します。これは、一括更新のアクションを回避する場合に使用します。

  7. 「ステータス」リストから、ステータスとして「アクティブ」または「無効」を選択します。

  8. 「イベント・トリガー」セクションで、イベントが発生したときに評価される条件を含むルールを追加します。たとえば、ユーザーが更新されたときに、ある条件では、ユーザーのtitleプロパティまたはlocationプロパティが変化したかどうかをチェックできます。別の例としては、ユーザーのマネージャの変更も考えられます。

    条件を追加する手順は次のとおりです。

    1. プラス(+)アイコンをクリックし、「Rule 1」を「Manager Change Condition」のようなルール名に変更します。

    2. 条件の左側にある展開アイコンをクリックします。

    3. 参照アイコンをクリックして、条件ブラウザを開きます。

    4. 「Modified User」「previousValue」をクリックします。「manager」を選択し、「OK」をクリックします。これにより、ModifiedUser.previousValue.Managerと設定されます。

    5. 「次に一致しない」のような条件演算子を選択します。

    6. 2番目の参照アイコンをクリックし、属性名を検索および選択して、「OK」をクリックします。そうすると、次の条件が設定されます。

      ModifiedUser.previousValue.Manager isn't ModifiedUser.currentValue.Manager
      
    7. 「THEN」の下で、「アクションの追加」の左側にあるプラス(+)アイコンをクリックします。

    8. 下矢印キーをクリックして、「call」を選択します。

    9. リストから「certifyThisUser」を選択します。

  9. 「作成」をクリックして、イベント・リスナーを作成します。

証明イベント・トリガー・ジョブが実行されると、マネージャが変更されたユーザーの証明が作成されます。

イベント・リスナーのルールの例としては、ある属性が特定の値に変更されたかどうかをチェックすることが考えられます。例:

ModifiedUser.previousValue.country isn't ModifiedUser.currentValue.country and ModifiedUser.currentValue.country is "Brazil"

ModifiedUser.previousValue.country isn't ModifiedUser.currentValue.countryは、「国」属性に変更があったかどうかをチェックします。変更があると、この条件はTRUEに評価されます。次に、and ModifiedUser.currentValue.country is "Brazil"によって、ルールに2番目の条件が追加されます。これにより、この属性が、「ブラジル」など特定の値に変更されたかどうかがチェックされます。この条件は、ブラジルに異動する従業員に何か特殊な証明が必要な場合に該当します。別の場所に異動した他の従業員の場合は、このルールのアクションはトリガーされません。


注意:

ユーザー定義フィールド(UDF)またはカスタム属性は、現在および以前の値についてのModifiedUserのリストには表示されません。ただし、これらの属性をイベント・リスナーのルール条件に指定することはできます。これを行うには、次の形式でルールの条件フィールドに式を入力します。
ModifiedUser.{current|previous}Value.get{String|Integer|Long|Date|Boolean}Attribute("NAME")

NAMEは、UDFの内部名になります。たとえば、FavoriteColorという名前の文字列値UDFの以前の値を取得するには、次の式を挿入します。

ModifiedUser.previousValue.getStringAttribute("FavoriteColor")

6.8.2 イベント・リスナーの変更

イベント・リスナーを変更する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「イベント・リスナー」をクリックします。「イベント・リスナー」ページが、イベント・リスナーのリストとともに表示されます。

  2. 変更するイベント・リスナーを選択します。

  3. 「アクション」メニューから「編集」を選択します。または、ツールバーにある「編集」をクリックします。イベント・リスナーの詳細ページが表示されます。

  4. イベント・リスナーを変更するフィールドで値を編集します。

  5. 「保存」をクリックします。

6.8.3 イベント・リスナーの削除

イベント・リスナーを削除する手順は次のとおりです。

  1. Oracle Identity System Administrationの左ペインの「証明」で、「イベント・リスナー」をクリックします。「イベント・リスナー」ページが、イベント・リスナーのリストとともに表示されます。

  2. 削除するイベント・リスナーを選択します。

  3. 「アクション」メニューから「削除」を選択します。または、ツールバーにある「削除」をクリックします。確認を求めるメッセージが表示されます。

  4. 「はい」をクリックして確認します。

6.8.4 証明イベント・トリガー・ジョブの構成

「イベント・リスナーの理解」に記述されているように、証明イベント・トリガー・ジョブには、イベント・リスナー名リストというオプションのパラメータが用意されています。このフィールドに1つ以上のイベント・リスナー名が指定されている場合には、トリガー・ジョブでは、それらのリスナーのトリガーのみが処理されます。これは、すべてのリスナーの処理をカバーするには、複数のトリガー・ジョブが必要になるという意味です。次の各項では、このパラメータを設定する方法、および複数のトリガー・ジョブを定義する方法について説明します。次の項で構成されます。

6.8.4.1 イベント・リスナー名リストの設定

イベント・リスナー名リストを設定する手順は次のとおりです。

  1. Oracle Identity System Administrationにログインします。

  2. 左ペインの「システム管理」で、「スケジューラ」をクリックします。

  3. 検索フィールドに「Certification Event Trigger Job」と入力して、検索を実行します。

  4. 検索結果内でジョブ名をクリックし、トリガー・ジョブの詳細を表示します。

  5. 下にスクロールし、「Parameters」セクションまで移動します。そこには、(カンマで区切られた)「Event Listener Name List」というパラメータが表示されています。

  6. 1つ以上のイベント・リスナー名を、カンマで区切ってこのフィールドに入力します。各リスナーの名前は、「イベント・リスナー」表の「名前」列に表示されているとおりに入力するようにしてください。

  7. 「適用」をクリックして変更を保存します。

6.8.4.2 さらなるトリガー・ジョブの追加

証明イベント・トリガー・ジョブの事前定義済インスタンスに加え、次の手順を実行することによって、トリガー・ジョブのインスタンスを新規作成できます。

  1. Oracle Identity System Administrationにログインします。

  2. 左ペインの「システム管理」で、「スケジューラ」をクリックします。

  3. 左ペインの「アクション」メニューから、「作成」を選択します。あるいは、「表示」リストの横のプラス(+)記号が付いたアイコンをクリックします。

  4. 「ジョブの作成」パネルで「タスク」フィールドを、その右側にあるアイコンをクリックして展開します。

  5. 検索フィールドに「Certification Event Trigger Task」と入力して、検索を実行します。

  6. 検索結果で「Certification Event Trigger Task」行をクリックし、「確認」をクリックします。

  7. このトリガー・ジョブのインスタンスに対し、ジョブ名を入力し、スケジュール設定の詳細を記録したければそれも入力します。

  8. 「Event Listener Name List」フィールドに、このトリガー・ジョブのインスタンスで処理するリスナー名のリストを、カンマで区切って入力します。

トリガー・ジョブのいずれのインスタンスでも、独自のスケジュールを設定することも、手動で実行することもできます。また、指定されたリスナー・サブセットに対するトリガーの操作に制限することもできます。このため、別の間隔で別のイベント・リスナーをトリガーできます。

6.9 証明レポートの構成

Oracle BI Publisherには証明レポートが実装されています。


注意:

  • BI Publisherには、Oracle Identity Managerのレポートをデプロイする必要があります。デフォルトの証明レポートおよび証明レポートの生成については、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』の証明レポートの生成に関する項を参照してください。

  • BI Publisherの資格証明とURLがOracle Identity Managerに構成されていない場合は、ダッシュボードの「レポート」タブも、「証明」ページの「PDFにエクスポート」オプションも「Excelにエクスポート」オプションも使用できません。


BI PublisherのURLを構成する手順は次のとおりです。

  1. Oracle Enterprise Managerにログインします。

  2. 「Identity and Access」をクリックします。

  3. OIMクラスタOIMノード「システムMBeanブラウザ」の順に選択します。

  4. システムMBeanブラウザで、「アプリケーション定義のMBean」「oracle.iam」「サーバー: oim server」「アプリケーション: oim」「XMLConfig」「Config」「XMLConfig.DiscoveryConfig」「Discovery」に移動します。

  5. BIPublisherURL属性の値を更新して、BI PublisherのURLを反映させます。

  6. 「適用」をクリックします。

Oracle Identity ManagerでBIPの資格証明を構成する手順は次のとおりです。

  1. Oracle Enterprise Managerにログインします。

  2. 左側のペインで、「WebLogicドメイン」を開きます。ドメイン名が表示されます。

  3. ドメイン名を右クリックし、「セキュリティ」「資格証明」に移動します。oimマップなど、資格証明ストアにおけるマップのリストが表示されます。

  4. oimマップを開きます。Passwordタイプのエントリのリストが表示されます。

  5. 次のように、oim資格証明ストア・マップでCSFエントリを新規作成します。

    • マップの選択: oim

    • キー: BIPWSKey

    • タイプ: Password

    • ユーザー名: ADMINISTRATOR_USER_NAME

    • パスワード: ADMINISTRATOR_PASSWORD

    • 説明: BI Publisher Webサービスのログイン資格証明。

BIPの資格証明とURLの構成後に、管理者は、システム管理にある証明の構成画面に移動して、「証明レポートの有効化」を選択する必要があります。

ダッシュボードの「詳細情報」セクションにある「レポート」タブの表示を構成するには:

  1. Oracle Identity System Administrationにログインします。

  2. 「証明」で「証明構成」をクリックします。「証明構成」ページが表示されます。

  3. 「証明レポートの有効化」オプションを選択します。

  4. 「保存」をクリックします。

レポートは、次の形式で生成できます。

  • PDF

  • RTF

  • HTML

  • Microsoft Excel

  • CSV

6.10 ユーザー証明における複数フェーズ・レビューの理解

共同証明、または拡張委任を使用した2フェーズ・レビュー(TPAD)には、次の機能があります。

  • 2フェーズ・レビュー: 1つの証明の中で、ビジネス指向のレビューアとテクニカル・レビューアのパースペクティブを組み合せることができるようにします。

  • 拡張委任: 証明者が、決定を他の人間に委任しながら、全体的な責任を保持できるようにします。個別の明細項目が1つの証明の中で拡張委任されることによって、レビューアは、同時に作業できる何人かの人たちの間で作業を分散できます。これにより、社内でのアクセスのレビューに責任を負う人たちは、負担を分散できるために、作業をより迅速に完了できます。


注意:

Oracle Identity Managerは、ユーザー証明に対してのみ、TPADをサポートします。TPADは、ロール証明、アプリケーション・インスタンス証明および権限証明に対してはサポートされません。

この項では、TPADについて次の各項で説明します。

6.10.1 複数フェーズによるレビュー

複数フェーズによるレビューでは、同じセットのユーザーアクセス権限に対する複数のパースペクティブを組み合せます。ユーザー証明の場合は、フェーズは次のようになります。

  • ビジネス・レビュー: これは、レビューの第1フェーズで必須です。ビジネス・レビューアは通常、各ユーザーのマネージャであり、ユーザーの証明可能なアクセス権限がすべて、このレビューアの画面に表示されます。最初にマネージャは、そのユーザーが、従業員など、その会社内で有効な権限保持者であることを確認します。次にマネージャは、会社内でのユーザーの地位から考えて、ロール割当て、アカウント割当て、権限割当てなど、ユーザーのアクセス権限が妥当であることを確認します。ビジネス・レビューアは、適切と思われる権限があれば証明または承認し、不要または不適切と思われる権限があれば失効させます。

  • テクニカル・レビュー: これは、レビューの第2フェーズで省略可能です。テクニカル・レビューアは通常、各権限の所有者または認可者であり、権限のメンバーをレビューするか、または特定のユーザーへのその権限の割当て、または特定のユーザーの特定のアカウントへのその権限の割当てをレビューします。テクニカル・レビューアは、適切と思われる権限があれば証明または承認し、不要または不適切と思われる権限があれば失効させます。

  • 最終レビュー: これは、レビューの最終フェーズで省略可能です。最終レビューができるように証明が構成されている場合は、第1フェーズからの主要なレビューア(たとえば、各ユーザーのマネージャ)は、最初の2つのフェーズでレビューアが行った決定を見ることができ、必要に応じてそれらの決定を無効にすることができます。


関連項目:

主要なレビューア、テクニカル・レビューア、最終レビューアおよび委任されたレビューアについては、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のアイデンティティ証明を完了するうえでの関係者に関する項

6.10.2 各フェーズ内での複数のレビューアへの委任

フェーズ1またはフェーズ2での主要なレビューアは、次のようにして、作業を他のユーザーに分散できます。

  • 主要なレビューアは、任意のセットの明細項目に対する責任を、別のユーザーに再割当てすることができます。再割当てでは責任が別の人間に委譲され、委任では責任が主要なレビューアに保持されます。フェーズ1で明細項目を再割当てすると、新しい証明が作成されます。

  • 主要なレビューアは、各明細項目、または任意のセットの明細項目を、主要なレビューアが選択した任意のユーザーに委任できます。このユーザーを、委任されたレビューアと呼びます。明細項目を委任すると、主要なレビューアのタスクではその明細項目が委任済とマークされ、その明細項目に対して主要なレビューアは操作をできなくなります。

  • 主要なレビューアは、証明タスクをサインオフする前であれば、フェーズ内でいつでも、委任された明細項目の委任を解除できます。明細項目の委任を解除すると、その明細項目は委任されたレビューアのタスクから削除され、たとえば、証明決定を行ったり、明細項目の委任または再割当てを行ったりして、その明細項目を操作できるようになります。

フェーズ1またはフェーズ2では、主要なレビューアが明細項目を委任し、少なくとも1つの明細項目が委任されたままでサインオフすると、つまり、主要なレビューアがサインオフする前にそれらの明細項目の一部で委任を解除していない場合は必ず、Oracle Identity Managerによってフェーズ1検証またはフェーズ2検証のレビュー・タスクが生成され、このタスクが主要なレビューアに割り当てられます。このタスクにより、主要なレビューアは、委任されたレビューアがそのフェーズでなんらかの決定を行っていた場合に、その決定を確認したり無効にしたりすることができます。

6.10.3 TPADでの証明のステージ

図6-2は、必須のフェーズ1、省略可能なフェーズ2、およびフェーズ2に依存する省略可能な最終レビュー・フェーズを、条件付きの検証タスクと組み合せることによって、TPADでの証明のステージを示しています。

図6-2 TPADでの証明のステージ

図6-2の説明が続きます
「図6-2 TPADでの証明のステージ」の説明

図6-2に示すように、TPAD証明内でのステージの全体的な流れは次のとおりです。

  1. 開始: 証明が作成され、証明作成タスクというスケジュール済ジョブを実行することによって証明タスクが生成されます。

  2. フェーズ1レビュー: これは常に必須です。

  3. フェーズ1検証: これは、フェーズ1が委任を使用して完了された場合にのみ発生します。

  4. フェーズ2レビュー: これは、構成に応じて省略可能です。

  5. フェーズ2検証: これは、フェーズ2が委任を使用して完了された場合にのみ発生します。

  6. 最終レビュー: これは、構成に応じて省略可能であり、フェーズ2が完了された場合にのみ発生します。

  7. 終了: 証明タスクが完了されました。証明完了の一環として任意のアクセスが失効された場合は、クローズド・ループ是正が発生します。

TPADでの証明ステージは、次の各項で説明します。

6.10.3.1 検証を使用したフェーズ1

図6-3は、TPADを使用した証明レビューの第1フェーズを示しています。

図6-3 検証を使用したフェーズ1

図6-3の説明が続きます
「図6-3 検証を使用したフェーズ1」の説明

次に示すのは、TPADでの検証を使用したフェーズ1のプロセス・フローです。

  1. 開始: 一連の証明オブジェクトが生成され、レビュー・プロセスが開始します。特定の各証明オブジェクト内の明細項目はいずれも、フェーズ1の主要なレビューア(P1PR)に割り当てられています。

  2. タスクP1PR: 証明生成のためのスケジュール済ジョブが実行されると、Oracle Identity Managerではサービス指向アーキテクチャ(SOA)を使用して、証明オブジェクトごとにタスクを作成し、そのタスクが、フェーズ1の主要なレビューア(P1PR)に割り当てられます。

    主要なレビューアがそのタスクを開くと、その主要なレビューアは、証明オブジェクト内の明細項目をすべて見ることができます。主要なレビューアが任意の特定の明細項目を開いた場合は、その主要なレビューアは、その明細項目の明細項目詳細をすべて見ることができます。

    主要なレビューアは、そのタスク内で、いずれの明細項目でも操作できます。主要なレビューアは、任意の明細項目を別の人間に委任するか、または任意の明細項目を別の人間に再割当てすることができます。デフォルトでは、主要なレビューアは、あらゆる明細項目を所有しており、その明細項目詳細に対し、その証明や失効などの決定を下すことができます。

    各明細項目に対して決定が下された後、明細項目の各詳細にフェーズ1決定が下された後、あるいは各詳細が委任されるか、または再割当てされた後で、主要なレビューアは、タスクをサインオフするか、または完了することができます。

  3. P1PRによる項目の再割当て: フェーズ1で主要なレビューアが任意のセットの明細項目を別の人間に再割当てした場合は、Oracle Identity Managerによって、それらの再割当てされた明細項目(およびその詳細)が元の証明から削除され、新規の独立した証明に入れられます。明細項目が再割当てされた人間は、その新規の独立した証明に対するP1PRとなります。

    再割当てされた明細項目は元のP1PRのタスクに表示されなくなり、このレビュー・サイクル内にも再表示されなくなります。新しいP1PRが元のP1PRに明細項目を再割当てするか、または委任しても、元のP1PRにタスクが新規作成され、次のように、別のレビュー・プロセスの一環となります。

    • 新しいP1PRが元のP1PRに明細項目を再割当てした場合は、独自のP1PRタスクを備えた新規証明となります。

    • 新しいP1PRが元のP1PRに明細項目を委任した場合は、新規P1PRのレビュー・プロセス内で新規に委任されたレビュー(P1DR)・タスクとなります。

  4. P1PRによる項目の委任: 主要なレビューアが任意のセットの明細項目を別の人間に委任した場合は、その人間が、それらの明細項目のそれぞれに対するフェーズ1の委任されたレビューア(P1DR)となります。タスクが新規作成され、新しいP1DRに割り当てられます。


    注意:

    タスクの数を最小にするには、特定のレビューアに委任しようとする明細項目セットを選択することをお薦めします。そうしないと、委任されたレビューアは、タスクをいくつでも受け取ってしまう可能性があり、それらのタスクのそれぞれには、同じ証明オブジェクトの同じフェーズにある明細項目のいくつかのサブセットが含まれます。

    主要なレビューアが特定の明細項目セットを委任すると、それらの明細項目には、主要なレビューアが委任したタスク内で委任済とマークされます。主要なレビューアは、それらの明細項目に対しては、委任を解除しないかぎり、そのタスク内で操作できなくなります。主要なレビューアには、フェーズ1検証中に、委任された任意のレビューアが行った決定を見て無効にするチャンスがあります。

  5. P1PRによる項目の委任解除: 主要なレビューアは、委任されている明細があれば、その委任を解除するか、または委任されているレビューアから取り返すことができます。明細項目の委任を解除すると、主要なレビューアはその明細項目を操作でき、現在委任されているレビューアのタスクからその明細項目が削除されます。これによって、委任されていたレビューアはその明細項目をもう操作できなくなります。

  6. P1PRによるサインオフ: すべての明細項目が完了された後、あるいは委任されるか、または再割当てされた後で、主要なレビューアは、そのタスクに対してサインオフしてタスクを完了することができます。明細項目は、その詳細すべてに、現在のフェーズで決定が設定されると完了します。この時点では、Oracle Identity Managerによって、フェーズ1検証(P1V)が必須かどうかが判別されます。

  7. SOAによる割当て先に対するプロキシのアクティブ/非アクティブ化(P1PR): P1PRなど、割り当てられたレビューアにプロキシを割り当てることができます。たとえば、レビューアが休暇を取る予定になっている場合、そのレビューアはプロキシをアクティブ化できます。レビューアが休暇から戻ると、そのプロキシは非アクティブ化されます。新たに割り当てられた(プロキシ)レビューアがタスクを開くと、プロキシ・レビューアは、各明細項目および明細項目詳細を表示して操作できます。プロキシの追加、変更または削除については、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のプロキシの管理に関する項を参照してください。

  8. SOAによるタスクのエスカレート(P1PR): 証明タスクは、Oracle Identity Managerが証明レビュー・タスクに使用するSOAコンポジットの構成に応じてエスカレートされる場合があります。たとえば、レビューアが、構成された時間制限内にタスクをサインオフしていないか、または完了していない場合は、SOAによってタスクがエスカレートされ、現在割り当てられているレビューアのマネージャに再割当てされる可能性があります。タスクが最大回数までエスカレートされるか、またはエスカレーションを終了する他の状況に到達した後で、タスクの有効期限が切れます。

  9. SOAによるタスクの有効期限切れ(P1PR): 証明レビュー・タスクは、ある状況で期限切れとなる場合があります。たとえば、レビューアが、構成された時間制限内にタスクをサインオフしていない場合は、タスクが有効期限切れとなる可能性があります。タスクが、有効期限が到来するまでエスカレートするように構成されている場合は、SOAによってタスクが有効期限切れとなるのは、最大回数までエスカレートされるか、またはエスカレーションを終了する他の状況に到達した後に限られます。有効期限の切れたタスクは操作できなくなります。

  10. タスク: P1DR: 委任されたレビュー・タスクそれぞれには、委任されたレビューアに主要なレビューアが委任した明細項目セットが含まれています。委任されたレビューアがそのタスクを開くと、委任されたレビューアが見ることができるのは、そのタスクを生成した特定の委任イベントで委任された明細項目のみです。フェーズ1の委任されたレビューア(P1DR)が任意の特定の明細項目を開いた場合は、P1DRはその明細項目のすべての詳細を見ることができます。

    委任されたレビューアは、そのタスク内で、いずれの明細項目でも操作できます。委任されたレビューアは、任意の明細項目を別の人間に委任することも、任意の明細項目の委任を解除することも、任意の明細項目を別の人間に再割当てすることもできません。デフォルトでは、委任されたレビューアは、あらゆる明細項目を所有しており、その明細項目詳細に対し、証明や失効などの決定を下すことができます。すべての明細項目に対して決定が下された後、または明細項目のすべての詳細にフェーズ1決定が下された後で、委任されたレビューアは、タスクをサインオフするか、または完了することができます。

  11. P1DRによるサインオフ: 委任されたレビュー・タスク内のすべての明細項目に決定が下された後で、委任されたレビューアは、タスクをサインオフするか、または完了することができます。委任されたレビュー・タスクはいずれも、証明レビュー・プロセスがフェーズ1検証に進むことのできる前に完了するか、または有効期限切れとなる必要があります。

  12. いずれの明細項目にもP1DRがある: この分岐点では、フェーズ1検証ステージが必須かどうかが判別されます。これは、委任されている明細項目があるかどうかによります。

    • P1PRがサインオフしたときに、再割当てされていない明細項目が委任されたままの場合は、レビュー・プロセスがフェーズ1検証に移行します。

    • P1PRがサインオフしたときに、再割当てされていない明細項目が委任されたままになっていない場合は、レビュー・プロセスがフェーズ2に移行します。

  13. P1DRのタスクがすべてサインオフされたか、または有効期限切れとなった: フェーズ1で委任されたすべてのレビュー・タスクがサインオフ(完了)されるか、または有効期限切れとなるまで、この分岐はループします。

  14. タスク: P1V: 主要なレビューア(P1PR)がサインオフし、委任されたすべてのレビュー・タスク(P1DR)が完了するか、または有効期限切れとなったら、フェーズ1検証が開始します。同じ証明オブジェクトの別のタスクが作成され、主要なレビューアに割り当てられます。このタスク内では、主要なレビューアは、フェーズ1でなんらかの決定を行っていた場合に、その決定を確認したり無効にしたりすることができます。委任されたレビューアが完了していない明細項目があれば、主要なレビューアはそれも完了できます。主要なレビューアは、このタスク内で、明細項目の再割当ても委任もできないため、委任の解除もできません。

  15. P1PRによるサインオフ(P1V): 別の主要なレビューアに再割当てされていないすべての明細項目について、証明オブジェクト内のすべての明細項目詳細に決定が下された後で、フェーズ1の主要なレビューアがサインオフできます。レビューアがフェーズ1検証タスクでサインオフすると、証明レビュー・プロセスはフェーズ2に進みます。

  16. SOAにより、(P1PRタスクと同様に)割当て先に対してプロキシがアクティブ化され、P1Vタスクがエスカレートまたは有効期限切れになる可能性があります。詳細は、ステップ7から9を参照してください。

6.10.3.2 検証を使用したフェーズ2

フェーズ2は、フェーズ1の省略可能な複数の循環バージョンです。

省略可能: フェーズ2は省略可能です。というのは、フェーズ2が発生するのは、構成でフェーズ2が有効になっている場合、フェーズ2の主要なレビューアを選択するように管理者が戦略を指定した場合、および、指定された戦略がフェーズ2の主要なレビューアを、証明内の少なくとも1つの明細項目に割り当てた場合に限られるためです。

複数: フェーズ2の主要なレビューアは複数ある場合があります。というのは、それぞれのレビューアが管理または認可するのは、明細項目でなく明細項目詳細であるためです。たとえば、ユーザー証明では、ロール割当て、アカウント割当て、権限割当てのそれぞれに、別々の主要なレビューアを指定できます。

循環: フェーズ2の各レビューアは、循環ビューを見ることができます。たとえば、ユーザー証明のフェーズ1では、ビジネス・レビューアはユーザーを明細項目として、また各ユーザーのアクセス権限を明細項目詳細として見ることができます。ユーザー証明のフェーズ2では、テクニカル・レビューアは、ロール定義、アプリケーション・インスタンス定義、権限定義などの権限定義を明細項目として、また各権限メンバーを明細項目詳細として見ることができます。この権限中心のビューは、テクニカル・レビューアにとって、より有用です。テクニカル・ビューアは、個別の権限定義に対する責任を委任するか、または再割当てできます。

図6-4は、TPADを使用した証明レビューの第2フェーズを示しています。

図6-4 検証を使用したフェーズ2

図6-4の説明が続きます
「図6-4 検証を使用したフェーズ2」の説明

フェーズ2のステージはフェーズ1と似ていますが、次の点が異なります。

  • タスク: P2PR: フェーズ2の主要なレビューア(P2PR)それぞれが、その証明内の割当てをレビューする必要がある各タイプの権限に対して、レビュー・タスクが生成されます。フェーズ2の主要なレビューアがP2PRのタスクを開くと、その主要なレビューアは、証明オブジェクト内で自分が責任を負う明細項目のリストを見ることができます。たとえば、ユーザー証明のフェーズ2では、P2PRのタスクを開くテクニカル・レビューアは、ロール定義、アプリケーション・インスタンス定義、権限定義などの権限のリストを見ることができます。それらの権限は、その主要なレビューアが証明者であり、その証明オブジェクトに割当てが含まれています。このタイプの証明はユーザー中心であり、循環ビューは権限中心です。

    主要なレビューアが任意の特定の明細項目を開いた場合は、その主要なレビューアは、その明細項目の明細項目詳細をすべて見ることができます。主要なレビューアは、そのタスク内で、いずれの明細項目でも操作できます。主要なレビューアは、任意の明細項目を別の人間に委任するか、または任意の明細項目を別の人間に再割当てすることができます。デフォルトでは、主要なレビューアは、あらゆる明細項目を所有しており、その明細項目詳細に対し、その証明や失効などの決定を下すことができます。

  • P2PRによる項目の再割当て: フェーズ2で主要なレビューアが任意のセットの明細項目を別の人間に再割当てした場合は、その人間が、それらの明細項目に対する新規の主要なレビューア(P2PR)となります。Oracle Identity Managerによって主要なレビュー・タスクが新規作成され、新しいP2PRに割り当てられます。


    注意:

    フェーズ2での再割当て操作では、証明は新規生成されません。たとえば、主要なテクニカル・レビューアが(循環される)明細項目を再割当てした場合は、証明は分割されません。

    再割当てされた明細項目は、元のP2PRのタスクに表示されなくなります。明細項目は、新しいP2PRに割り当てられている別個のタスク内に表示されます。

6.10.3.3 最終レビュー

最終レビューは省略可能であり、最後に決着をつけるものです。これは、TPADにおいて最も単純なフェーズです。

省略可能: 最終レビューが発生するのは、構成で最終レビューが有効になっている場合、証明の定義において最終レビューが実行されるように管理者が指定した場合、および、少なくとも1つの明細項目にフェーズ2の主要なレビューアが割り当てられているためにフェーズ2が実行された場合に限られます。

最後に決着をつけるもの: フェーズ2のレビューアは、フェーズ1のレビューアと異なる決定を下した可能性があるため、フェーズ1の主要なレビューアは、それまでの2つのフェーズで下された決定を表示して無効にすることができます。したがって、最終レビューは最後に決着をつけるものです。

最も単純なフェーズ: 最終レビューアは1人のみであり、それがフェーズ1の主要なレビューアです。最終レビューアは、委任も再割当てもできません。最終レビューアは、フェーズ1で下された決定、およびフェーズ2で下された決定を確認し、それらの決定を無効にすることができます。

図6-5は、TPADを使用した証明レビューの省略可能な最終フェーズを示しています。

図6-5 最終レビュー・フェーズ

図6-5の説明が続きます
「図6-5 最終レビュー・フェーズ」の説明

最終レビューでは、他のレビュー・フェーズと次のステージが異なります。

  • システムによるFRDの計算: Oracle Identity Managerでは、次のようにして最終レビュー決定(FRD)が計算されます。

    • フェーズ2の決定が棄権以外のものである明細項目詳細では、フェーズ2の決定が最終レビュー決定になります。

    • 特定の明細項目詳細にフェーズ2の決定がない場合、またはフェーズ2の決定が棄権することである場合は、フェーズ1の決定が最終レビュー決定になります。

  • 最終レビューが有効: この分岐では、最終レビュー用にタスクを生成するかどうか、またそのタスクをフェーズ1の主要なレビューアに割り当てるかどうかが判別されます。構成でフェーズ2が無効になっている場合、この証明レビューでフェーズ2が使用されていない場合、または構成で最終レビューが無効になっている場合は、最終レビュー用のタスクは生成されません。フェーズ2の決定が下されていて、構成で最終レビューが有効になっている場合は、最終レビュー用のタスクは生成されます。

  • タスク: FR: 最終レビューアは、最終レビュー・タスクを開き、次のものを参照できます。

    • 各明細項目詳細に関してフェーズ1で下された決定。

    • 各明細項目詳細に関してフェーズ2で下された決定。

    • 最終レビュー決定。

    最終レビューアは、フェーズ1とフェーズ2の決定との関連で、FRDを無効にできます。最終レビューアは、このタスク内で、明細項目の再割当ても委任もできないため、委任の解除もできません。最終レビューアは、各FRDを検証した後でサインオフできます。その時点では、最終レビュー・タスクが完了し、全体的な証明プロセスが完了しますが、クローズド・ループ是正は例外で、この是正はサインオフ後にOracle Identity Managerにより自動的に実行されます。最終レビューアがサインオフしないで、最終レビュー・タスクの有効期限が切れることを許容した場合は、証明プロセスは停止します。

最終レビューを使用し、フェーズ1の決定とフェーズ2の決定を比較して、最終的な決定を下すことができます。フェーズ2の決定を優先する場合は、構成で最終レビューを有効にしないでください。

6.11 証明の監視の理解

証明の監視とは、特定の主要なレビュー・タスクの範囲内で、プライマリ・レビューアの決定をレビューする(場合によっては取り消す)アクティビティのことです。

特定の主要なレビュー・タスクの範囲内でプライマリ・レビューアの証明の決定を取り消すことができる人物を監督者と呼びます。監督者には次の特徴があります。

  • 監督者は、OIMユーザーである必要があります。

  • 主要なレビュー・タスクを同時に監視できる監督者は1人のみです。

  • 監督者には、プライマリ・レビューアまたは前任の監督者による決定を表示および取消しする権限があります。

証明構成の一部として、証明の監視ワークフローを定義する証明コンポジットを選択できます。証明コンポジットとは、証明のフェーズ中に、プライマリ・レビューアまたは委任されたレビューアごとに証明サーバーを起動するSOAワークフローのことです。

CertificationOverseerProcessコンポジットで定義されているデフォルトの動作は、次のとおりです。

  • 主要なレビュー・タスクは、プライマリ・レビューアとシーケンス内のすべての監督者がサインオフするまで完了しません。

  • 監督者のシーケンスで最後の監督者がサインオフした決定は、その主要なレビュー・タスクの最終決定になります。

  • クローズド・ループ型の是正は、全体的な証明が完了した後で開始されます。すべての主要なレビュー・タスクが完了するまでは、証明のどのフェーズも完了しません。

  • 証明のフェーズ2と最終レビュー・フェーズの場合:

    • フェーズ2には複数のプライマリ・レビューアが存在することがあるため、主要なレビュー・タスクごとに個別の監督者のシーケンス(プライマリ・レビューアごとに1つの主要なレビュー・タスク)が存在することがあります。複数フェーズ・レビューの詳細は、「ユーザー証明における複数フェーズ・レビューの理解」を参照してください。

  • 委任の場合、プライマリ・レビューアの検証タスクに対してのみ監視が実施されます。主要なレビュー・タスク中にプライマリ・レビューアが委任すると、その主要なレビュー・タスクは監視されません。そのかわりに、そのフェーズの決定をすべて含む、後続の検証タスク中に監視が実施されます。

  • 証明のフェーズ1の間に明細項目の再割当てがあると、新しい証明が作成され、再割当て先に割り当てられる新しい主要なレビュー・タスクが作成されます。ここで、新しい主要なレビュー・タスクに対する監視者の新しいシーケンスが計算されます。

デフォルトの監視機能を拡張すると、様々なレベルの監視を指定したり、特定のステージに達したときに監視プロセスを停止したりできます。これを行うには、カスタムの証明コンポジットを作成して、デプロイする必要があります。カスタムの証明コンポジットの作成とデプロイの詳細は、「証明の監視のカスタマイズ」を参照してください。

6.11.1 証明の監視のカスタマイズ

証明の監視は、監視のレベルを拡張するため、または特定のタイトルに達したときに監視プロセスを停止するためにカスタマイズできます。証明コンポジットには、カスタマイズ可能な監視ロジックが含まれています。このロジックにより、次のいずれかまたはすべてに基づいて監督者のシーケンスを選択するためのOracle Identity Managerへの問合せをサポートします。

  • プライマリ・レビューア

  • 証明の現在のフェーズ

  • OIMで定義されている管理階層

デフォルトでは、証明タスクが1人のレビューアに割り当てられるという、単一レベルの監視のみがサポートされます。

証明の監視用コンポジットで事前定義されているように、プライマリ・レビューアまたは監督者がサインオフすると、主要なレビュー・タスクはシーケンス内の次の監督者に自動的にルーティングされます。プライマリ・レビューアまたは監視者(最終監視者を除く)が主要なレビュー・タスクでサインオフすると、そのユーザーは、完了したタスクを問い合せて、そのタスクを受信箱で表示することはできなくなります。

証明の監視のカスタマイズに必要な手順は、次のとおりです。

  1. コンポジットを作成します。これを行うには、次のようにします。

    1. OIM_HOME/server/workflows/new-workflow/ディレクトリに移動します。process-templateサブディレクトリには、コンポジット・ファイルが含まれたZIPファイルのアーカイブが格納されています。このコンポジット・ファイルは、新しいコンポジットを作成するためにベース・ファイルとして使用します。

    2. 次のコマンドを実行します。

      ant -f new_project.xml certification
      
    3. プロンプトが表示されたら、新しいコンポジットの名前を入力して、[Enter]を押します。コンポジットが作成され、コンポジットに指定した名前のパッケージ・ディレクトリがprocess-templateサブディレクトリに作成されます。

  2. JDeveloperでコンポジットを開きます。これを行うには、次のようにします。

    1. process-templateディレクトリに移動します。

    2. 手順1cで指定したコンポジット名のディレクトリに移動します。

    3. JDeveloperを使用して、COMPOSITE_NAME.jprを開きます。

  3. 「アプリケーション・ナビゲータ」ビューの「プロジェクト」ペインでプロジェクトを開いて、「CertificationTask.task」をダブルクリックして編集します。「割当て」タブをクリックします。「Stage1.Participant」オブジェクトをクリックして、「編集」を選択します。「参加者タイプの編集」ダイアログ・ボックスが表示されます。デフォルトでは、このコンポジットで単一の証明のレベルが定義され、証明は1人のレビューアに割り当てられます。たとえば、証明のレベルを変更するには、現在のタスクの割当て先のマネージャに移動して、次の値を設定します。


    注意:

    この手順で説明するカスタマイズはサンプルです。詳細なカスタマイズは、CertificationOverseerProcessデフォルト・テンプレートや、SOAのドキュメントを参照してください。

    • タイプ: 「シリアル」シリアル証明ロジックのみがサポートされます。

    • 参加者のリストの作成で使用: 「管理チェーン」

    • 属性の指定で使用: 「値ベース」

    • 開始参加者: 証明を開始するユーザーを選択します。

    • 最上位の参加者: 「役職別」。証明レビューの最上位の参加者になるレビューアの役職を指定します。最上位の参加者としてVPを指定し、レベル数として5を指定すると、証明はレベル3であっても、VPレベルにまで引き上げられます。その他のレベルは、スキップされます。

    • レベル数: 「番号別」。1を指定すると、証明はマネージャのレベルまでになります。2を指定すると、証明はマネージャのマネージャまでになります。

    • タスクの単一への自動割当て: 「ユーザー」

    • 割当てパターン: 「最もビジーでない箇所」

  4. 「OK」をクリックします。

  5. コンポジットをコンパイルして、コンポジットJARファイルをSOAにデプロイします。詳細は、SOAのドキュメントを参照してください。

  6. Oracle Identity System Administrationにログインし、新しくデプロイしたコンポジットを「構成」ページで選択して、証明の定義を作成します。

6.12 アイデンティティの証明のトラブルシューティング

表6-4には、アイデンティティの証明の使用中に遭遇する可能性のある問題と、その問題を解決するための手順がリストされています。

表6-4 アイデンティティの証明の問題のトラブルシューティング

問題 解決策

証明の定義を作成し、証明作成タスクというスケジュール済ジョブを実行しますが、証明タスクが生成されません。

「証明の構成」で説明しているように、すべての構成手順が実行されていることを確認してください。



注意:

必要なSOAパッチがすべて適用されていることを確認してください。SOAのパッチのリストは、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。