13 アイデンティティの証明の管理
この章では、アイデンティティの証明に関連する概念と、アイデンティティの証明に必要な構成タスクについて説明します。次の項目が含まれます。
13.1 証明の概念
アイデンティティの証明に関連する主要概念は、ライン・オブ・ビジネスと明細項目、証明タスク、オブジェクト、定義およびジョブ、クローズド・ループ是正、是正のトラッキング、イベント・リスナー、証明の認可およびユーザー認証のカスタム・レビューアです。
アイデンティティの証明に関連する概念について、次の各項で説明します。
13.1.1 ライン・オブ・ビジネスと明細項目
ライン・オブ・ビジネス(LOB)は、業種またはビジネス機能のカテゴリです。明細項目とは、証明の1ページ目に表示されるデータの行です。
LOBとは、業界またはビジネスの機能のカテゴリです。たとえば、LOBマネージャは、販売など、企業内のビジネス機能に向けられています。
明細項目とは、証明の1ページ目に表示されるデータの行です。各明細項目には、証明のタイプに従って、特定のアイデンティティまたは権限に関連する一連の権限割当てが収集されるか、またはまとめられます。レビューアは、任意の明細項目を開いて、その明細項目の詳細を表示できます。たとえば、ユーザー証明のフェーズ1の中では、各明細項目はユーザーを表しています。ユーザーの詳細を開くと、そのユーザーのアクセス権限が表示されます。
13.1.2 証明タスク
証明タスクは、証明プロセスの中で行う一連の作業で構成されています。
あるレビューアに割り当てられている明細項目の各セットによって、サービス指向アーキテクチャ(SOA)のタスクが開始されます。このタスクは、特定の明細項目セットを含み、そのレビューアのSOA受信箱にルーティングされます。SOAコンポーネントはまた、レビューアに対し、そのレビューアに証明タスクが割り当てられたことを通知します。
13.1.3 証明オブジェクト
証明オブジェクトは、証明IDと一組の明細項目で構成されています。
証明オブジェクトとは、生成され、特定の証明者または主要なレビューアに割り当てられる証明です。各証明オブジェクトの構成は次のとおりです。
-
一意の証明ID
-
一連の明細項目で、それぞれの明細項目には一連の詳細が含まれている
13.1.4 証明の定義
証明の定義とは、名前を付けられたパラメータ・セットで、このセットは、証明オブジェクトを生成するための証明ジョブへの入力として使用されます。
証明の定義で指定されるものは次のとおりです。
-
生成する証明のタイプ(ユーザー証明、ロール証明、アプリケーション・インスタンス証明、権限証明など)
-
どの明細項目(たとえばユーザー)を選択するかを記述した選択基準
-
各明細項目でどの詳細を選択するかを記述したコンテンツ制限基準
-
証明オブジェクトの生成またはレビュー・タスクの動作を制御する、その他のパラメータ
13.1.5 証明ジョブ
証明ジョブは、リクエストに応じて、またはスケジュール設定されたものとして、証明を作成するために使用されます。
証明ジョブとは、バックグラウンドで実行されるタスクで、このタスクでは、指定された証明の定義に基づいて証明オブジェクトを生成します。証明ジョブに対してできる操作は次のとおりです。
-
必要に応じて、毎週、毎月、毎四半期など、一定の間隔で実行するようにスケジュール設定する
-
Oracle Identity System Administrationの「スケジューラ」セクションからただちに実行する
-
イベント・リスナーのアクションからトリガーする
証明生成ジョブを作成および実行し、リクエストに応じて、またはスケジュール設定されたものとして、証明を作成できます。リスク集計ジョブを有効にして実行し、ユーザー、アカウント、ロール割当て、権限割当てなどのエンティティのリスク値を計算できます。
13.1.6 クローズド・ループ是正
クローズド・ループ是正は、証明プロセスの結果としてアクセス権限を取り消すために使用します。
クローズド・ループ是正とは、Oracle Identity Managerのプロビジョニング・システムを利用し、Oracle Identity Managerの証明プロセスの結果に基づいて、アカウント、ロールおよび権限を自動的に失効させる機能です。
13.1.7 是正のトラッキング
アクセス・リクエスト・カタログは、是正のトラッキングに使用されます。
リクエスト・カタログを使用して、失効されたアカウント、アカウント内のアクセスまたはロールの是正ステータスを追跡します。これは、それぞれの失効リクエストが満たされているかどうか、またいつ満たされたかを記録します。
13.1.8 イベント・リスナー
イベント・リスナーとは、ユーザーの変更に対応するサービスです。イベント・リスナーは、すべての証明タイプでサポートされています。
証明に対する各イベント・リスナーの構成は次のとおりです。
-
管理者によって指定される選択基準
-
対応して使用する証明の定義
13.1.9 証明の認可
証明の認可は、証明管理者および証明ビューア管理者ロールの割当てまたは取消しによって制御します。
次に示すOracle Identity Managerの管理ロールにより、証明機能の管理および証明インスタンスの進捗のモニターに必要な権限が、割当て先に付与されます。
-
証明管理者: 証明管理者の管理ロールにより、証明機能に対するスーパーユーザー権限が、割当て先に付与されます。特に、この管理ロールでは、Oracle Identity Manager System Administrationにおける証明構成およびスケジューラに対するアクセス権限が付与されます。このロールでは、証明に対する完全なアクセス権も付与され、いずれの証明に対しても、表示やアクションの実行が可能となります。
-
証明ビューア: 証明ビューアは読取り専用のロールで、このロールが付与されたコンプライアンス管理者は、新規、進行中および完成した証明を表示できます。
13.1.10 ユーザー証明のカスタム・レビューア
ユーザー証明のカスタム・レビューアは、CERT_CUSTOM_ACCESS_REVIEWERS表に証明ルールを定義することで指定できます。
13.1.10.1 カスタム・アクセス・レビューアについて
ユーザー証明のための独自のカスタム・アクセス・レビューアを定義するには、特定のレビューアとともに、特定のユーザー・アカウント、ロール、権限またはアプリケーション・インスタンスに対する証明ルールを指定するか、これらのエンティティの組合せに対する証明ルールを指定します。さらに、証明ルールをグループ化して、証明ルールにマップ名を割り当てることで、そのマップ名に対するレビューアを指定することもできます。
ノート:
CERT_CUSTOM_ACCESS_REVIEWERS表は、目的とする証明ジョブの実行前にデータが移入されている必要があります。この表のデータは、Oracle Identity Managerの管理者が維持管理します。表13-1 CERT_CUSTOM_ACCESS_REVIEWERS表の定義
| 列 | データ型 | 説明 |
|---|---|---|
| reviewer_login | varchar2(256) | レビューア・ユーザーのOIMログインID。
このフィールドには、次の特別な値を設定できます。
|
| user_login | varchar2(256) | アクセスにフィルタの適用が必要になるユーザーのOIMユーザー・ログイン。このフィールドには、次の特別な値を設定できます。
<ANY>: 任意のユーザーに適用される特別なレビューア・マッピングを指定します。 |
| access_type | number(2) | アクセス・タイプには数値が割り当てられています。有効な値は、次のいずれかになります。
|
| app_instance_name | varchar2(4000) | アプリケーション・インスタンスの名前。 |
| account_name | varchar2(300) | アプリケーション・インスタンスの特定のアカウントの名前。 |
| entitlement_name | varchar2(4000) | 権限の名前 |
| role_name | varchar2(4000) | ロールの名前。 |
| map_name | varchar2(4000) | マッピングへのタグ付けと、証明の定義で使用できるマップ名。 |
13.1.10.2 カスタム・アクセス・レビューアを使用するための条件
ユーザー証明のカスタム・アクセス・レビューアを使用するには、特定の条件が満たされている必要があります。
-
レビューア表は、フィールド/列のいずれについてもワイルドカードをサポートしていません。
-
レビューア表には、証明に含めるすべてのユーザーごとに定義したマッピングを保持します。
-
アプリケーション・インスタンス情報は、すべてのアカウントと権限のマッピングで必要になります。
-
マップ名ごとに許容されるデフォルト・レビューアと代替レビューアのマッピングのインスタンスは1つのみです。
13.1.10.3 サンプルのCERT_CUSTOM_ACCESS_REVIEWERS表
表13-2 サンプルのCERT_CUSTOM_ACCESS_REVIEWERS表
| 行番号 | REVIEWER_LOGIN | USER_LOGIN | ACCESS_TYPE | アプリケーション・インスタンス名 | アカウント名 | 権限名 | マップ名 |
|---|---|---|---|---|---|---|---|
| 1 | ACERTUSER2 | VCERTUSER2 | 3 | VISDU1 | VCERTUSER2SERVICE | 2015 Review | |
| 2 | ACERTUSER1 | VCERTUSER3 | 4 | VISDU1 | VCERTUSER3 | EntTestDB~CN=VISDU11,DC=abc,DC=com | 2015 Review |
| 3 | ACERTUSER3 | VCERTUSER2 | 4 | VISDU1 | VCERTUSER2 | EntTestDB~CN=VISDU11,DC=abc,DC=com | 2015 Review |
| 4 | VCERTUSER10 | VCERTUSER2 | 1 | 該当なし | 該当なし | 該当なし | <GLOBAL> |
-
行番号1は、特定のレビューアACERTUSER2を持つユーザーVCERTUSER2のユーザー・アカウントVCERTUSER2SERVICEが所有する特定のアプリケーション・インスタンスVISDU1に対して定義されたマッピングを保持しています。
-
行番号2は、特定のレビューアACERTUSER1を持つユーザーVCERTUSER3のユーザー・アカウントが所有するアプリケーション・インスタンスVISDU1の特定の権限EntTestDB~CN=VISDU11,DC=abc,DC=comに対して定義されたマッピングを保持します。
-
行番号3は、特定のレビューアACERTUSER3を持つユーザーVCERTUSER2のユーザー・アカウントVCERTUSER2が所有するアプリケーション・インスタンスVISDU1の特定の権限EntTestDB~CN=VISDU11,DC=abc,DC=comに対して定義されたマッピングを保持します。
13.1.10.4 カスタム・アクセス・レビューアのシナリオ
次に、サポートされるカスタム・アクセス・レビューア構成シナリオの一覧を示します。
特定のユーザーのカスタム・レビューア
レビューア表に、特定のレビューアR1を持つ特定のユーザーU1に対して定義されたマッピングを保持します。
このマッピングは、アクセス職責マッピング全体として処理されます。レビューアR1はユーザーU1のアクセス全体をレビューすることになり、ユーザーU1はレビューアR1の証明に含まれるようになります。ユーザーU1のアクセスは、レビューア表のレビューアがR1ではない場合に除外されます。
特定のユーザーが所有するアカウントに対するカスタム・レビューア
レビューア表に、特定のレビューアR2を持つユーザーU1の特定のユーザー・アカウントU1A1に対して定義されたマッピングを保持します。
このマッピングは、制限されたアクセス職責マッピングとして処理されます。レビューアR2はユーザーU1のアカウントU1A1のみをレビューすることになり、ユーザーU1はレビューアR2の証明に含まれるようになります。Oracle Identity Managerは、レビューアR2に対してU1A1アカウントとともにU1A1に含まれる権限のすべてを含めます。
特定のユーザー・アカウントが所有する権限のカスタム・レビューア
レビューア表に、特定のレビューアR3を持つ特定のアカウントU1A1が所有する特定の権限U1A1E1に対して定義されたマッピングを保持しまします。
このマッピングは、制限されたアクセス職責マッピングとして処理されます。レビューアR3はユーザーU1の権限U1A1E1のみをレビューすることになり、ユーザーU1はレビューアR3の証明に含まれるようになります。Oracle Identity Managerは、レビューアR3に対してアカウントU1A1と権限U1A1E1のみを含めます。
アプリケーション・インスタンス(アカウント名なし)の範囲内の権限に対するカスタム・レビューア
レビューア表に、特定のレビューアR5を持つアプリケーション・インスタンス名APP2の特定の権限E3に対して定義されたマッピングを保持します。このマッピングには、アカウント名は定義されていません。
このマッピングは、制限された職責マッピングとして処理されます。レビューアR5は、アプリケーション・インスタンスAPP2で使用可能なすべてのユーザー・アカウントからE3という名前が付いたすべての権限をレビューすることになります。証明は、アプリケーション・インスタンスAPP2で権限E3を持つすべてのユーザーに対して生成されてレビューアR5に割り当てられます。Oracle Identity Managerは、権限E3のみを持つアカウントをレビューアR5の証明に含めます。
特定のユーザーが所有するロールに対するカスタム・レビューア
レビューア表に、特定のレビューアR4を持つユーザーU1の特定のユーザー・ロールU1R1に対して定義されたマッピングを保持します。
このマッピングは、制限されたアクセス職責マッピングとして処理されます。レビューアR4はユーザーU1のロールU1R1のみをレビューすることになり、ユーザーU1はレビューアR4の証明に含まれるようになります。Oracle Identity Managerは、レビューアR4に対してロールU1R1のみを含めます。
レビューア表で指定された各種アクセス・タイプに対するカスタム・レビューア
証明は、表内で定義されたレビューアごとに作成されます。それぞれのレビューアには、マッピングが定義されているアクセス要素のみが表示されます。それぞれのレビューアは、1回の証明ジョブの実行で作成される1つの証明のみを所有します。
レビューア表でタグ/マップ名が定義されているカスタム・レビューア表
レビューア表では、証明の定義で定義されたタグ/マップ名ごとにスコープが設定されます。証明の定義でタグ/マップ名が指定されていない場合、レビュー表のスコープは<GLOBAL>タグ/マップ名に対して設定されます。
特定のマップ名に対するデフォルト・レビューア・マッピング
レビューア表に、デフォルト・ビューア行でマップ名MAP1に対して<Default Reviewer> - <USER_MANAGER> - <ANY>として定義されたマッピングを保持します。
このマッピングは、デフォルトのユーザー・レビューア・マッピングとして処理され、任意のユーザーのレビューアがユーザーのマネージャになるようにデフォルト設定されます。すべてのユーザーのマネージャは、レビューアとして含まれます。Oracle Identity Managerは、レビューア表に別のユーザー・アクセス・タイプ・マッピングが存在している場合、ユーザーのマネージャの証明にユーザーを含めません。このマッピングは、別のマッピングにどのような影響も与えません。
証明の定義に基本選択のサブセットとしてユーザーレベルのマッピングがあるレビューア表
基本選択は、ユーザーU1、U2、U3およびU1::U1A1-> R1 (アカウント・タイプ)、U2::U2A1E1-> R2 (権限タイプ)のマッピングを含むレビューア表で構成されます。デフォルト・レビューア・マッピングは、<USER_MANAGER>-<ANY>です。マネージャは、U1->M1、U2->M2およびU3->M3として使用できます。
証明は、すべてのユーザーU1、U2およびU3に対して生成されます。各ユーザーのマネージャが各ユーザーのアクセスをレビューします。レビューアM3は、U3のすべてのアクセスをレビューします。レビューアM2は、権限U2A1E1以外のU2のすべてのアクセスをレビューします。レビューアR2は、ユーザーU2のU2A1E1のみをレビューします。レビューアM1は、アカウントU1A1以外のすべてのU1のアクセスをレビューします。レビューアR1は、ユーザーU1のU1A1のみをレビューします。
デフォルト・レビューア・マッピングとユーザーレベル・マッピングのオーバーライドを含むレビューア表
レビューア表に、<GLOBAL>マップ名に対する<Default Reviewer> - <USER_MANAGER> - <ANY>としてデフォルト・レビューア・マッピングを保持します。また、レビューア表に、U1 -> R1のユーザー・タイプ・マッピングも保持します。ユーザーU1には、システムでマネージャM1が定義されています。レビューアR1に対して1つの証明が生成されますが、マネージャM1に対して証明は生成されません。
デフォルト・レビューア・マッピングと代替レビューア・マッピングを含むレビューア表
レビューア表に、<GLOBAL>マップ名に対する<Default Reviewer> -< USER_MANAGER> - <ANY>としてデフォルト・レビューア・マッピングを保持します。レビューア表に、<GLOBAL>マップ名に対する<Alternate Reviewer> - <AR1> - <ANY>として代替レビューア・マッピングを保持します。ユーザーU1には、システムでマネージャM1が定義されています。レビューアM1は、システムで無効なユーザーです。
ユーザーは非アクティブなため、マネージャM1に対して証明は生成されません。ユーザーU1を持つレビューアAR1に対して1つの証明が生成されます。
13.2 証明の構成
証明構成の特定の前提条件が満たされていると、Identity Self Serviceの「証明構成」ページで証明構成のプロパティを設定できます。
この項では、次の各トピックで証明の構成方法について説明します。
13.2.1 証明を構成するための前提条件
証明の構成のための前提条件には、カタログ項目への証明可能としてのマーキング、証明、ユーザー・マネージャ、組織証明者、証明スナップショットのユーザー属性および個別のエンティティに対するリスク・レベルの設定、属性へのタグ付け、およびアイデンティティ証明の可用性、リマインダ、通知、エスカレーションおよび証明の期限の構成が含まれます。
証明を構成する際に前提条件となるステップは次のとおりです。
ノート:
構成前のステップの一部では、リクエスト・カタログを使用することが必要になります。リクエスト・カタログの詳細は、次の各項を参照してください。
-
『Oracle Identity Governanceの管理』のアクセス・リクエスト・カタログの管理に関する項
13.2.1.1 カタログ項目を証明可能とマーク
ロール割当て、ロール・メンバーシップ、アプリケーション・インスタンス、権限などのリクエスト可能エンティティは、リクエスト・カタログで証明可能とマークされた後でのみ証明に使用できます。証明可能とマークされていないエンティティは、証明には表示されません。
デフォルトでは、カタログ内の項目はすべて、証明可能とマークされています。そのエンティティに対して証明タスクを生成しない場合は、「証明可能」オプションの選択を解除できます。
エンティティを証明可能とマークするには:
13.2.1.2 リクエスト・カタログでの証明者の設定
あるユーザーをエンティティの証明者に設定し、「ロール証明者」や「アプリケーション・インスタンス証明者」など、レビューアを選択するためのオプションのいくつかを選択すると、そのユーザーは自動的に、そのエンティティを証明するための証明者または主要なレビューアに設定されます。たとえば、ユーザーJohn Doeが、ビジョン開発者ロールの証明者として選択されている場合、証明作成の「レビューア」画面での選択に応じて、John Doeは、ビジョン開発者ロールを証明する際の主要なレビューアに自動的に設定されます。この例では、そのユーザーがビジョン開発者ロールの証明者に設定された後、ロール証明の作成時に、「ロール証明者」オプションを選択すると、このフィールドが取得されます。
ノート:
「ロール証明者」や「アプリケーション・インスタンス証明者」など、証明作成画面でレビューアを選択するためのオプションのいくつかを使用する場合には、リクエスト・カタログで証明者を設定することが必要になります。
カタログでの証明者を設定するには:
13.2.1.3 ユーザー・マネージャおよび組織証明者の設定
ユーザー・マネージャおよび組織証明者は、証明作成プロセスにおいて、主要なレビューアとして選択できます。
ユーザー・マネージャとは、Oracle Identity Self Serviceで、「ユーザーの詳細」ページの「属性」タブの「マネージャ」フィールドで選択されたユーザーです。Terence HillのマネージャとしてJane Doeが指定されている場合、「証明の定義の作成」で説明しているように、ユーザー証明の定義を作成するときにこのユーザー・マネージャをプライマリ・レビューアに選択すると、Jane Doeは、Terence Hillに対して生成される証明タスクのプライマリ・レビューアに自動的に設定されます。
組織証明者とは、Oracle Identity Self Serviceで、「組織の詳細」ページの「属性」タブの「証明者ユーザー・ログイン」フィールドで選択されたユーザーです。Robert KleinがVision North組織の組織証明者に指定されている場合、証明の定義を作成するときに組織証明者を主要なレビューアに選択すると、Robert Kleinは、Vision Northに対して生成される証明タスクの主要なレビューアに自動的に設定されます。
ノート:
-
「レビューア」オプションとして「ユーザー・マネージャ」または「組織証明者」を使用する場合には、ユーザー・マネージャまたは組織証明者を設定することが必要になります。それ以外の場合は不要です。
-
ロールの組織証明者は、「階層対応」オプションをサポートしせん。組織証明者の場合、そのロールは組織内に用意されている必要があります。言い換えれば、ロールには具体的な組織が指定されている必要があります。それ以外の場合は、証明は生成されません。ロールと組織がリンクされていて、組織には証明者ユーザーが割り当てられているようにしてください。
13.2.1.4 証明スナップショットのユーザー属性の設定
証明スナップショットには、Oracle Identity Managerの次のユーザー属性が含まれます。
UserManagerConstants.AttributeName.USER_KEY.getId()); UserManagerConstants.AttributeName.USER_ORGANIZATION.getId()); UserManagerConstants.AttributeName.USER_LOGIN.getId()); UserManagerConstants.AttributeName.MANAGER_KEY.getId()); UserManagerConstants.AttributeName.STATUS.getId()); UserManagerConstants.AttributeName.EMAIL.getId()); UserManagerConstants.AttributeName.FIRSTNAME.getId()); UserManagerConstants.AttributeName.LASTNAME.getId()); UserManagerConstants.AttributeName.DISPLAYNAME.getId()); UserManagerConstants.AttributeName.EMPTYPE.getId()); UserManagerConstants.AttributeName.PHONE_NUMBER.getId()); UserManagerConstants.AttributeName.EMPLOYEE_NUMBER.getId()); UserManagerConstants.AttributeName.USER_UPDATE.getId()); UserManagerConstants.AttributeName.USER_CREATEBY.getId()); UserManagerConstants.AttributeName.USER_UPDATEBY.getId()); UserManagerConstants.AttributeName.USER_CREATED.getId()); UserManagerConstants.AttributeName.DEPARTMENT_NUMBER.getId()); UserManagerConstants.AttributeName.LOCALITY_NAME.getId()); UserManagerConstants.AttributeName.POSTAL_CODE.getId()); UserManagerConstants.AttributeName.STATE.getId()); UserManagerConstants.AttributeName.STREET.getId()); UserManagerConstants.AttributeName.USER_COUNTRY.getId()); UserManagerConstants.AttributeName.LOCALE.getId()); UserManagerConstants.AttributeName.TITLE.getId()); UserManagerConstants.AttributeName.GENERATION_QUALIFIER.getId()) UserManagerConstants.AttributeName.COMMONNAME.getId()); UserManagerConstants.AttributeName.HIRE_DATE.getId()); UserManagerConstants.AttributeName.ACCOUNT_STATUS.getId()); UserManagerConstants.AttributeName.MIDDLENAME.getId());
その他すべてのユーザー属性は、証明可能とマークされている場合、証明スナップショットに追加できます。このような属性は、他のユーザー定義属性とともに格納されます。属性に証明可能とマークするとパフォーマンスに影響を及ぼす可能性があるため、必要がある場合のみ属性に証明可能とマークすることをお薦めします。
13.2.1.5 個々のエンティティのリスク・レベルの設定
個々のエンティティのリスク・レベルを設定するには:
ノート:
リスク・レベルの設定の影響と、リスク・サマリーに達するようにOracle Identity Managerでリスク・レベルを処理する方法の詳細は、「リスク・サマリーの計算方法について」を参照してください。
- Oracle Identity Self Serviceで「カタログ」ページに移動します。
- リスク・レベルを設定するロール、アプリケーション・インスタンスまたは権限を検索して選択します。
- 「詳細情報」の「リスク・レベル」リストから、「高リスク」、「中リスク」または「低リスク」を選択します。
- 「適用」をクリックします。
個々のエンティティのリスク・レベルを設定したら、「リスク集計」スケジュール済ジョブを実行して、新しい証明の作成時に新しいリスク・レベルが適切に選択されるようにする必要があります。既存の証明オブジェクトには、新しいリスク・レベルが反映されないことに注意してください。
13.2.1.6 属性のタグ付け
Design Consoleで、証明のためにアカウント、ITリソースおよび権限にタグを付ける必要があります。タグを付けなかったら、エンティティの証明は生成されません。
アカウント、ITリソースおよび権限にタグがすでに付けられているかどうかを確認するには、この項で説明されているDesign Consoleのナビゲーションに従います。エンティティにすでにタグが付いている場合は、この項をスキップできます。それ以外の場合は、この項のステップを実行してアカウントおよびITリソースのタグ付けを構成します。
ノート:
証明の作成を有効にするには、この項で説明する手順を実行して、次のプロパティの値をtrueに設定する必要があります。
-
Entitlement -
ITResource -
AccountName
アカウントおよびITリソースのタグ付けを構成するには:
13.2.1.7 アイデンティティ証明の可用性の構成
証明機能は、Oracle Identity Managerの「コンプライアンス」に属します。したがって、「アイデンティティ監査機能セットの使用可否」システム・プロパティの値がTRUEに設定されている場合、証明機能は使用可能です。このプロパティの値がTRUEである場合、ロールのライフサイクル管理、職務の分離(SoD)およびアイデンティティ証明が有効になります。
このプロパティの値を変更した場合は、Oracle Identity Managerサーバーを再起動する必要があります。
ノート:
システム・プロパティおよびシステム・プロパティの値の設定については、Oracle Identity Governanceの管理でシステム・プロパティの管理に関する項を参照してください。
13.2.1.8 証明のリマインダ、通知、エスカレーションおよび有効期限の構成(省略可能)
Oracle Identity Governanceの管理のSOA電子メール通知の構成に関する項の説明に従って、電子メール通知がSOAで構成されている場合は、電子メール通知はデフォルトで、次のシナリオで送信されます。
-
タスクがユーザーに割り当てられた場合
-
タスクが完了した場合
デフォルトでは、証明が作成されてから1日後と2日後に、リマインダが1件ずつ送信されます。デフォルトでは、証明に対してエスカレーションも有効期限も設定されていません。
証明に対するデフォルトの構成を変更するには:
-
weblogicなどの管理資格証明を使用してOracle SOA Composerにログインします。そのためには、次のURLに移動します。
http://HOST_NAME:PORT_NUMBER/soa/composer
-
「オープン」をクリックし、「タスクを開く」を選択します。「開くタスクの選択」ダイアログ・ボックスが表示されます。
-
「CertificationProcess_rev1.0」を選択し、「オープン」をクリックします。「CertificationTask : イベント駆動構成」ページが表示されます。
-
「通知設定」セクションで、次の操作を行います。
-
タスクの割当て先は、割当てタスクおよび完了タスクの通知の受信者として選択されています。デフォルト設定を変更するために、「タスク・ステータス」列でタスクのステータスを選択し、「受信者」列で通知の受信者を選択することができます。デフォルトの通知メッセージを編集するタスクごとに鉛筆アイコンをクリックし、「OK」をクリックできます。
-
次のドロップダウンで、リマインダのデフォルト設定を変更します。
-
-
「有効期限およびエスカレーション・ポリシー」セクションで、エスカレーションおよび有効期限のデフォルト値を変更できます。
-
「OK」をクリックします。
-
「保存」をクリックし、「コミット」をクリックします。
13.3 証明の定義の管理
証明の定義の管理には、ユーザー、ロール、アプリケーション・インスタンスおよび権限証明に対する定義の作成、変更および削除が含まれます。
この項では、次の各トピックで証明の定義について説明します。
13.3.1 証明の定義の作成
「証明の定義」ページから新規証明ウィザードを起動することで、ユーザー、ロール、アプリケーション・インスタンスおよび権限の証明定義を作成できます。
証明の定義の作成については、以降の項で説明します。
13.3.1.1 ユーザー証明の定義の作成
ユーザー証明の定義を作成するには:
-
Oracle Identity Self Serviceにログインします。
-
「コンプライアンス」タブをクリックします。
-
「アイデンティティの証明」ボックスをクリックして、「定義」を選択します。「証明の定義」ページが表示されます。
-
「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「新規証明」ウィザードの「一般の詳細」ページが表示されます。
-
次の値を入力します。
-
証明名: 証明の名前を入力します。
-
タイプ: ユーザー証明を作成する場合は「ユーザー」を選択します。
-
説明: 必要に応じて、新規のユーザー証明の説明を入力します。
-
-
「次」をクリックします。「新規証明」ウィザードの「基本選択」ページが表示されます。
-
「基本選択」セクションで、次のようにユーザー選択戦略を選択します。
-
すべての組織のユーザー: Oracle Identity Manager内のすべての組織からユーザーを選択します。
-
選択した組織のユーザーのみ: 特定の組織を手動で選択できます。「追加」をクリックすることによって、組織を選択できます。選択した組織を削除するには、「削除」をクリックします。
ノート:
証明の完了時、証明者には、組織の組織管理者でもある場合を除き、組織名など、その組織の詳細はわかりません。証明者が組織証明者でない場合は、その組織内のユーザーのみが表示されます。
-
すべてのユーザー: Oracle Identity Manager内のすべてのユーザーを選択します。
-
ユーザー基準: 指定された検索条件を満たすすべてのユーザーを選択します。様々なユーザー属性やユーザー定義フィールド(UDF)に基づいて、基準をフィルタ処理できます。これを行うには、「選択の制約」セクションで詳細な基準を適用するオプションを選択してから、属性およびUDFを選択します。
-
選択したユーザー: システム内のユーザーのリストから、特定のユーザーを選択できます。ユーザーを選択するには、「追加」をクリックします。選択したユーザーを削除するには、「削除」をクリックします。
ノート:
この検索を保存しておき、別のユーザー証明の定義を作成する際、ユーザー基準の指定に使用できます。保存された検索は、特定の証明にマップされません。別のユーザー証明の定義に、ユーザー基準の保存済検索を使用するには:
- 証明の作成中、「ユーザー基準」オプションを選択して検索基準を指定したら、「結果の更新とプレビュー」をクリックする必要があります。これにより、選択した基準が定義に関連付けられます。
- この検索基準をテンプレートとして保存する場合は、「保存」をクリックします。保存しているテンプレートの名前を入力するように求められます。次に、このテンプレートを保存して再利用できます。
保存されたテンプレートは、ある証明に固有のものではありません。別の証明の作成中は、このテンプレートがデフォルトで表示されます。別のテンプレートを新規作成した場合は、そのテンプレートが表示されます。言い換えると、あるタイプの証明に関連付けられたすべての基準画面には、最新のテンプレートが表示されます。
- 生成されたテンプレートを使用しない場合は、保存済検索リスト内の値を、使用するものに変更します。
-
-
基本選択に対する制約を指定するには、次のオプションのいずれかを選択します。
-
任意のレベルのリスクを持つユーザー
-
高リスクのサマリーを持つユーザーのみ
-
高リスクのロールを持つユーザーのみ
-
高リスクのアプリケーション・インスタンスを持つユーザーのみ
-
高リスクの権限を持つユーザーのみ
-
-
「次」をクリックします。「コンテンツ選択」ページが表示されます。
-
「コンテンツ選択」セクションで、次のように選択します:
-
証明内にアクセス権のないユーザーを含めるには、「アカウントのないユーザーを含む」オプションを選択します。
-
「ロール」セクションで、次のいずれかのオプションを選択して、ユーザーごとに認証するロール割当てを制限します:
ノート:
ユーザーごとのロールのリストは、選択したオプションに制限できます。たとえば、選択したロールまたは選択した基準を選択し、1つのロールを追加した場合、そのロールは、カタログで証明可能とマークされている場合にのみ証明内に表示され、それは、ユーザーに他のロールが付与されている場合でも同じです。
-
すべてのロール: すべてのロールを表示する場合に選択します。
-
高リスクのロールのみ: 高リスク・レベルのロールのみを表示し、中および低リスク・レベルのロールを除外する場合に選択します。
-
選択したロールのみ: ロールを手動で選択する場合は、このオプションを選択します。
-
選択したロールの基準: フィルタ基準に基づいてロールを表示する場合に選択します。
-
ルールの外部のロール: メンバーシップ・ルールを介してユーザーに付与されたロールを除外する場合に選択します。
-
ルールの外部の高リスクのロール: メンバーシップ・ルールを介してユーザーに付与された高リスク・レベルのロールを除外し、メンバーシップ・ルールを介して付与されていない高リスク・ロールのみを含める場合に選択します。
ノート:
「ルールの外部のロール」および「ルールの外部の高リスクのロール」オプションは、Oracle Identity Governanceバンドル・パッチ12.2.1.4.210428を適用した後に使用できます。
-
なし: 証明からすべてのロールを除外する場合に選択します。
-
-
「アプリケーション・インスタンス」セクションで、次のように選択します:
-
「証明可能な属性のないアカウントを含む」オプションを選択して、選択したアプリケーション・インスタンスにアカウントを含めます。これは、ターゲット・システム内に証明可能な権限(アクセス権)がない場合でも同じです。このオプションの選択を解除した場合、ターゲット・システム内にあるアカウントのうち、権限が付与されていないものは、証明内に表示されません。
-
ユーザーごとに認証するアプリケーション・インスタンス割当てを制限するには、次のいずれかのオプションを選択します:
ノート:
ロールと同様に、証明内に表示するアプリケーション・インスタンスを制限できます。
-
すべてのアプリケーション・インスタンス: すべてのアプリケーション・インスタンスを含める場合に選択します。
-
高リスクのアプリケーション・インスタンスのみ: 高リスク・レベルのアプリケーション・インスタンスのみを含め、中および低リスク・レベルのアプリケーション・インスタンスを除外する場合に選択します。
-
選択したアプリケーション・インスタンスのみ: アプリケーション・インスタンスを手動で選択する場合は、このオプションを選択します。
-
選択したアプリケーション・インスタンスの基準: フィルタ基準に基づいてアプリケーション・インスタンスを表示する場合に選択します。
-
-
-
次のいずれかのオプションを選択して、証明内に表示できる権限を制限します:
-
すべての権限: 選択すると、すべての権限が表示されます。
-
ロールの外部の権限: 選択すると、ロール/アクセス・ポリシーでプロビジョニングされていない権限のみが表示され、ロール/アクセス・ポリシー経由で付与されたアクセスは除外されます。
-
高リスクの権限を持つアカウント: 選択すると、高リスクの権限のアカウント情報のみが表示されます。
-
高リスクの権限のみ: 選択すると、高リスクの権限のみが表示され、中および低のリスク・レベルの権限は除外されます。
-
ロールの外部の高リスクの権限のみ: 選択すると、高リスクの権限のみが表示され、中および低のリスク・レベルの権限は除外され、ロール/アクセス・ポリシー経由で付与された(すべてのリスクの)すべての権限が除外されます。
-
選択した権限の基準: フィルタ基準に基づいて権限を表示する場合に選択します。
-
-
-
「次」をクリックします。「構成」ページが表示されます。
-
オプション(表13-3を参照)を選択して、「次」をクリックします。「レビューア」ページが表示されます。
拡張委任とともに複数フェーズ・レビューを有効にする場合は、「拡張委任の許可」オプションと「複数フェーズ・レビューの許可」オプションを選択します。
証明ワークフローで証明の監視を有効にする場合は、検索アイコンをクリックし、使用可能なコンポジットを検索して、CertificationOverseerProcessコンポジットを選択してから「追加」をクリックします。
ノート:
「構成」ページで、「自己証明の防止」オプションを選択して代替レビューアを選択した場合、「ロールの検索」レビューア・オプションは選択できません。 -
「レビューア」リストから、主要なレビューアを選択します。プライマリ・レビューアは、ユーザー・マネージャ、組織証明者、任意の選択したユーザーまたは任意の選択したロールになります。プライマリ・レビューアは、次のいずれかになります。
-
ユーザー・マネージャ: プライマリ・レビューアとして、ユーザーのマネージャを選択します。
-
組織証明者: プライマリ・レビューアとして組織証明者を選択します。
-
ユーザーの検索: 参照アイコンをクリックして検索および指定するプライマリ・レビューアとしてユーザーを選択します。
-
ロールの検索: 参照アイコンをクリックして選択するロールのすべてのユーザー・メンバーをプライマリ・レビューアとして選択します。レビューおよび証明するために、ロールの任意のユーザー・メンバーはタスクを請求できます。タスクがユーザーによって請求されると、ロールの他のユーザーは「受信ボックス」にタスクを表示できなくなります。
グループ証明者の割当ては、CertificationProcessコンポジットではサポートされません。プライマリ・レビューアとしてロールを指定する場合は、ウィザードの「構成」ページでCertificationOverseerProcessコンポジットを選択する必要があります。
-
カスタム・アクセス・レビューア: Oracle Identity ManagerデータベースのCERT_CUSTOM_ACCESS_REVIEWERS表に移入して、プライマリ・レビューアを指定するカスタム・レビューア。カスタム・アクセス・レビューアの定義の詳細は、「ユーザー証明のカスタム・レビューア」を参照してください。
複数フェーズ・レビューの場合は、次の操作を行います。
-
「フェーズ1」セクションで、次のいずれかを選択してフェーズ1のレビューアを選択します。
-
ユーザー・マネージャ: ユーザーのマネージャをフェーズ1のレビューアに選択します。
-
組織証明者: 組織証明者をフェーズ1のレビューアに選択します。
-
ユーザーの検索: 参照アイコンをクリックすることによって、任意のユーザーを、検索して指定するフェーズ1のレビューアに選択します。
-
ロールの検索: 参照アイコンをクリックして選択するロールのすべてのユーザー・メンバーをフェーズ1レビューアとして選択します。レビューおよび証明するために、ロールの任意のユーザー・メンバーはタスクを請求できます。タスクがユーザーによって請求されると、ロールの他のユーザーは「受信ボックス」にタスクを表示できなくなります。
グループ証明者の割当ては、CertificationProcessコンポジットではサポートされません。このオプションを選択する場合は、ウィザードの「構成」ページでCertificationOverseerProcessコンポジットを選択する必要があります。
-
カスタム・アクセス・レビューア: Oracle Identity ManagerデータベースのCERT_CUSTOM_ACCESS_REVIEWERS表に移入して、フェーズ1レビューアを指定するカスタム・レビューア。カスタム・アクセス・レビューアの定義の詳細は、「ユーザー証明のカスタム・レビューア」を参照してください。
-
-
「フェーズ2 (オプション)」セクションで、「フェーズ2レビュー・プロセスの有効化」オプションを選択して、ロール割当て、アカウント割当て、権限割当てなどのユーザー権限ごとに、特権証明者がフェーズ2の主要なレビューアになることを指定します。次に、フェーズ2レビューアとして、次のいずれかを選択します。
-
証明者ユーザー: フェーズ2レビューアとしてカタログ証明者ユーザーを選択します。
-
証明者ロール: フェーズ2レビューアとしてカタログ証明者ロールを選択します。カタログ項目に証明者ロールがない場合は、タスクが証明者ユーザーに移動します。権限証明者(ユーザーとロールの両方)が定義されていない場合、タスクはアプリケーション・インスタンス(証明者ユーザー/ロール)に戻されます。
-
-
「最終レビュー(オプション)」セクションで、「最終レビュー・プロセスの有効化」オプションを選択して、最終的な検証およびサインオフに向けて、フェーズ1のレビューアによる最終レビュー・プロセスを有効にします。
-
-
「次」をクリックします。「増分」ページが表示されます。
増分証明は、グループ/ロール証明ではサポートされません。そのため、「レビューア」ページで「ロールの検索」オプションを選択していると、「増分」ページがスキップされて「サマリー」ページが表示されます。
-
「増分データの生成」で「有効」を選択します。この設定では、証明者は、証明または失効の対象を、証明に対して行われた変更または包含のみにできます。証明されたユーザーのアクセス権をレビューする必要はなくなります。
増分証明が有効になっている場合は、次のパラメータが取られます。
-
増分日付範囲(required): 次のものが含まれます。
-
最後のベース以降(デフォルト): このオプションが選択されていると、ユーザーの現在のアクセスが、増分を有効にしないで作成された同じタイプの前回の証明、およびそれ以降で証明が作成された現在日付までのすべての増分証明に対して比較されます。
-
開始日: このオプションが選択されていると、ユーザーの現在のアクセスが、指定された日付以降で証明が作成された時点での、同じタイプの証明すべてに対して比較されます。
-
-
以前の値を表示(オプション): 次のものが含まれます。
-
無効(デフォルト): この選択が解除されていると、「増分日付範囲」パラメータに基づいて前の証明にすでに表示されていた値は、証明に含まれません。
-
有効: これが選択されていると、前の証明に存在していたすべての現在値が、これらのアクセスに対して前回行われた意思決定とともに表示されます。
-
-
-
「次」をクリックします。「サマリー」ページが、ユーザー証明の詳細とともに表示されます。
-
「作成」をクリックして、ユーザー証明を作成します。メッセージが表示され、定義に基づいて証明ジョブを作成し、すぐに実行するかどうか尋ねられます。ジョブ名を編集し、「はい」をクリックして証明ジョブを実行できます。
または、「いいえ」をクリックし、スケジュール済ジョブの作成と実行をしないで、証明の定義を作成します。このオプションを使用した場合は、証明ジョブを後で手動で作成する必要があります。
新規のユーザー証明の定義は、「証明の定義」ページに表示されます。
ノート:
拡張委任を使用した複数フェーズ・レビューの場合は、次のようになります。
-
証明が100%完了となるのは、フェーズ2のレビューアまたはテクニカル・レビューアがすべてのレビューを完了したときです。2フェーズ・レビューにおいて、証明が行われているフェーズごとに、フェーズと完了の進捗度(パーセンテージ)が証明ステータスに表示されます。このステータスを表示するには、「受信箱」または「ダッシュボード」で「進行中」証明をクリックします。
-
証明は、最終レビューのためにフェーズ1の主要なレビューアに渡されます。ページ2では、フェーズ1の主要なレビューアが、(グレー表示されている)最初と2番目のフェーズでユーザーの行ったアクション、およびシステムで生成されたデフォルトのアクション(フェーズ1の主要なレビューアによる無効化が可能)をレビューできます。
13.3.1.2 ロール証明の定義の作成
ロール証明の定義を作成するには:
-
Oracle Identity Self Serviceにログインします。
-
「コンプライアンス」タブをクリックします。
-
「アイデンティティの証明」ボックスをクリックして、「定義」を選択します。「証明の定義」ページが表示されます。
-
「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「新規証明」ウィザードの「一般の詳細」ページが表示されます。
-
次の値を入力します。
-
名前: 証明の名前を入力します。
-
タイプ: ロール証明の定義を作成する場合は「ロール」を選択します。
-
説明: 必要に応じて、新規のロール証明の定義の説明を入力します。
-
-
「次」をクリックします。「新規証明」ウィザードの「基本選択」ページが表示されます。
-
このページの「基本選択」セクションで、次に示すように、リストからロール選択戦略を選択します。
-
すべての組織のすべてのロール: Oracle Identity Manager内のすべての組織のすべてのロールを選択します。
-
選択した組織のロール: 指定した組織からロールを選択します。「追加」をクリックし、組織を検索して選択します。選択した組織を削除するには、「削除」をクリックします。
ノート:
証明の完了時、証明者には、組織管理者でもある場合を除き、組織名など、その組織の詳細はわかりません。証明者が組織証明者でない場合は、その組織内のユーザーのみが表示されます。
-
すべてのロール: Oracle Identity Manager内のすべてのロールを選択します。
-
ロール基準: 指定された検索条件を満たすすべてのロールを選択します。この選択の結果はプレビューできます。
ヒント:
この検索を保存しておき、別のロール証明の定義を作成する際、ロール基準の指定に使用できます。保存された検索は、特定の証明にマップされません。別のロール証明の定義に、ロール基準の保存済検索を使用するには:
-
証明書の作成中、「ロール基準」オプションを選択して検索基準を指定したら、「結果の更新とプレビュー」をクリックする必要があります。これにより、選択した基準が定義に関連付けられます。
-
この検索基準をテンプレートとして保存する場合は、「保存」をクリックします。保存しているテンプレートの名前を入力するように求められます。次に、このテンプレートを保存して再利用できます。
-
保存されたテンプレートは、ある証明に固有のものではありません。別の証明の作成中は、このテンプレートがデフォルトで表示されます。別のテンプレートを新規作成した場合は、そのテンプレートが表示されます。言い換えると、あるタイプの証明に関連付けられたすべての基準画面には、最新のテンプレートが表示されます。
-
生成されたテンプレートを使用しない場合は、保存済検索リスト内の値を、使用するものに変更します。
-
-
選択したロール: ロールを手動で選択できます。
-
-
制約を指定するには、次のオプションのいずれかを選択します。
-
任意のレベルのリスクを持つロール
-
高リスクのロールのみ
-
-
「次」をクリックします。「コンテンツ選択」ページが表示されます。
-
「ポリシーの証明」を選択して、ポリシーの証明を指定します。「メンバーの証明」を選択して、ロール・メンバーの証明を指定します。
-
「次」をクリックします。「構成」ページが表示されます。
-
構成オプション(表13-3を参照)を選択して、「次」をクリックします。「レビューア」ページが表示されます。
ノート:
「構成」ページで、「自己証明の防止」オプションを選択して代替レビューアを選択した場合、「ロール - 証明者ユーザー」および「ロール - 証明者ロール」レビューア・オプションは選択できません。 -
「レビューア」リストから、主要なレビューアを選択します。プライマリ・レビューアは、次のいずれかになります。
-
ロール(証明者ユーザー): プライマリ・レビューアとして証明者ユーザーを選択します。
-
ロール(証明者ロール): プライマリ・レビューアとして証明者ロールを選択します。
-
組織証明者: プライマリ・レビューアとして組織証明者を選択します。
-
ユーザーの検索: 参照アイコンをクリックして検索および指定するプライマリ・レビューアとしてユーザーを選択します。
-
ロールの検索: 参照アイコンをクリックして選択するロールのすべてのユーザー・メンバーをプライマリ・レビューアとして選択します。レビューおよび証明するために、ロールの任意のユーザー・メンバーはタスクを請求できます。タスクがユーザーによって請求されると、ロールの他のユーザーは「受信ボックス」にタスクを表示できなくなります。
グループ証明者の割当ては、CertificationProcessコンポジットではサポートされません。プライマリ・レビューアとしてロールを指定する場合は、ウィザードの「構成」ページでCertificationOverseerProcessコンポジットを選択する必要があります。
-
-
「次」をクリックします。「増分」ページが表示されます。
増分証明は、グループ/ロール証明ではサポートされません。そのため、「レビューア」ページで「ロールの検索」オプションを選択していると、「増分」ページがスキップされて「サマリー」ページが表示されます。
-
「増分データの生成」で「有効」を選択します。この設定では、証明者は、証明または失効の対象を、証明に対して行われた変更または包含のみにできます。証明されたユーザーのアクセス権をレビューする必要はなくなります。
増分証明が有効になっている場合は、次のパラメータが取られます。
-
増分日付範囲(required): 次のものが含まれます。
-
最後のベース以降(デフォルト): このオプションが選択されていると、ユーザーの現在のアクセスが、増分を有効にしないで作成された同じタイプの前回の証明、およびそれ以降で証明が作成された現在日付までのすべての増分証明に対して比較されます。
-
開始日: このオプションが選択されていると、ユーザーの現在のアクセスが、指定された日付以降で証明が作成された時点での、同じタイプの証明すべてに対して比較されます。
-
-
以前の値を表示(オプション): 次のものが含まれます。
-
無効(デフォルト): この選択が解除されていると、「増分日付範囲」パラメータに基づいて前の証明にすでに表示されていた値は、証明に含まれません。
-
有効: これが選択されていると、前の証明に存在していたすべての現在値が、これらのアクセスに対して前回行われた意思決定とともに表示されます。
-
-
-
「次」をクリックします。「サマリー」ページが、ユーザー証明の詳細とともに表示されます。
-
「作成」をクリックします。メッセージが表示され、定義に基づいて証明ジョブを作成し、すぐに実行するかどうか尋ねられます。ジョブ名を編集し、「はい」をクリックして証明ジョブを実行できます。
または、「いいえ」をクリックし、スケジュール済ジョブの作成と実行をしないで、証明の定義を作成します。このオプションを使用した場合は、証明ジョブを後で手動で作成する必要があります。
新規のロール証明の定義は、「証明の定義」ページに表示されます。
13.4 証明のスケジュール設定
証明の定義を作成する必要があり、作成が済んだらスケジュール設定できます。
証明は、証明作成プロセスの一環としてスケジュール設定されます。詳細は、「証明の定義の作成」を参照してください。証明は、一度実行するようにスケジュール設定することも、毎日、毎週または毎月繰り返すようにスケジュール設定することもできます。
「新規証明」ウィザードの「サマリー」ページで「作成」をクリックして証明の定義を作成したら、メッセージが表示され、証明ジョブを作成して実行するかどうか尋ねられます。スケジュール済ジョブ名は「ジョブ名」ボックスで編集できます。「はい」をクリックすると、新規証明の定義用に証明ジョブが作成されて実行されます。Oracle Identity System Administrationの「スケジューラ」セクションに移動してジョブを検索できます。ジョブのデフォルト名はCert_DEFINITION_NAMEです。
証明ジョブは、「証明作成タスク」スケジュール済タスクに基づいて作成されます。このスケジュール済タスクは、定義された証明の定義用に証明ジョブを新規作成するために使用されます。ジョブが実行されると、証明の定義が使用され、証明が生成されます。
「証明作成タスク」スケジュール済タスクについては、Oracle Identity Governanceの管理の事前定義済のスケジュール済タスクに関する項を参照してください。証明ジョブは、Oracle Identity System Administrationの「スケジューラ」セクションから変更できます。Oracle Identity Governanceの管理のジョブの変更に関する項を参照してください。
証明は、Oracle Identity System Administrationの「スケジューラ」セクションからスケジュール設定することもできます。これを行うには、Oracle Identity Governanceの管理のジョブの作成に関する項の手順に従います。この方法では、「ジョブの作成」ページの「タスク」フィールドで証明作成タスクを選択します。
証明ジョブを変更するときには、「ジョブの詳細」ページの「証明の定義名」フィールドで証明の定義名を指定します。
13.5 リスク・サマリーの計算方法について
ロール、アプリケーション・インスタンスおよび権限に、また事前定義された特定のリスク係数に、高、中、低の各リスク・レベルを直接割り当てることができます。
リスク集計ジョブでは、アイデンティティ証明をサポートするために必要な、レベルの高い残りのデータ・オブジェクトのリスクのサマリーが計算されます。これらのオブジェクトには、Oracle Identity Managerにおけるあらゆるユーザー、ユーザー・ロール割当て、アカウントおよび権限割当てが含まれます。アイデンティティ証明中に、証明者はリスクのサマリーを使用して、高リスクの証明項目を中リスクおよび低リスクの項目から切り離します。
この項では、システムがリスク・レベルをどのように処理してリスクのサマリーを導き出すかについて説明します。また、リスク集計ジョブについても説明します。このジョブは、手動で実行することも、スケジュールを設定して実行することもできます。次の項目が含まれます。
ノート:
ロール、アプリケーション・インスタンスおよび権限がメタデータ・オブジェクトであるのに対し、ユーザー、アカウントおよび権限割当てはインスタンスデータ・オブジェクトです。
メタデータ・オブジェクトが、Oracle Identity Manager内の情報システムを表して記述した構造化オブジェクトであるのに対し、インスタンスデータ・オブジェクトは、システムに移入するアプリケーション・データの個別インスタンスです。たとえば、ロールが事前定義されていて、それによりユーザーがトラブル・チケット(権限)を作成できるカスタマ・サービス・アプリケーション(リソース)を考えてみます。この例では、1つのリソース・オブジェクトはアプリケーションを表し、1つの権限オブジェクトはそのアプリケーション内の特定の権限を表しています。
このリソースには膨大な数のユーザー・アカウントがある場合があり、そのうちの一部のサブセットには権限割当てがあり、それによってユーザーがトラブル・チケットを作成できると考えてみましょう。1つのリソース(メタデータ・オブジェクト)には複数のアカウント(インスタンスデータ・オブジェクト)が存在する場合があり、1つの権限(メタデータ・オブジェクト)には複数の割当てインスタンス(インスタンスデータ・オブジェクト)が存在する場合があります。Oracle Identity Managerでは、インスタンスデータ・オブジェクトのリスク・レベルが計算されます。あらゆるユーザー、アカウントおよび権限割当てのリスク・レベルを人間が繰り返し処理するというのは現実的でないからです。
13.5.1 項目リスクとリスク係数のマッピングの理解
項目リスクとは、特定のロール、アプリケーション・インスタンスおよび権限に対して、様々な管理者が割り当てることのできるリスク・レベルのことです。リスク係数のマッピングとは、事前定義された特定の条件にリスク・レベルをマップする設定です。
項目リスクとリスク係数のマッピングは、直接制御の対象となる設定です。
この項の内容は次のとおりです。
13.5.1.1 項目リスクの設定
項目リスクとは、特定のロール、アプリケーション・インスタンスおよび権限に対して、様々な管理者が割り当てることのできるリスク・レベルのことです。
ノート:
3つの帯は高リスク、2つの帯は中リスク、1つの帯は低リスクを示しています。
メタデータ・オブジェクトに項目リスク・レベルを直接割り当てない場合は、Oracle Identity Managerによって、デフォルトの項目リスク・レベルが割り当てられます。ロール、アプリケーション・インスタンス、権限それぞれにデフォルト値を設定できます。
メタデータ・オブジェクトのデフォルトの項目リスク・レベルを設定するには:
- Oracle Identity Self Serviceにログインします。
- 「コンプライアンス」タブをクリックします。
- 「アイデンティティの証明」ボックスをクリックして、「リスク構成」を選択します。「リスク構成」ページが表示されます。
- 項目ごとに、「高」、「中」、「低」いずれかのリスクのラジオ・ボタンを選択します。
- 「保存」をクリックします。
高度に制限された権限をユーザーに付与するメタデータ・オブジェクトに対して、項目リスクの高レベルを予約する必要があります。オブジェクトに項目リスクの高レベルを設定すると、その親オブジェクトの「リスクのサマリー」にも高い値が設定されることに注意してください。同様に、オブジェクトに項目リスクの中レベルを設定すると、その親オブジェクトの「リスクのサマリー」に中以上の値が設定されます。レベルの高いオブジェクトに「リスクのサマリー」の低い値を設定するには、システム階層でその下にあるオブジェクトのすべてに低リスクを設定する必要があります。
13.5.1.2 リスク・レベルのマッピング(リスク係数)について
リスク係数のマッピングとは、事前定義された特定の条件にリスク・レベルをマップする設定です。たとえば、「オープン監査違反を有する項目」を高リスクとして構成し、「受けいれられたリスクとしてクローズされた項目」を中リスクとして構成するようなことがあります。
一般的に言えば、不規則または危険となる可能性のあるユーザーに権限が拡張される状況に対して、リスク係数の高いレベルを予約する必要があります。
Oracle Identity Managerにはリスク係数のカテゴリが3つあり、それぞれのカテゴリには複数の設定が含まれています。表13-4に、リスク要因のカテゴリを示します。
表13-4 リスク係数
| リスク係数 | 説明 |
|---|---|
|
プロビジョニング・シナリオ/割当てのシナリオ |
プロビジョニング・シナリオは、ロール、アカウントまたは権限割当てをユーザーに割り当てる際に使用される方法またはメカニズムに関連付ける必要のあるリスク・レベルを定義します。 たとえば、管理者によって直接プロビジョニングされるオブジェクトには、リスク・レベルとして「中」を構成し、ロールに関連付けられているポリシーに基づいてプロビジョニングされるオブジェクトには、リスク・レベルとして「低」を構成するとします。リコンシリエーションを介してOracle Identity Managerに引き込まれるオブジェクトには、リスク・レベルとして「高」を構成するとします。 |
|
前回の証明アクション |
検討中のアカウント、権限割当てまたはユーザー・ロール割当ての前回証明のステータスに基づいて、リスク・レベルを定義します。 たとえば、前回の証明決定が承認することであった任意の項目には、リスク・レベルとして「低」を構成し、前回の証明決定が「条件付きで証明」であった任意の項目には、リスク・レベルとして「中」を構成するとします。最後に、前回の証明決定が「棄権」または「失効」であった任意の項目には、値として「高」を構成するとします。 |
|
アイデンティティ監査違反 |
未解決のアイデンティティ監査違反に含まれる原因に関連付けられるリスク・レベルを定義します。原因は、アカウント、権限割当てまたはユーザー・ロール割当てに関連付けられます。たとえば、関連する原因がアクティブな違反にあるオブジェクトには、このような状況が職務の分離(SoD)違反を表すため、リスク・レベル「高」を構成できます。関連する原因が未解決のアイデンティティ監査違反にオブジェクトにない場合は、リスク・サマリーの計算時にこのリスク要因はスキップされます。 |
ノート:
UIの「リスク構成」ページでリスク・レベルのマッピングを変更すると、大きなさざ波効果が発生する可能性があり、発生したらOracle Identity Manager全体で「リスクのサマリー」に影響を与えます。初期設定において、「リスク・レベル」構成ページでマッピングを構成し、不要な変更を追加しなくて済むようにする必要があります。「リスクのサマリー」に影響を与えるさざ波効果の詳細は、「リスク構成値の変更がシステムに与える影響について」を参照してください。
13.5.2 リスク集計とリスクのサマリーについて
「リスク集計タスク」スケジュール済ジョブでは、項目リスク・レベルとリスク係数レベルが処理され、アイデンティティ証明をサポートするレベルの高いオブジェクトごとに、リスクのサマリーが計算されます。
リスク集計タスクは、事前定義済のリスク集計ジョブに情報を提供するために使用されます。このタスクを使用してジョブを新規作成する必要はありません。このタスク・タイプのジョブが実行されたら、Oracle Identity Manager内のすべてのユーザーの、前回更新以後のリスクが計算されます。このスケジュール済タスクの詳細は、Oracle Identity Governanceの管理の事前定義済のスケジュール済タスクに関する項を参照してください。「リスク集計タスク」スケジュール済ジョブは、Oracle Identity Governanceの管理のジョブの無効化と有効化に関する項に示す手順に従って有効化することができます。
リスク集計の最初のフェーズでは、「リスク集計タスク」スケジュール済ジョブにより、それぞれの個別オブジェクトの項目リスク・レベルおよびその3つのリスク係数レベルが評価され、4つのうち最も高いレベルがオブジェクトの「リスクのサマリー」プロパティに割り当てられます。個別のユーザー・オブジェクト、ユーザー・ロール割当てオブジェクト、アカウント・オブジェクトおよび権限割当てオブジェクトごとに、リスクのサマリーの値が計算されます。次のダイアグラムに、このプロセスを示します。
あらゆるオブジェクトのリスクのサマリーが計算されたら、次の集計フェーズが開始されます。このフェーズでは、個別のオブジェクトそれぞれのリスクのサマリーが合算されて、そのオブジェクトを含む親オブジェクトのリスクのサマリーになります。
権限割当てレベルの上で、各データ・オブジェクトのリスクのサマリーの値が、そのオブジェクトを含む親オブジェクトのリスクのサマリーにつながります。たとえば、アカウント・オブジェクトは権限割当てオブジェクトより1階層上のレベルであり、ユーザー・オブジェクトはそこからさらに1階層上のレベルです。したがって、アカウント・オブジェクト内のあらゆる権限割当てオブジェクトのリスクのサマリーは、そのアカウントのリスクのサマリーにつながり、同様に、ユーザー・オブジェクト内のあらゆるアカウント・オブジェクトのリスクのサマリーは、そのユーザーのリスクのサマリーにつながります。
ユーザー・オブジェクトはまた、ユーザー・ロール割当てオブジェクトより1つ上のレベルなので、あらゆるユーザー・ロール割当てオブジェクトのリスクのサマリーは、そのユーザーのリスクのサマリーにつながります。
次のダイアグラムに、このプロセスを示します。
このダイアグラムでは、権限割当てのリスクのサマリーの値が合算されて、アカウント・オブジェクトになります。アカウントのリスクのサマリーの値とユーザー・ロール割当てのリスクのサマリーの値が合算されて、関連付けられている任意のユーザーのリスクのサマリーになります。
13.5.3 リスク構成値の変更がシステムに与える影響について
リスクのサマリーの値に影響を与える可能性のあるアクションまたはシステム・イベントが、大きく分けて3つあります。この影響は、アクションまたはシステム・イベントに応じて、軽度、中程度または重度となります。
リスクのサマリー値に影響を与える可能性のある各アクションまたはイベントと、その結果についての説明は表13-5を参照してください。
表13-5 リスクのサマリーの値に影響を与える可能性のあるアクションまたはシステム・イベント
| アクションまたはイベント | 影響 | 説明 |
|---|---|---|
|
ユーザーまたはOracle Identity Manager、あるいはその両方が、個別の権限を変更する |
軽度 |
アカウント、権限、ユーザー・ロール割当てなど、個別のデータ・オブジェクトに対する変更に該当します。これらの値は、頻繁に変化することが考えられます。たとえば、このカテゴリに含まれる変更のタイプは次のとおりです。
Oracle Identity Manager内での影響は相対的に小さなものとなります。変化は個別の各権限のレベルで発生するからです。 |
|
管理者が、ロール、リソースおよび権限に対して項目リスクの変更を行う |
中程度 |
ロール、アプリケーション・インスタンスまたは権限のリスク・レベルを、様々な管理者が変更するという状況に該当します。 これらの変更のさざ波効果は、大きなものとなる可能性があります。メタデータ・オブジェクトに対するリスク・レベルを変更すると、そのメタデータ・オブジェクトに関連付けられているあらゆるデータオブジェクトに対する項目リスク・レベルが変更される場合があります。データオブジェクトに対するリスク・レベルを変更すると、そのリスクのサマリー、さらに、そのデータオブジェクトを含む他のあらゆるデータオブジェクトのリスクのサマリーに影響が及ぶ場合があります。 たとえば、権限定義に対するリスク・レベルを変更すると、その権限定義に対応するその権限のあらゆる割当てに対する項目リスクが変更されます。権限割当てに対する項目リスクを変更すると、そのリスクのサマリーが変更される場合があります。権限割当てのリスクのサマリーを変更すると、親アカウントのリスクのサマリーに影響が及ぶ場合があります。アカウントのリスクのサマリーを変更すると、そのアカウントを所有するユーザーのリスクのサマリーに影響が及ぶ場合があります。 |
|
管理者が、リスク・レベルのマッピングに対して構成の変更を行う |
重度 |
Oracle Identity System Administrationの「リスク構成」ページでリスク・レベルのマッピングを、様々な管理者が変更するという状況に該当します。 特定のリスク係数の特定の値に関連付けられているリスク・レベルを変更すると、そのリスク係数の値を持つ、任意のユーザー・ロール割当て、アカウントまたは権限割当てのリスクのサマリーに影響が及ぶ可能性があります。任意のユーザー・ロール割当て、アカウントまたは権限割当てのリスクのサマリーを変更すると、影響を受けるユーザー・ロール割当て、アカウントまたは権限割当てに関連付けられるあらゆるユーザーに影響が及ぶ可能性があります。 このため、リスクレベルのマッピングを変更するのは、ごくまれにしてください。 |
13.6 クローズド・ループ是正および是正のトラッキングについて
クローズド・ループ是正とは、証明プロセス中にロールおよび権限が失効される結果として、プロビジョニング・ソリューションからロール、アプリケーション・アカウントおよび権限を直接失効させることを可能にする機能です。
証明が完了し、主要なレビュー・タスクがすべてサインオフされたら、Oracle Identity Managerでは、失効させることを最終決定としていたユーザーおよび権限をすべて削除しようとします。リクエストが作成されることによって、失効される任意のロール割当ての割当てが解除され、失効される任意のアカウントのプロビジョニングが解除され、失効される任意の権限割当てが削除され、失効される任意のユーザーが削除または無効化されます。具体的には、次のようになります。
-
ユーザーを失効させると、そのユーザーが削除/無効化され、そのユーザーの権限がすべて削除されます。
-
ユーザーのロール割当てを失効させると、そのメンバーがロールから削除されます。これにより、最終的に、ロールによって付与されているアカウントおよび権限割当てが、プロビジョニングによって削除される場合があります(これらのアカウントおよび権限割当てが、そのユーザーに別の方法で付与されていない場合)。
-
ユーザーのアカウントを失効させると、そのアカウントが削除/無効化されます。そのアカウントに関連付けられている権限割当てがあれば、これによって暗黙的に削除/無効化されます。
-
ユーザーの権限割当てを失効させると、その割当てを含むアカウントから割当てが削除されます。
是正ステータスは、監査を目的として、リクエスト・カタログで追跡できます。それぞれの是正リクエストには、そのリクエストを生成した証明の証明IDが含まれており、それにより、ダッシュボードはOracle Identity Self Serviceの「リクエストのトラッキング」ページにリンクして、表示されている証明に関連付けられているすべてのリクエストのステータスを表示できます。
13.7 チャレンジ・ワークフローの構成
クローズド・ループ是正の結果として生成されたリクエストの一部は、チャレンジ・ワークフローを通過します。このリクエストは自動承認されるように構成できます。
この項では、次の各トピックでチャレンジ・ワークフローの構成方法について説明します。
13.7.1 チャレンジ・ワークフローについて
クローズド・ループ是正の結果として生成されたリクエストは、自動承認されるかチャレンジ・ワークフローを通過します。
デフォルトでは、クローズド・ループ是正は次のように機能します。
-
証明書をサインオフした人間(最終レビューア)がユーザー(受益者)のマネージャである場合は、リクエストは自動承認されます。
-
最終レビューアがユーザーのマネージャでない場合は、リクエストはチャレンジ・ワークフローを通過していきます。具体的には次のように処理されます。
-
アクセスが失効されているユーザー(受益者)にリクエストが送信されます。
-
受益者がリクエストを承認することによって失効を受け入れた場合には、クローズド・ループ是正が発生してアクセスが失効されます。
-
受益者がリクエストを却下することによって失効に異議を申し立てた場合には、証明をサインオフした人間(最終レビューア)にリクエストが返送されます。
-
最終レビューアがこの異議申立てを受け入れた場合には、プロセスは停止し、受益者のアクセスは失効されません。
-
最終レビューアがこの異議申立てを却下した場合には、クローズド・ループ是正が発生してアクセスが失効されます。
-
-
13.7.2 自動承認のルールの変更
自動承認ロジックは、SOAのDefaultRequestApprovalコンポジット内でルールを使用して定義されます。すべてのクローズド・ループ是正リクエストが自動承認されるようにルールを変更できます。
すべてのクローズド・ループ是正リクエストが自動承認されるようにルールを変更するには:
- 「ルール1」を選択し、Oracle SOAコンポーザのメニュー・バーにある「セッションの編集」をクリックして、ルールの詳細を表示します(図13-1を参照)。
13.8 イベント・リスナーについて
イベント・リスナー・メカニズムによって、特定のビジネス・イベントが検出され、イベントの詳細が証明のために格納されます。
格納されたイベントの詳細は、証明イベント・トリガーと呼ばれ、スケジュール済ジョブとして実行される証明イベント・トリガー・タスクによって、証明に加工されます。イベント・リスナーによって現在検出されているビジネス・イベントは、個別または一括による、Oracle Identity Managerユーザーの変更です。
「証明の定義の管理」で説明しているように、それぞれのイベント・リスナーにルールセットと証明の定義が含まれています。ルールセットには1つ以上のルールが含まれており、それぞれのルールは1つ以上の条件をテストし、その条件が満たされた場合に行うアクションを指定しています。イベント・リスナーのルールに対する標準的なアクションは、証明イベント・トリガーを格納することであり、このトリガーによって特定されるのは、イベント・リスナー、変更されたユーザー、およびこのイベントに対応して生成される証明の定義です。
トリガーは、証明イベント・トリガー・ジョブの実行と実行の間に蓄積されます。ジョブが実行されると、そのイベント・リスナーの識別子によってグループ分けされ、対応するイベント・リスナーのプロパティに従って、各グループが処理されます。デフォルトでは、トリガー・ジョブにより、証明のテンプレートにリスナーの証明の定義を使用して、トリガーの各グループにおけるすべてのユーザーの証明が作成されます。この後で、完成したグループ内のトリガーが削除されます。
イベント・リスナーのトリガーがトリガー・ジョブによってどのように処理されるかに影響を与えるプロパティがいくつかあります。最初のプロパティによって、リスナーがアクティブな状態にあるか無効な状態にあるかが判別されます。リスナーが無効になっている場合は、ビジネス・イベントが発生したときにルールが評価されなくなるため、そのリスナーからトリガーは格納されません。リスナーがトリガーを格納してから無効になった場合は、次のトリガー・ジョブが実行され、格納されたトリガーは処理されずに削除されます。無効になっているリスナーが元のアクティブな状態に設定されると、トリガー・ジョブによって処理されるトリガーをもう一度格納できます。
トリガーの処理に影響を与える別のイベント・リスナーのプロパティは、そのイベント数です。これは、トリガー・ジョブの1回の実行中に、そのリスナーでいくつのトリガーを処理できるかを制限するものです。この設定はオプションです。これが指定されていない場合は、その数字は無制限です。イベント数が指定されている場合は、処理できるトリガーの最大数を表しています。トリガー・ジョブが実行されると、トリガーのバッチごとのリスナーのイベント数がチェックされ、トリガーの数がイベント数を超えている場合は、トリガーが破棄され、証明も生成されません。この機能は、ユーザーが一括で変更されたときに、膨大な数の証明が作成されないようにする際に役立ちます。
最終的に、トリガー・ジョブ自体は、特定のイベント・リスナーからのトリガーを処理し、それ以外のものは処理しないように構成できます。この機能は、イベント・リスナー名リストという、証明イベント・トリガー・タスクのパラメータによって制御されます。トリガー・ジョブの定義においてこのパラメータが空白のままになっている場合は、トリガー・ジョブが実行されたときに、すべてのリストからのトリガーが処理されます。名前リストが定義されている場合は、ジョブが実行されたときに、そのリストに含まれているリスナーのトリガーのみが処理されます。他のリスナーからのトリガーは無視され、その後のトリガー・ジョブ実行に備えて保持されます。スケジュール済ジョブの複数のインスタンスが証明イベント・トリガー・タスクに向けて定義されていると、イベント・リスナーの各リストにより、最も適切なスケジュールでトリガーを処理させることができます。
ノート:
あるリスナー名が複数のイベント・リスナー名リストに表示されている場合、またはトリガー・ジョブのいずれかに空のイベント・リスナー名リストがある場合は、これらのうち、最初に実行するジョブでは、そのリスナーのトリガーがすべて消費されます。トリガーは、初めて処理された後で常に破棄されます。
13.9 イベント・リスナーおよび証明イベント・トリガー・ジョブの構成
イベント・リスナーの構成には、イベント・リスナーの作成、変更および削除が含まれます。証明イベント・トリガー・ジョブの構成には、イベント・リスナー名の設定とモード・トリガー・ジョブの追加が含まれます。
この項では、次の各トピックでイベント・リスナーと証明イベント・トリガー・ジョブの構成について説明します。
13.9.1 イベント・リスナーの作成
イベント・リスナーの作成には、イベント・リスナーの属性値を指定する操作と、イベントの発生時に評価される条件を含んでいるルールを追加する操作が含まれます。
イベント・リスナーを新規作成するには:
ノート:
イベント・リスナーを作成する前に、証明イベント・トリガー・ジョブが実行されたときに実行される、ユーザー証明の定義またはアプリケーション・インスタンス証明の定義を作成する必要があります。
-
Oracle Identity Self Serviceにログインします。
-
「コンプライアンス」タブをクリックします。
-
「アイデンティティの証明」ボックスをクリックして、「イベント・リスナー」を選択します。「イベント・リスナー」ページが表示されます。
-
「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「イベント・リスナーの作成」ページが表示されます。
-
「リスナー・プロパティ」セクションで、イベントの識別に使用する名前、および説明を指定します。
-
「証明の定義」リストから、実行される証明の定義を選択します。
-
「イベント数」ボックスに、証明イベント・トリガー・ジョブが実行された時点でこのリスナーで処理するイベントの最大数を入力します。これは、一括更新のアクションを回避する場合に使用します。
-
「ステータス」リストから、ステータスとして「アクティブ」または「無効」を選択します。
-
「イベント・トリガー」セクションで、イベントが発生したときに評価される条件を含むルールを追加します。たとえば、ユーザーが更新されたときに、ある条件では、ユーザーのtitleプロパティまたはlocationプロパティが変化したかどうかをチェックできます。別の例としては、ユーザーのマネージャの変更も考えられます。
条件を追加するには:
-
「ルール」パネルで、プラス(+)アイコンをクリックし、下向き矢印キーをクリックして一般的なルールを選択します。新しいルールが含まれます。
-
ルールを選択すると、右側にルールの詳細が表示されます。
-
「IF」の下側にあるプラス(+)アイコンをクリックし、下向き矢印キーをクリックしてリストからタイプを選択します。たとえば、「Simple Test」を選択します。
-
参照アイコンをクリックして、条件ブラウザを開きます。
-
「Modified User」、「previousValue」をクリックします。「manager」を選択し、「OK」をクリックします。これにより、
ModifiedUser.previousValue.Managerを設定します。 -
「次に一致しない」のような条件演算子を選択します。
-
2番目の参照アイコンをクリックし、属性名を検索および選択して、「OK」をクリックします。そうすると、次の条件が設定されます。
ModifiedUser.previousValue.Manager isn't ModifiedUser.currentValue.Manager
-
「THEN」の下で、「アクションの追加」の左側にあるプラス(+)アイコンをクリックします。
-
下矢印キーをクリックして、「call」を選択します。
-
リストから「certifyThisUser」を選択します。
複数のルールが構成されていると、拡張プロパティ(優先度、モード、ステータスなど)を設定できます。ルールに拡張プロパティを指定するには:
-
「ルール」パネルで、ルールを選択します。ルールの詳細が、右側に表示されます。
-
「プロパティ」リンクをクリックして、拡張プロパティ・ウィンドウを開きます。
-
情報として、「名前」、「説明」、「優先度」、「アクティブ」、拡張モード、ツリー・モードおよび「有効日」を指定します。
ルールの拡張プロパティ設定の詳細は、Oracle Business Process Managementによるビジネス・ルールの設計のルールの拡張設定の表示方法と編集方法に関する項を参照してください。
-
-
「作成」をクリックして、イベント・リスナーを作成します。
証明イベント・トリガー・ジョブが実行されると、マネージャが変更されたユーザーの証明が作成されます。
イベント・リスナーのルールの例としては、ある属性が特定の値に変更されたかどうかをチェックすることが考えられます。たとえば:
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")
13.9.2 イベント・リスナーの変更
イベント・リスナーの変更には、「イベント・リスナー」ページでイベント・リスナーを選択する操作と、イベント・リスナーの詳細ページでイベント・リスナーの属性を編集する操作が含まれます。
イベント・リスナーを変更するには:
- Oracle Identity Self Serviceの「コンプライアンス」タブで、「アイデンティティの証明」ボックスをクリックして「イベント・リスナー」を選択します。「イベント・リスナー」ページが、イベント・リスナーのリストとともに表示されます。
- 変更するイベント・リスナーを選択します。
- 「アクション」メニューから「開く」を選択します。または、ツールバーにある「開く」をクリックします。イベント・リスナーの詳細ページが表示されます。
- イベント・リスナーを変更するフィールドで値を編集します。
- 「保存」をクリックします。
13.9.3 イベント・リスナーの削除
イベント・リスナーの削除には、「イベント・リスナー」ページでイベント・リスナーを選択する操作と、「削除」オプションを使用する操作が含まれます。
イベント・リスナーを削除するには:
- Oracle Identity Self Serviceの「コンプライアンス」タブで、「アイデンティティの証明」ボックスをクリックして「イベント・リスナー」を選択します。「イベント・リスナー」ページが、イベント・リスナーのリストとともに表示されます。
- 削除するイベント・リスナーを選択します。
- 「アクション」メニューから「削除」を選択します。または、ツールバーにある「削除」をクリックします。確認を求めるメッセージが表示されます。
- 「はい」をクリックして確認します。
13.9.4 証明イベント・トリガー・ジョブの構成
証明イベント・トリガー・ジョブには、イベント・リスナー名リストというオプションのパラメータがあります。このフィールドに1つ以上のイベント・リスナー名が指定されている場合には、トリガー・ジョブでは、それらのリスナーのトリガーのみが処理されます。これは、すべてのリスナーの処理をカバーするには、複数のトリガー・ジョブが必要になるという意味です。
この項では、イベント・リスナー名リスト・パラメータの設定方法と複数のトリガー・ジョブの定義方法について説明します。次の項目が含まれます。
13.9.4.1 イベント・リスナー名リストの設定
イベント・リスナー名リストを設定するには:
- Oracle Identity System Administrationにログインします。
- 左ペインの「システム構成」で、「スケジューラ」をクリックします。
- 検索フィールドに
「Certification Event Trigger Job」と入力して、検索を実行します。 - 検索結果内でジョブ名をクリックし、トリガー・ジョブの詳細を表示します。
- 下にスクロールし、「Parameters」セクションまで移動します。そこには、(カンマで区切られた)「Event Listener Name List」というパラメータが表示されています。
- 1つ以上のイベント・リスナー名を、カンマで区切ってこのフィールドに入力します。各リスナーの名前は、「イベント・リスナー」表の「名前」列に表示されているとおりに入力するようにしてください。
- 「適用」をクリックして変更を保存します。
13.9.4.2 さらなるトリガー・ジョブの追加
証明イベント・トリガー・ジョブの事前定義済インスタンスに加え、次のステップを実行することによって、トリガー・ジョブのインスタンスを新規作成できます。
- Oracle Identity System Administrationにログインします。
- 左ペインの「システム構成」で、「スケジューラ」をクリックします。
- 左ペインの「アクション」メニューから、「作成」を選択しますあるいは、「表示」リストの横のプラス(+)記号が付いたアイコンをクリックします。
- 「ジョブの作成」パネルで「タスク」フィールドを、その右側にあるアイコンをクリックして展開します。
- 検索フィールドに
「Certification Event Trigger Task」と入力して、検索を実行します。 - 検索結果で「Certification Event Trigger Task」行をクリックし、「確認」をクリックします。
- このトリガー・ジョブのインスタンスに対し、ジョブ名を入力し、スケジュール設定の詳細を記録したければそれも入力します。
- 「Event Listener Name List」フィールドに、このトリガー・ジョブのインスタンスで処理するリスナー名のリストを、カンマで区切って入力します。
トリガー・ジョブのいずれのインスタンスでも、独自のスケジュールを設定することも、手動で実行することもできます。また、指定されたリスナー・サブセットに対するトリガーの操作に制限することもできます。このため、別の間隔で別のイベント・リスナーをトリガーできます。
13.10 証明レポートの構成
証明レポートは、PDF形式、RTF形式、HTML形式、Microsoft Excel形式およびCSV形式で生成できます。
ダッシュボードの「詳細情報」セクションにある「レポート」タブの表示を構成するには:
- Oracle Identity System Administrationにログインします。
- 「コンプライアンス」タブをクリックします。
- 「アイデンティティの証明」ボックスをクリックして、「証明構成」を選択します。「証明構成」ページが表示されます。
- 「証明レポートの有効化」オプションを選択します。
- 「保存」をクリックします。
レポートは、次の形式で生成できます。
-
PDF
-
RTF
-
HTML
-
Microsoft Excel
-
CSV
13.11 ユーザー証明における複数フェーズ・レビューの理解
2フェーズ・レビューと拡張委任(TPAD)は、ユーザー証明に対してのみサポートされます。これには、複数フェーズによるレビュー、各フェーズ内での複数レビューアへの委任およびTPADでの証明のステージが含まれます。
この項では、次の各項で拡張委任を使用した2フェーズ・レビューについて説明します。
13.11.1 拡張委任を使用した2フェーズ・レビューの機能について
TPADは、ビジネス指向のレビューアとテクニカル・レビューアの観点を組み合せて、証明者が別のレビューアに意思決定を委任できるようにします。
共同証明またはTPADには、次の機能があります。
-
2フェーズ・レビュー: 1つの証明の中で、ビジネス指向のレビューアとテクニカル・レビューアのパースペクティブを組み合せることができるようにします。
-
拡張委任: 証明者が、決定を他の人間に委任しながら、全体的な責任を保持できるようにします。個別の明細項目が1つの証明の中で拡張委任されることによって、レビューアは、同時に作業できる何人かの人たちの間で作業を分散できます。これにより、社内でのアクセスのレビューに責任を負う人たちは、負担を分散できるために、作業をより迅速に完了できます。
ノート:
Oracle Identity Managerは、ユーザー証明に対してのみ、TPADをサポートします。TPADは、ロール証明、アプリケーション・インスタンス証明および権限証明に対してはサポートされません。
13.11.2 複数フェーズによるレビュー
複数フェーズによるレビューでは、同じセットのユーザーアクセス権限に対する複数のパースペクティブを組み合せます。
ユーザー証明の場合は、フェーズは次のようになります。
-
ビジネス・レビュー: これは、レビューの第1フェーズで必須です。ビジネス・レビューアは通常、各ユーザーのマネージャであり、ユーザーの証明可能なアクセス権限がすべて、このレビューアの画面に表示されます。最初にマネージャは、そのユーザーが、従業員など、その会社内で有効な権限保持者であることを確認します。次にマネージャは、会社内でのユーザーの地位から考えて、ロール割当て、アカウント割当て、権限割当てなど、ユーザーのアクセス権限が妥当であることを確認します。ビジネス・レビューアは、適切と思われる権限があれば証明または承認し、不要または不適切と思われる権限があれば失効させます。
-
テクニカル・レビュー: これは、レビューの第2フェーズで省略可能です。テクニカル・レビューアは通常、各権限の所有者または認可者であり、権限のメンバーをレビューするか、または特定のユーザーへのその権限の割当て、または特定のユーザーの特定のアカウントへのその権限の割当てをレビューします。テクニカル・レビューアは、適切と思われる権限があれば証明または承認し、不要または不適切と思われる権限があれば失効させます。
-
最終レビュー: これは、レビューの最終フェーズで省略可能です。最終レビューができるように証明が構成されている場合は、第1フェーズからの主要なレビューア(たとえば、各ユーザーのマネージャ)は、最初の2つのフェーズでレビューアが行った決定を見ることができ、必要に応じてそれらの決定を無効にすることができます。
関連項目:
プライマリ・レビューア、テクニカル・レビューア、最終レビューアおよび委任レビューアの詳細は、「アイデンティティの証明を完了させる関係者」を参照してください。
13.11.3 各フェーズ内での複数のレビューアへの委任
フェーズ1またはフェーズ2のプライマリ・レビューアは、職責を再割当てして、明細項目を委任および委任解除できます。
フェーズ1またはフェーズ2での主要なレビューアは、次のようにして、作業を他のユーザーに分散できます。
-
主要なレビューアは、任意のセットの明細項目に対する責任を、別のユーザーに再割当てすることができます。再割当てでは責任が別の人間に委譲され、委任では責任が主要なレビューアに保持されます。フェーズ1で明細項目を再割当てすると、新しい証明が作成されます。
-
主要なレビューアは、各明細項目、または任意のセットの明細項目を、主要なレビューアが選択した任意のユーザーに委任できます。このユーザーを、委任されたレビューアと呼びます。明細項目を委任すると、主要なレビューアのタスクではその明細項目が委任済とマークされ、その明細項目に対して主要なレビューアは操作をできなくなります。
-
主要なレビューアは、証明タスクをサインオフする前であれば、フェーズ内でいつでも、委任された明細項目の委任を解除できます。明細項目の委任を解除すると、その明細項目は委任されたレビューアのタスクから削除され、たとえば、証明決定を行ったり、明細項目の委任または再割当てを行ったりして、その明細項目を操作できるようになります。
フェーズ1またはフェーズ2では、主要なレビューアが明細項目を委任し、少なくとも1つの明細項目が委任されたままでサインオフすると、つまり、主要なレビューアがサインオフする前にそれらの明細項目の一部で委任を解除していない場合は必ず、Oracle Identity Managerによってフェーズ1検証またはフェーズ2検証のレビュー・タスクが生成され、このタスクが主要なレビューアに割り当てられます。このタスクにより、主要なレビューアは、委任されたレビューアがそのフェーズでなんらかの決定を行っていた場合に、その決定を確認したり無効にしたりすることができます。
13.11.4 TPADでの証明のステージ
TPADでの証明のステージは、検証のフェーズ1、検証のフェーズ2および最終レビューです。
TPADでの証明ステージは、次の各項で説明します。
13.11.4.1 TPADでの証明のステージについて
図13-2は、必須のフェーズ1、省略可能なフェーズ2、およびフェーズ2に依存する省略可能な最終レビュー・フェーズを、条件付きの検証タスクと組み合せることによって、TPADでの証明のステージを示しています。
図13-2に示すように、TPAD証明内でのステージの全体的な流れは次のとおりです。
-
開始: 証明が作成され、「証明作成タスク」スケジュール済ジョブを実行することによって証明タスクが生成されます。
-
フェーズ1レビュー: これは常に必須です。
-
フェーズ1検証: これは、フェーズ1が委任を使用して完了された場合にのみ発生します。
-
フェーズ2レビュー: これは、構成に応じて省略可能です。
-
フェーズ2検証: これは、フェーズ2が委任を使用して完了された場合にのみ発生します。
-
最終レビュー: これは、構成に応じて省略可能であり、フェーズ2が完了された場合にのみ発生します。
-
終了: 証明タスクが完了されました。証明完了の一環として任意のアクセスが失効された場合は、クローズド・ループ是正が発生します。
13.11.4.2 検証を使用したフェーズ1
図13-3は、TPADを使用した証明レビューの第1フェーズを示しています。
次に示すのは、TPADでの検証を使用したフェーズ1のプロセス・フローです。
-
開始: 一連の証明オブジェクトが生成され、レビュー・プロセスが開始します。特定の各証明オブジェクト内の明細項目はいずれも、フェーズ1の主要なレビューア(P1PR)に割り当てられています。
-
タスクP1PR: 証明生成のためのスケジュール済ジョブが実行されると、Oracle Identity Managerではサービス指向アーキテクチャ(SOA)を使用して、証明オブジェクトごとにタスクを作成し、そのタスクが、フェーズ1の主要なレビューア(P1PR)に割り当てられます。
主要なレビューアがそのタスクを開くと、その主要なレビューアは、証明オブジェクト内の明細項目をすべて見ることができます。主要なレビューアが任意の特定の明細項目を開いた場合は、その主要なレビューアは、その明細項目の明細項目詳細をすべて見ることができます。
主要なレビューアは、そのタスク内で、いずれの明細項目でも操作できます。主要なレビューアは、任意の明細項目を別の人間に委任するか、または任意の明細項目を別の人間に再割当てすることができます。デフォルトでは、主要なレビューアは、あらゆる明細項目を所有しており、その明細項目詳細に対し、その証明や失効などの決定を下すことができます。
各明細項目に対して決定が下された後、明細項目の各詳細にフェーズ1決定が下された後、あるいは各詳細が委任されるか、または再割当てされた後で、主要なレビューアは、タスクをサインオフするか、または完了することができます。
-
P1PRによる項目の再割当て: フェーズ1で主要なレビューアが任意のセットの明細項目を別の人間に再割当てした場合は、Oracle Identity Managerによって、それらの再割当てされた明細項目(およびその詳細)が元の証明から削除され、新規の独立した証明に入れられます。明細項目が再割当てされた人間は、その新規の独立した証明に対するP1PRとなります。
再割当てされた明細項目は元のP1PRのタスクに表示されなくなり、このレビュー・サイクル内にも再表示されなくなります。新しいP1PRが元のP1PRに明細項目を再割当てするか、または委任しても、元のP1PRにタスクが新規作成され、次のように、別のレビュー・プロセスの一環となります。
-
新しいP1PRが元のP1PRに明細項目を再割当てした場合は、独自のP1PRタスクを備えた新規証明となります。
-
新しいP1PRが元のP1PRに明細項目を委任した場合は、新規P1PRのレビュー・プロセス内で新規に委任されたレビュー(P1DR)・タスクとなります。
-
-
P1PRによる項目の委任: 主要なレビューアが任意のセットの明細項目を別の人間に委任した場合は、その人間が、それらの明細項目のそれぞれに対するフェーズ1の委任されたレビューア(P1DR)となります。タスクが新規作成され、新しいP1DRに割り当てられます。
ノート:
タスクの数を最小にするには、特定のレビューアに委任しようとする明細項目セットを選択することをお薦めします。そうしないと、委任されたレビューアは、タスクをいくつでも受け取ってしまう可能性があり、それらのタスクのそれぞれには、同じ証明オブジェクトの同じフェーズにある明細項目のいくつかのサブセットが含まれます。
主要なレビューアが特定の明細項目セットを委任すると、それらの明細項目には、主要なレビューアが委任したタスク内で委任済とマークされます。主要なレビューアは、それらの明細項目に対しては、委任を解除しないかぎり、そのタスク内で操作できなくなります。主要なレビューアには、フェーズ1検証中に、委任された任意のレビューアが行った決定を見て無効にするチャンスがあります。
-
P1PRによる項目の委任解除: 主要なレビューアは、委任されている明細があれば、その委任を解除するか、または委任されているレビューアから取り返すことができます。明細項目の委任を解除すると、主要なレビューアはその明細項目を操作でき、現在委任されているレビューアのタスクからその明細項目が削除されます。これによって、委任されていたレビューアはその明細項目をもう操作できなくなります。
-
P1PRによるサインオフ: すべての明細項目が完了された後、あるいは委任されるか、または再割当てされた後で、主要なレビューアは、そのタスクに対してサインオフしてタスクを完了することができます。明細項目は、その詳細すべてに、現在のフェーズで決定が設定されると完了します。この時点では、Oracle Identity Managerによって、フェーズ1検証(P1V)が必須かどうかが判別されます。
-
SOAによる割当て先に対するプロキシのアクティブ/非アクティブ化(P1PR): P1PRなど、割り当てられたレビューアにプロキシを割り当てることができます。たとえば、レビューアが休暇を取る予定になっている場合、そのレビューアはプロキシをアクティブ化できます。レビューアが休暇から戻ると、そのプロキシは非アクティブ化されます。新たに割り当てられた(プロキシ)レビューアがタスクを開くと、プロキシ・レビューアは、各明細項目および明細項目詳細を表示して操作できます。プロキシの追加、変更および削除の詳細は、「プロキシの管理」を参照してください。
-
SOAによるタスクのエスカレート(P1PR): 証明タスクは、Oracle Identity Managerが証明レビュー・タスクに使用するSOAコンポジットの構成に応じてエスカレートされる場合があります。たとえば、レビューアが、構成された時間制限内にタスクをサインオフしていないか、または完了していない場合は、SOAによってタスクがエスカレートされ、現在割り当てられているレビューアのマネージャに再割当てされる可能性があります。タスクが最大回数までエスカレートされるか、またはエスカレーションを終了する他の状況に到達した後で、タスクの有効期限が切れます。
-
SOAによるタスクの有効期限切れ(P1PR): 証明レビュー・タスクは、ある状況で期限切れとなる場合があります。たとえば、レビューアが、構成された時間制限内にタスクをサインオフしていない場合は、タスクが有効期限切れとなる可能性があります。タスクが、有効期限が到来するまでエスカレートするように構成されている場合は、SOAによってタスクが有効期限切れとなるのは、最大回数までエスカレートされるか、またはエスカレーションを終了する他の状況に到達した後に限られます。有効期限の切れたタスクは操作できなくなります。
-
タスク: P1DR: 委任されたレビュー・タスクそれぞれには、委任されたレビューアに主要なレビューアが委任した明細項目セットが含まれています。委任されたレビューアがそのタスクを開くと、委任されたレビューアが見ることができるのは、そのタスクを生成した特定の委任イベントで委任された明細項目のみです。フェーズ1の委任されたレビューア(P1DR)が任意の特定の明細項目を開いた場合は、P1DRはその明細項目のすべての詳細を見ることができます。
委任されたレビューアは、そのタスク内で、いずれの明細項目でも操作できます。委任されたレビューアは、任意の明細項目を別の人間に委任することも、任意の明細項目の委任を解除することも、任意の明細項目を別の人間に再割当てすることもできません。デフォルトでは、委任されたレビューアは、あらゆる明細項目を所有しており、その明細項目詳細に対し、証明や失効などの決定を下すことができます。すべての明細項目に対して決定が下された後、または明細項目のすべての詳細にフェーズ1決定が下された後で、委任されたレビューアは、タスクをサインオフするか、または完了することができます。
-
P1DRによるサインオフ: 委任されたレビュー・タスク内のすべての明細項目に決定が下された後で、委任されたレビューアは、タスクをサインオフするか、または完了することができます。委任されたレビュー・タスクはいずれも、証明レビュー・プロセスがフェーズ1検証に進むことのできる前に完了するか、または有効期限切れとなる必要があります。
-
いずれの明細項目にもP1DRがある: この分岐点では、フェーズ1検証ステージが必須かどうかが判別されます。これは、委任されている明細項目があるかどうかによります。
-
P1PRがサインオフしたときに、再割当てされていない明細項目が委任されたままの場合は、レビュー・プロセスがフェーズ1検証に移行します。
-
P1PRがサインオフしたときに、再割当てされていない明細項目が委任されたままになっていない場合は、レビュー・プロセスがフェーズ2に移行します。
-
-
P1DRのタスクがすべてサインオフされたか、または有効期限切れとなった: フェーズ1で委任されたすべてのレビュー・タスクがサインオフ(完了)されるか、または有効期限切れとなるまで、この分岐はループします。
-
タスク: P1V: 主要なレビューア(P1PR)がサインオフし、委任されたすべてのレビュー・タスク(P1DR)が完了するか、または有効期限切れとなったら、フェーズ1検証が開始します。同じ証明オブジェクトの別のタスクが作成され、主要なレビューアに割り当てられます。このタスク内では、主要なレビューアは、フェーズ1でなんらかの決定を行っていた場合に、その決定を確認したり無効にしたりすることができます。委任されたレビューアが完了していない明細項目があれば、主要なレビューアはそれも完了できます。主要なレビューアは、このタスク内で、明細項目の再割当ても委任もできないため、委任の解除もできません。
-
P1PRによるサインオフ(P1V): 別の主要なレビューアに再割当てされていないすべての明細項目について、証明オブジェクト内のすべての明細項目詳細に決定が下された後で、フェーズ1の主要なレビューアがサインオフできます。レビューアがフェーズ1検証タスクでサインオフすると、証明レビュー・プロセスはフェーズ2に進みます。
-
SOAにより、(P1PRタスクと同様に)割当て先に対してプロキシがアクティブ化され、P1Vタスクがエスカレートまたは有効期限切れになる可能性があります。詳細は、ステップ7から9を参照してください。
13.11.4.3 検証を使用したフェーズ2
フェーズ2は、フェーズ1の省略可能な複数の循環バージョンです。
省略可能: フェーズ2は省略可能です。というのは、フェーズ2が発生するのは、構成でフェーズ2が有効になっている場合、フェーズ2の主要なレビューアを選択するように管理者が戦略を指定した場合、および、指定された戦略がフェーズ2の主要なレビューアを、証明内の少なくとも1つの明細項目に割り当てた場合に限られるためです。
複数: フェーズ2の主要なレビューアは複数ある場合があります。というのは、それぞれのレビューアが管理または認可するのは、明細項目でなく明細項目詳細であるためです。たとえば、ユーザー証明では、ロール割当て、アカウント割当て、権限割当てのそれぞれに、別々の主要なレビューアを指定できます。
循環: フェーズ2の各レビューアは、循環ビューを見ることができます。たとえば、ユーザー証明のフェーズ1では、ビジネス・レビューアはユーザーを明細項目として、また各ユーザーのアクセス権限を明細項目詳細として見ることができます。ユーザー証明のフェーズ2では、テクニカル・レビューアは、ロール定義、アプリケーション・インスタンス定義、権限定義などの権限定義を明細項目として、また各権限メンバーを明細項目詳細として見ることができます。この権限中心のビューは、テクニカル・レビューアにとって、より有用です。テクニカル・ビューアは、個別の権限定義に対する責任を委任するか、または再割当てできます。
図13-4は、TPADを使用した証明レビューの第2フェーズを示しています。
フェーズ2のステージはフェーズ1と似ていますが、次の点が異なります。
-
タスク: P2PR: フェーズ2の主要なレビューア(P2PR)それぞれが、その証明内の割当てをレビューする必要がある各タイプの権限に対して、レビュー・タスクが生成されます。フェーズ2の主要なレビューアがP2PRのタスクを開くと、その主要なレビューアは、証明オブジェクト内で自分が責任を負う明細項目のリストを見ることができます。たとえば、ユーザー証明のフェーズ2では、P2PRのタスクを開くテクニカル・レビューアは、ロール定義、アプリケーション・インスタンス定義、権限定義などの権限のリストを見ることができます。それらの権限は、その主要なレビューアが証明者であり、その証明オブジェクトに割当てが含まれています。このタイプの証明はユーザー中心であり、循環ビューは権限中心です。
主要なレビューアが任意の特定の明細項目を開いた場合は、その主要なレビューアは、その明細項目の明細項目詳細をすべて見ることができます。主要なレビューアは、そのタスク内で、いずれの明細項目でも操作できます。主要なレビューアは、任意の明細項目を別の人間に委任するか、または任意の明細項目を別の人間に再割当てすることができます。デフォルトでは、主要なレビューアは、あらゆる明細項目を所有しており、その明細項目詳細に対し、その証明や失効などの決定を下すことができます。
-
P2PRによる項目の再割当て: フェーズ2で主要なレビューアが任意のセットの明細項目を別の人間に再割当てした場合は、その人間が、それらの明細項目に対する新規の主要なレビューア(P2PR)となります。Oracle Identity Managerによって主要なレビュー・タスクが新規作成され、新しいP2PRに割り当てられます。
ノート:
フェーズ2での再割当て操作では、証明は新規生成されません。たとえば、主要なテクニカル・レビューアが(循環される)明細項目を再割当てした場合は、証明は分割されません。
再割当てされた明細項目は、元のP2PRのタスクに表示されなくなります。明細項目は、新しいP2PRに割り当てられている別個のタスク内に表示されます。
13.11.4.4 最終レビュー
最終レビューは省略可能であり、最後に決着をつけるものです。これは、TPADにおいて最も単純なフェーズです。
省略可能: 最終レビューが発生するのは、構成で最終レビューが有効になっている場合、証明の定義において最終レビューが実行されるように管理者が指定した場合、および、少なくとも1つの明細項目にフェーズ2の主要なレビューアが割り当てられているためにフェーズ2が実行された場合に限られます。
最後に決着をつけるもの: フェーズ2のレビューアは、フェーズ1のレビューアと異なる決定を下した可能性があるため、フェーズ1の主要なレビューアは、それまでの2つのフェーズで下された決定を表示して無効にすることができます。したがって、最終レビューは最後に決着をつけるものです。
最も単純なフェーズ: 最終レビューアは1人のみであり、それがフェーズ1の主要なレビューアです。最終レビューアは、委任も再割当てもできません。最終レビューアは、フェーズ1で下された決定、およびフェーズ2で下された決定を確認し、それらの決定を無効にすることができます。
図13-5は、TPADを使用した証明レビューの省略可能な最終フェーズを示しています。
最終レビューでは、他のレビュー・フェーズと次のステージが異なります。
-
システムによる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の決定を優先する場合は、構成で最終レビューを有効にしないでください。
13.12 証明のコメントの事前移入について
このコンテンツは、OIGバンドル・パッチ12.2.1.4.211010バンドル・パッチ以降のリリースにのみ適用されます。
証明定義の場合、「認証操作に対する事前移入コメント」構成プロパティを選択すると、キャンペーンのコメントがマイニングされ、使用可能な場合は、キャンペーンの詳細ページの各明細項目に対してUIに事前移入されます。
各明細項目のコメントには、キャンペーンの実行時に、次の順序で最初に使用可能なものが移入されます:
- 明細項目の最終完了証明からの空でないコメント
- 明細項目の理由のリクエストからのコメント
- アクセス・ポリシーにより付与されたアカウント/権限については、関連するロール・リクエストの理由
事前移入されたコメントの詳細は、次のフローチャートを参照してください:
図13-6 証明のコメント
ノート:
キャンペーンに最新のコメントを移入するには、証明定義の実行を開始する前に、証明のコメントのマイニング・ジョブを実行します。このジョブの詳細は、事前定義済のスケジュール済タスクに関する項を参照してください。13.13 証明のUIの新機能について
このコンテンツは、OIGバンドル・パッチ12.2.1.4.211010バンドル・パッチ以降のリリースにのみ適用されます。
-
このリリースでは、構成プロパティの次の値に基づいてUIエクスペリエンスが拡張されます:
- 証明操作に対するコメントを許可
- 認証操作に対する必須コメント
- 証明以外のすべての操作に対するコメントを許可
- 認証以外のすべての操作に対する必須コメント
次の表に、完全な詳細を示します:構成プロパティ値 UI動作 - 認証操作に許可されるコメント => False
- この場合、1つ以上の行を選択して「認証」をクリックすると、コメントを入力するためのダイアログ・ボックスは表示されません。
- コメントが存在する場合は、nullに変更されます。
- 認証操作に許可されるコメント => True
- 認証操作に対する必須コメント => False
- この場合、1つ以上の行を選択して「認証」をクリックしても、コメントを入力するためのダイアログ・ボックスは表示されません。
- 行は、各行に対する既存のコメントを使用して認証されます。
- 行のコメントを追加/変更するには、認証アクションを実行する前に、行を選択し、「コメントの編集」を使用します。
- 認証操作に許可されるコメント => True
- 認証操作に対する必須コメント => True
- 単一行が選択された場合: 行のコメントが存在しない場合は、コメントを設定するダイアログ・ボックスが表示されます。コメントが存在する場合は、ダイアログ・ボックスは表示されず、既存のコメントを使用して認証されます。
- 複数の行が選択され、すべての行にコメントが存在する場合: ダイアログ・ボックスは表示されず、既存のコメントを使用して行が認証されます。
- 複数の行が選択され、1つ以上の行にコメントが存在しない場合: ダイアログ・ボックスに「コメント」とチェック・ボックス「コメントが存在しない場合に使用」が表示されます。選択したすべての行に指定されたコメントを使用する場合は、このチェック・ボックスをオフにします。
このチェック・ボックスを選択すると、新しいコメントはコメントのない行にのみ使用されます。他の行は既存のコメントで認証されます。
- すべて選択する場合: 既存のコメントを使用して、ページ全体のすべての行を認証します。いずれかの行にコメントがない場合、エラーが表示され、他の行が認証されます。
- 認証以外のアクションで許可されるコメント => FALSE
- この場合、1つ以上の行を選択して「失効」をクリックしても、ダイアログ・ボックスは表示されません。
- また、コメントが存在する場合は、nullに更新されます。
- 認証以外の操作に許可されるコメント => True
- 認証以外の操作に対する必須コメント => False/True
- この場合、「失効」をクリックすると、コメントを入力するためのダイアログ・ボックスが表示されます。これは常に表示されます。コメントを入力する必要があります(コメントは、認証以外の操作に対する必須コメント・プロパティがTRUEに設定されている場合に必要になります)
- この場合、行に対する既存のコメントは使用されません。
13.14 証明の監視について
証明の監視とは、特定の主要なレビュー・タスクの範囲内で、プライマリ・レビューアの決定をレビューする(場合によっては取り消す)アクティビティのことです。
特定の主要なレビュー・タスクの範囲内でプライマリ・レビューアの証明の決定を取り消すことができる人物を監督者と呼びます。監督者には次の特徴があります。
-
監督者は、Oracle Identity Managerユーザーである必要があります。
-
主要なレビュー・タスクを同時に監視できる監督者は1人のみです。
-
監督者には、プライマリ・レビューアまたは前任の監督者による決定を表示および取消しする権限があります。
証明構成の一部として、証明の監視ワークフローを定義する証明コンポジットを選択できます。証明コンポジットとは、証明のフェーズ中に、プライマリ・レビューアまたは委任されたレビューアごとに証明サーバーを起動するSOAワークフローのことです。
CertificationOverseerProcessコンポジットで定義されているデフォルトの動作は、次のとおりです。
-
主要なレビュー・タスクは、プライマリ・レビューアとシーケンス内のすべての監督者がサインオフするまで完了しません。
-
監督者のシーケンスで最後の監督者がサインオフした決定は、その主要なレビュー・タスクの最終決定になります。
-
クローズド・ループ型の是正は、全体的な証明が完了した後で開始されます。すべての主要なレビュー・タスクが完了するまでは、証明のどのフェーズも完了しません。
-
証明のフェーズ2と最終レビュー・フェーズの場合:
-
フェーズ2には複数のプライマリ・レビューアが存在することがあるため、主要なレビュー・タスクごとに個別の監督者のシーケンス(プライマリ・レビューアごとに1つの主要なレビュー・タスク)が存在することがあります。複数フェーズ・レビューの詳細は、「ユーザー証明における複数フェーズ・レビューの理解」を参照してください。
-
-
委任の場合、プライマリ・レビューアの検証タスクに対してのみ監視が実施されます。主要なレビュー・タスク中にプライマリ・レビューアが委任すると、その主要なレビュー・タスクは監視されません。そのかわりに、そのフェーズの決定をすべて含む、後続の検証タスク中に監視が実施されます。
-
証明のフェーズ1の間に明細項目の再割当てがあると、新しい証明が作成され、再割当て先に割り当てられる新しい主要なレビュー・タスクが作成されます。ここで、新しい主要なレビュー・タスクに対する監視者の新しいシーケンスが計算されます。
デフォルトの監視機能を拡張すると、様々なレベルの監視を指定したり、特定のステージに達したときに監視プロセスを停止したりできます。これを行うには、カスタムの証明コンポジットを作成して、デプロイする必要があります。カスタム証明コンポジットの作成およびデプロイの詳細は、『Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』の証明の監督のカスタマイズに関する項を参照してください。