1. Oracle Identity Governanceの管理
  2. ポリシー管理
  3. ワークフローの管理

4 ワークフローの管理

ワークフローの管理には、ワークフロー・ルールの理解と構成、アップグレードされたデプロイメントでのリクエスト商品の管理、テストから本番へのワークフロー・ポリシーの移行、ワークフローなしでのOracle Identity Managerの実行が含まれます。

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

4.1 ワークフロー・ルールの理解

ワークフロー・ルール、リクエスト・プロセス・フロー(ワークフローがある場合とない場合)、およびリクエスト・ライフサイクル(1つのリクエストとバルク・リクエスト)について理解します。

この項では、承認ワークフローについて説明します。内容は次のとおりです。

4.1.1 ワークフロー・ルールについて

リクエストの生成と承認は、ワークフロー・ルールの使用と構成によって異なります。

リクエストの生成および承認は次によって制御されます。

  • Oracle Identity Managerがワークフローを使用して実行されているかどうか。Oracle Identity Managerではワークフローはデフォルトで有効になっています。ワークフローなしでのOracle Identity Managerの実行の詳細は、「ワークフローなしでのOracle Identity Governanceの実行」を参照してください。

  • サポートされている操作に対して定義された承認ワークフロー・ルール。

ノート:

ワークフロー・ポリシーの導入で、承認ポリシーは非推奨となっています。このマニュアルで説明するように、リクエストの生成および承認はワークフロー・ポリシーによって管理されます。

以前のリリースからOracle Identity Managerをアップグレードした場合、承認ポリシーは引き続き動作します。

ただし、既存の承認ポリシーはすべてワークフロー・ポリシーに移行することをお薦めします。

ワークフロー・ルールにより、次が決定されます。

  • 操作の承認が必要かどうか

  • 特定の操作に対してどのワークフローを起動する必要があるか

4.1.2 リクエスト・プロセス・フローについて

リクエストのプロセス・フローは、操作が許可されるかどうか、単独の操作かバルク操作か、デプロイメントにワーフクローが含まれるかどうかによって異なります。

図4-1に、承認ワークフロー・ルールによって制御されるリクエストの生成および承認のプロセスを示します。

図4-1 リクエスト・プロセス・フロー

図4-1の説明が続きます
「図4-1 リクエスト・プロセス・フロー」の説明

リクエスト・プロセス・フローは次のようになります。

  1. ユーザーに付与されている管理ロールに基づいて認可チェックが実行されます。このチェックにより、操作の実行がユーザーに許可されるかどうかが決まります。

  2. 操作が認可されない場合、エラーが返され、フローは終了します。

  3. 操作が許可されると、バルク操作または先日付操作であるかがチェックされます。

  4. バルク操作または先日付操作である場合、リクエストが作成され、ワークフロー・ルール評価に基づいて承認が開始され、承認後に操作は終了します。

  5. バルク操作または先日付操作でない場合、承認ワークフロー・ルールが評価されます。この評価の結果により、リクエストが作成されるかどうかが決まります。

    • 結果が直接である場合、リクエストは作成されず、操作は直接実行されます。

    • SOAワークフローIDが結果として返される場合、リクエストが作成され、ポリシー評価によって返されたワークフローが起動されます。

バルク・リクエストは次の方法で処理されます。

  • バルク・リクエストが許可された結果として、リクエストが常に作成されます。

  • バルク・リクエスト用として構成されている承認ワークフロー・ルールが表示されます。

    ルール評価の結果としてワークフローIDが生成される場合、バルク・リクエストが作成され、対応するSOAワークフローが開始されます。

    ルール評価の結果としてワークフローIDが生成されない場合、バルク・リクエストが作成されて自動承認されます。

  • バルク・リクエストが承認(自動承認またはSOAワークフロー承認)された後、子リクエストが作成されます。

  • 子リクエストは承認ワークフロー・ルール評価(非バルク)を受け、その結果に基づいて処理されます。

4.1.3 リクエスト・ライフサイクルについて

各リクエストは、システムで作成された後、特定のライフサイクルを通過します。ライフサイクルによって、リクエストは様々なステージに遷移します。リクエストが存在するステージによって、コントローラがそのステップで実行するアクション、リクエストに対してその時点で使用可能な操作、および遷移が可能なステージが決定します。

リクエスト・ライフサイクルについては、次に示す項で説明します。

4.1.3.1 様々なリクエストのステージ

表4-1に、ライフサイクルの様々なステージでのリクエストの機能、およびリクエストのこれらのステージへの到達方法を示します。

表4-1 リクエストのステージ

リクエストのステージ 説明

リクエストの下書きが作成されました

「カート詳細」ページの「下書きとして保存」ボタンをクリックすることによってリクエストを下書きとして保存すると、リクエストは「リクエストの下書きが作成されました」ステージに移動します。

リクエスタは、リクエストを将来の変更、送信または削除用に保存できます。これは、リクエスタがリクエストの送信前に追加情報を待っている場合に役に立ちます。下書きリクエストの取消しまたはクローズはできません。

ノート: 下書きモードで保存されたリクエスト・データにはパスワードなどの機密情報を含めないでください。それらがリクエストを下書きとして保存する前に入力したものであっても同様です。

リクエストが作成されました

正常に送信されたリクエストは、「リクエストが作成されました」ステージに移動します。

情報の指定

これは、権限リクエストのリクエスタに割り当てられたタスク(受信ボックスからアクセス可能)で、権限のプロビジョニングが必要なアカウントを検索し、選択するためのタスクです。

承認待ちのリクエスト

作成されたリクエストに承認が定義されている場合は、リクエストは「承認待ちのリクエスト」ステージに自動的に移動します。このステージでは、対応する承認がリクエスト・サービスを介して開始されます。

このステージでリクエストが取り消されるかクローズされた場合、リクエスト・エンジンはワークフロー・インスタンスごとにワークフローの取消しをコールします。タスクの取消しに関する通知が承認者に送信されます。

これらのステータスを正常に完了したリクエストは、リクエスト承認済ステージに到達します。

リクエストが正常に作成された後にSoD検証チェックがプラグインされる場合、リクエストは次のステータスに関連付けられます。

  • SoDチェックが開始されていません

    リクエストに基づいたリソースのプロビジョニングに対してSoD検証が開始されない場合、リクエストはこのステージに到達します。リクエスト・エンジンは、リクエストの送信後かつ承認の取得前に、リクエストをこのステージに移動します。

  • SoDチェックが開始されました

    リクエストに基づいたリソースのプロビジョニングに対してSoD検証が非同期で開始された場合、リクエストはこのステージに到達します。リクエスト・エンジンは、リクエストの送信後かつ承認の取得前に、リクエストをこのステージに移動します。

  • SoDチェックが完了しました

    リクエストに基づいたリソースのプロビジョニングに対してSoD検証が完了した場合、リクエストはこのステージに到達します。リクエスト・エンジンは、リクエストの送信後かつ承認の取得前に、リクエストをこのステージに移動します。

ノート: これらのSoDリクエスト・ステータスが可能なのは、リクエストが次のリクエスト・タイプのいずれかである場合です。

  • ApplicationInstanceのプロビジョニング

  • アカウントの変更

  • 権限のプロビジョニング

  • 権限の失効

  • ロールの割当て

  • ロールからの削除

リクエストが承認されました

リクエストは、承認された場合のみ、次のステージに移動し、現在のステータスで更新されます。結果は「承認済」、「却下」または「保留」です。

リクエストが自動承認されました

リクエストは、承認された場合のみ、次のステージに移動し、現在のステータスで更新されます。

否認されたリクエスト

ワークフロー・インスタンスが更新されるたびに、リクエスト・サービスは、リクエスト・エンジンをそのインスタンスの現在のステータスで更新します。リクエスト・エンジンが想定しているリクエスト・サービスからの結果は、「承認」または「却下」です。インスタンス化されたワークフロー・インスタンスが却下された場合、リクエスト・エンジンはリクエストを「却下」ステージに移動します。任意のワークフロー・インスタンスが却下された場合、コントローラはすべての保留中のワークフローを取り消して、リクエストを「却下」ステージに移動します。

操作が開始されました

リクエストが承認されると、リクエスト・エンジンはリクエストを「操作が開始されました」ステージに移動して、操作を開始します。

次のリクエスト・ステータスがこのステージに関連付けられています。

  • 操作が完了しました

    実際のリクエスト操作が完了すると、リクエスト・エンジンはリクエストを「操作が完了しました」ステージに移動します。これは、「操作が開始されました」ステータスの後に発生し、「完了」ステージに関連付けられます。

  • ポスト操作処理が開始されました

    実際のリクエスト操作が完了した後、実行する必要がある追加操作が後処理として存在する場合、リクエスト・エンジンは、その操作を開始する前に、リクエストを「ポスト操作処理が開始されました」ステージに移動します。これが実行されるのは、「操作が完了しました」ステータスの後です。

ノート: バルク操作の場合、子リクエストはリクエスト・レベルの承認の後に作成され、親リクエストは「リクエストが子リクエストの完了待ちです」ステータスに移動します。

リクエストに失敗しました

リクエストに指定されている関連操作の実行に失敗した場合、リクエストは保留中の操作を取り消して「リクエストに失敗しました」ステージに移動します。

次のリクエスト・ステータスがこのステージに関連付けられています。

  • リクエストに失敗しました

    リクエストで指定されたすべての関連付けられた操作が失敗すると、リクエストは、「リクエストに失敗しました」ステージに移動します。

  • リクエストの一部が失敗しました

    リクエストで指定された一部の関連付けられた操作が失敗すると、リクエストは、「リクエストの一部が失敗しました」ステージに移動します。

リクエストが取り下げられました

リクエスタはリクエストを取り消すことができます。このステージでは、リクエストが「リクエストが取り消されました」ステータスに関連付けられ、すべての承認の開始が取り消されます。

ノート:

  • リクエストを取り消すことができるのは、「操作が開始されました」ステージの前です。「操作が開始されました」ステージに到達したリクエストの取消しはできません。

  • 下書きモードで保存したリクエストの取消しはできません。

  • リクエストは、Identity Self Serviceを使用して実行されるリクエスタによってのみ、いつでも取り消すことができます。

  • 管理者は、リクエストをクローズできます。この操作は取消機能と似ています。

リクエストがクローズされました

リクエストは、リクエスタによってクローズできます。このステージでは、リクエストが「リクエストがクローズされました」ステータスに関連付けられ、すべての承認の開始が取り消されます。

ノート:

  • 下書きモードで保存したリクエストのクローズはできません。

  • 管理者は、リクエストをクローズできます。この操作は取消機能と似ています。

リクエストが完了しました

リクエストに指定されたすべての操作の実行が完了すると、リクエスト・エンジンはリクエストを「リクエストが完了しました」ステージに移動します。

次のリクエスト・ステータスがこのステージに関連付けられています。

  • リクエストがエラーで完了しました

    実際のリクエスト操作が正常に実行されても後処理操作のいずれかの実行に失敗した場合、リクエストはこのステータスに到達します。「リクエストがエラーで完了しました」ステージは「失敗」ステージに関連付けられています。

  • リクエストが完了しました

    実際のリクエスト操作がエラーなしに正常に実行された場合、リクエストはこのステータスに到達します。

  • リクエストが完了待ちです

    リクエストが将来の日付で実行するようにスケジュールされている場合、リクエストは「リクエストが完了待ちです」ステータスに到達し、操作が有効日に完了するまで待機します。

ステージに正常に到達すると、リクエストのステータスも対応するステータスに更新されます。

操作は、手動で実行するか、イベントに対応してシステムで自動的に実行できます。手動操作の例を次に示します。

  • リクエストの下書きとしての保存。

  • 下書きリクエストの編集/更新。

  • リクエストの送信

  • リクエストのクローズ/取消し。

  • 承認ワークフローが正常に承認されたことがサービスに通知されたときのリクエストの承認。

自動操作の例を次に示します。

  • リクエストが送信されたときの承認の開始。

  • リクエストが承認され、かつ実行日が将来の日付かまたは指定されていない場合のリクエストの実行。

4.1.3.2 1つのリクエスト・ライフサイクル

1つのリクエストまたは非バルク・リクエストは、単一レベルの承認を受けます。承認ワークフローが起動されると、図4-2に示すように、リクエストは「承認待ちのリクエスト」ステージに移動し、承認後に「リクエストが承認されました」ステージに移動します。

図4-2 1つのリクエスト・ライフサイクル

図4-2の説明が続きます
「図4-2 1つのリクエスト・ライフサイクル」の説明
4.1.3.3 バルク・リクエスト・ライフサイクル

バルク・リクエストまたは親リクエストのライフサイクルは、バルク・リクエストが「リクエストが承認されました」ステージに移行するまでは、1つのリクエストまたは非バルク・リクエストと同じです。この後、図4-3に示すように、子リクエストに分割されてから、「操作が開始されました」ステージの「リクエストが子リクエストの完了待ちです」ステータスに移動します。

図4-3 バルク・リクエスト・ライフサイクル

図4-3の説明が続きます
「図4-3 バルク・リクエスト・ライフサイクル」の説明

各子リクエストは、「1つのリクエスト・ライフサイクル」で説明しているライフサイクルを通過します。子リクエストが完了すると、バルク・リクエストまたは親リクエストは「リクエストが完了しました」ステージに移動します。

4.2 承認ワークフロー・ルールの構成

承認ワークフロー・ルールを構成するには、ワークフロー・ルール、ルール条件、システム定義の操作とルールを理解し、承認ワークフロー・ルールを作成し、カスタム・ルール条件を構成し、承認ワークフロー・ルールを変更し、承認ワークフロー・ルールを削除し、承認ワークフロー・ルール評価を理解します。

この項では、承認ワークフロー・ルールの構成について説明します。内容は次のとおりです。

4.2.1 承認ワークフロー・ルールについて

承認ワークフロー・ルールを構成することにより、操作に承認が必要かどうかを決定できます。また、承認が必要な場合、このルールにより、どのSOAワークフローを開始するかも示します。

操作および対応するワークフロー・ルールのリストは、Oracle Identity Managerに事前定義されています。これらのシステム定義のルールにより、承認が必要かどうか、および開始するSOAワークフローが決まります。すべての非バルク操作には、事前定義済の承認ワークフロー・ルールが構成されています。

サポートされている操作および対応するルールのリストは、「システム定義の操作およびルールについて」を参照してください。

ノート:

Oracle Identity Managerでは、新しい操作および対応するルールを作成することはできません。ただし、既存の操作のルールを作成および変更することはできます。

承認ワークフロー・ルールは、サポートされているすべての操作に対して定義できます。これらは、次のとおりです。

  • ユーザーの自己登録

  • ユーザーの作成

  • ユーザーの変更

  • ユーザーの無効化

  • ユーザーの有効化

  • ユーザーの削除

  • ロールの作成

  • ロールの変更

  • ロールの削除

  • ロールの割当て

  • ロールからの削除

  • ロール付与を変更

  • ApplicationInstanceのプロビジョニング

  • アカウントの変更

  • アカウントの無効化

  • アカウントの有効化

  • アカウントの失効

  • 権限のプロビジョニング

  • 権限の変更

  • 権限の失効

  • 異種リクエスト

  • ユーザー・プロファイルの一括変更

  • ユーザーの一括無効化

  • ユーザーの一括有効化

  • ユーザーの一括削除

  • ロールの一括削除

  • ロールの一括割当て

  • ロールからの一括削除

  • ApplicationInstanceの一括プロビジョニング

  • アカウントの一括無効化

  • アカウントの一括有効化

  • アカウントの一括失効

  • 権限の一括プロビジョニング

  • 権限の一括失効

4.2.2 ルールの条件について

承認ワークフロー・ルールは、次に示すルールの条件と結果で構成されています。

承認ワークフロー・ルールは、次で構成されています。

  • 条件: 操作レベルで定義されている許容入力に基づくルール条件

  • 結果: 操作に対して開始するSOAワークフローIDであるワークフローID

「ユーザーの変更」操作の承認ワークフロー・ルールの例を次に示します。

ルールの条件:

requester.adminroles CONTAINS OrclOIMUserAdmin

ルールの結果:

Direct

ここでは、ルール条件により、リクエスタが受益者の組織内のユーザー管理者管理ロールのメンバーであるかどうかをチェックしています。条件が満たされる場合、承認ワークフローを開始せずに操作が実行されます。

ルール条件は操作ごとに異なります。たとえば、「ユーザーの作成」操作にはリクエスタ・データとともにユーザー・データが必要であり、「ロールの割当て」操作にはリクエスタ・データとともにロール情報およびユーザー・データが必要です。リクエスタ・データはすべての操作に必要です。Oracle Identity System Administrationでは、選択した操作に基づいて必要なロール条件を入力できます。

各承認ワークフローには複数のルールを関連付けることができますが、これらは一定の順序で定義する必要があります。たとえば、「ユーザーの作成」承認ワークフローには、契約者の作成、サプライヤの作成および「パートナの作成」などのルールを順番に定義できます。承認ワークフロー内のルールが評価される順序は、これらのルールがポリシー内に定義されている順序によって決まります。

各操作のルール条件の例は、「カスタム・ルール条件について」を参照してください。

4.2.3 システム定義の操作およびルールについて

各操作/ワークフロー・ポリシーにはデフォルトのルールがあり、その結果はDIRECTです。これは、操作に対するデフォルトのルール条件がtrueと評価された場合、承認なしで直接に操作することを意味します。

表4-2に、システム定義の操作と、結果がDIRECTとなる対応するワークフロー・ルールの一覧を示します。

ノート:

表4-2内のルールは下位互換性の維持のみを目的としています。これらは削除し、独自のルールを作成する必要があります。

表4-2 操作およびルール

操作 ルール名 ルール条件

ロールの割当て

Assign Roles Default Rule

requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ロールの作成

Create Role Default Rule

requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ユーザーの作成

Create User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ロールの削除

Delete Role Default Rule

requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ユーザーの削除

Delete User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

アカウントの無効化

Disable Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ユーザーの無効化

Disable User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

アカウントの有効化

Enable Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ユーザーの有効化

Enable User Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

アカウントの変更

Modify Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

権限の変更

Modify Entitlement Default Rule

requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ロールの変更

Modify Role Default Rule

requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ユーザー・プロファイルの変更

Modify User Profile Default Rule

requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ApplicationInstanceのプロビジョニング

Provision ApplicationInstance Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

権限のプロビジョニング

Provision Entitlement Default Rule

requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ロールからの削除

Remove from Roles Default Rule

requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

アカウントの失効

Revoke Account Default Rule

requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

権限の失効

Revoke Entitlement Default Rule

requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

ロール付与を変更

Modify Role Grant Default Rule

requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

さらに、表4-3に示すように、コンプライアンスのユースケースをサポートする他のいくつかのシステム定義のルールがあり、これには、ロール・ライフサイクル、アイデンティティ監査および証明が含まれます。

表4-3 コンプライアンス・ユースケースのルール

操作 ルール名 ルール条件 ルール結果

ロールの割当て

Assign Roles IdentityAuditorEnabled Rule

identityAuditEnabled EQUAL TRUE

ワークフロー

default/DefaultOperationalApproval!5.0

ロールの作成

Create Role IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

ワークフロー

default/RoleLCMApproval!1.0

ロールの削除

Delete Role IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

ワークフロー

default/RoleLCMApproval!1.0

ユーザーの無効化

Disable User Certification Rule

request.isCertification Equal true

ワークフロー

default/DefaultRequestApproval!6.0

ロールの変更

Modify Role IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

ワークフロー

default/RoleLCMApproval!1.0

ロールからの削除

Remove from Roles IdentityAuditorEnabled Rule

identityAuditEnabled Equal TRUE

ワークフロー

default/DefaultOperationalApproval!5.0

ロールからの削除

Remove from Roles Certification Rule

request.isCertification Equal TRUE

ワークフロー

default/DefaultRequestApproval!6.0

アカウントの失効

Revoke Account Certification Rule

request.isCertification Equal TRUE

ワークフロー

default/DefaultRequestApproval!6.0

権限の失効

Revoke Entitlement Certification Rule

request.isCertification Equal TRUE

ワークフロー

default/DefaultRequestApproval!6.0

ロール付与を変更

Modify Role Grant IdentityAuditorEnabled Rule

identityAuditEnabled EQUAL TRUE

ワークフロー

default/DefaultOperationalApproval!5.0

関連項目:

request.isCertificationおよびidentityAuditorEnabled条件の詳細は、表4-4。

ノート:

表4-3に示されたワークフロー・ルールは、表4-2に示されたデフォルト・ルールより先に(順序に関して)構成されます。したがって、これらのルールは、デフォルト・ルールの前に評価されます。ワークフロー・ルールの評価の詳細は、「承認ワークフロー・ルール評価について」を参照してください。

たとえば、ロールの割当て操作には、2つのルールが次の順序でデフォルトで構成されています。

  1. Assign Roles IdentityAuditorEnabled Rule

  2. Assign Roles Default Rule

ロールの割当て操作のために開始する承認ワークフローを決定するには、Assign Roles IdentityAuditorEnabled Ruleルールが最初に評価されます。ルールが一致しない(trueになる)場合、Assign Roles Default Ruleが評価されます。

4.2.4 承認ワークフロー・ルールの作成

承認ワークフロー・ルールを構成することにより、操作に承認が必要かどうかを決定できます。また、承認が必要な場合、このルールにより、どのSOAワークフローを開始するかも示します。

承認ワークフロー・ルールを作成するには:

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

  2. 左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。「ワークフロー構成の承認」ページが表示されます。

  3. 「ルールを構成する操作を選択します」セクションで、ルールを構成する操作を選択します。操作に関連付けられたルールがページ下部の「ルール」セクションに表示されます。このセクションには、操作に関連付けられたルール名、ルールの説明およびワークフローが表示されます。

    「ルール」セクションでは、新しいルールを作成したり、既存のルールを選択して更新または削除できます。

    ノート:

    承認ワークフロー・ポリシーに複数のルール条件が指定されている場合、ルールが評価される順序は、これらのルールがポリシー内で構成されている順序に基づいて決まります。この順序は、ルールの作成後は変更できません。したがって、これらのルールは、評価する順序で作成する必要があります。

  4. 「ルール」セクションの「作成」をクリックします。ルールの作成ページが表示されます。

  5. 「名前」ボックスに、ルールの名前を入力します。これは必須フィールドです。

  6. 「説明」ボックスに、ルールの説明を入力します。

  7. 「所有者」ボックスに、ルールの所有者を指定します。これを行うには、「所有者」フィールドの横の検索アイコンをクリックしてから、所有者を検索して選択します。

  8. 「ステータス」リストから、ルールのステータスを選択します。デフォルトでは、ルールは「有効」ステータスです。

  9. 「条件ビルダー」セクションで、IFおよびTHEN句でルール条件を指定します。これを行うには、次のステップを実行し、ユーザーが最上位組織のメンバーである場合は「ユーザーの作成」操作が自動承認される、サンプルのルール条件を作成します。

    1. IF句の下にある空の行の先頭フィールドで、オブジェクトおよび属性を指定するには、フィールドの横の検索アイコンをクリックします。「条件ビルダー」ダイアログ・ボックスが表示されます。

      ノート:

      オブジェクトおよび属性の正確な名前がわかっている場合は、検索アイコンをクリックするかわりに、先頭フィールドに条件(requester.Organization Nameなど)を入力できます。

    2. リクエスタ・データに基づいて条件を指定するため、「リクエスタ」をクリックします。リクエスタ・オブジェクトに対して指定可能な属性のリストが表示されます。ページ番号アイコンをクリックして選択すると、属性間を移動できます。それ以外の場合、検索フィールドに属性名を入力し、検索アイコンをクリックします。

      ノート:

      「条件ビルダー」ダイアログ・ボックス内の任意の画面で「開始」をクリックすると、先頭の画面に戻り、オブジェクトを選択して新しい条件の指定を開始できます。

    3. 「組織名」属性をクリックします。「条件ビルダー」ダイアログ・ボックスに条件requester.Organization Nameが表示されます。

    4. 「OK」をクリックします。IF句の先頭フィールドに条件が追加されます。

    5. 「演算子」リストから「次と等しい」を選択します。

      選択できる演算子は、次のとおりです。

      • EQUAL

      • NOT_EQUAL

      • CONTAINS

      • DOES_NOT_CONTAIN

      • BEGINS_WITH

      • DOES_NOT_BEGIN_WITH

      • ENDS_WITH

      • DOES_NOT_END_WITH

    6. 右側のフィールドで値を指定するには、検索アイコンをクリックします。「条件ビルダー」ダイアログ・ボックスが表示されます。

      ノート:

      正確な値がわかっている場合は、検索アイコンをクリックするかわりに、値(Topなど)を入力できます。

    7. 次のオプションのいずれかを選択します。

      • 値: 属性の値を指定します。

      • 式: 式に基づいて条件を指定します。

      この例の目的に従い、「値」オプションを選択します。「組織名」属性の値がリストされます。これは、ルールに指定されているオブジェクトおよび属性がrequester.Organization Nameであるためです。

    8. 「Top」をクリックします。Top組織が選択されます。

    9. 「OK」をクリックします。値フィールドにTop組織が移入されます。

    10. 別の条件を追加するには、「条件の追加」をクリックします。IF句の下に別の行が追加されます。右側の演算子リストから、「AND」または「OR」演算子を選択し、ステップaからiで説明しているように別のルール条件を入力できます。

      行を削除するには、行の左側のチェック・ボックスを選択し、「削除」をクリックします。

    11. 複数のルール条件を追加した場合、条件をグループ化できます。これを行うには、条件の左側のチェック・ボックスを選択し、「グループ」をクリックします。同様に、条件のグループを削除するには、条件の左側のチェック・ボックスを選択し、「グループ解除」をクリックします。

      ノート:

      • 一度にグループ化できる条件は2つのみです。3つ以上の条件を選択する場合、「グループ」ボタンは無効になっています。また、「グループ解除」ボタンが有効になるのは、グループ化されている条件の1つを選択する場合のみです。ただし、複数のグループを選択すると、このボタンは無効になります。

      • 最大2つの条件をグループ化できます。したがって、AND演算子を使用してグループ化された4つの条件を持つルールを作成する場合、条件は2セットでグループ化されます。しかし、条件の1つがOR演算子を使用してグループ化されている場合、ルールは正しく更新されます。

    12. THEN句で、先頭フィールドの横の検索アイコンをクリックし、「条件ビルダー」ダイアログ・ボックスを開きます。

    13. 「workflow」を選択し、「OK」をクリックします。

    14. ワークフローの値フィールドで、「AutoApproval!1.0」を選択します。このワークフローを選択すると、リクエストは自動承認されます。

    15. 「OK」をクリックします。値フィールドにワークフロー値が移入されます。

      したがって、指定したルール条件は次のようになります。

      IF
requester.Organization Name EQUALS Top

THEN
workflow default/AutoApproval!1.0

  10. 「作成」をクリックし、ルール条件を作成します。ルール条件を作成した操作を選択すると、そのルール条件が表内に表示されます。

    ノート:

    • 「リスク」属性を使用してルールの条件を定義する場合、ルールを正しく評価するために、リクエストが行われる前にリスク集計ジョブというスケジュール済ジョブを実行する必要があります。

    • アプリケーション・インスタンスの場合、属性をフィルタ処理して除外するメカニズムがありません。アプリケーション・インスタンスのすべての属性がルールを書き込むことができる条件ビルダーに表示されます。ロールでは、ロール名を選択すると、ロール・エンティティの属性リストが表示されます。属性リストの表示には、アスタリスク(*)ワイルドカード文字を選択できます。

各ワークフロー操作のルール条件の例は、「カスタム・ルール条件について」を参照してください。

ノート:

このリリースでは、ワークフロー・ルールの作成時に、「ロール」ではなく「ユーザー・タイプ」を使用します。たとえば、次のルール条件では、user.User Typeがuser.Roleのかわりに使用されます。
IF user.User Type=Contractor
THEN capability=selfModifyUser

4.2.5 カスタム・ルール条件について

カスタム・ルール条件の構文は、操作と、それに対応する条件の最上位属性で構成されます。

表4-4に、カスタム・ルール条件の指定方法と例を示します。

表4-4 承認ワークフロー・ルールの構文と例

操作 条件の最上位属性 ワークフロー・ルール条件の作成(最上位属性に基づく)

バルクを含むすべての操作

operation

これは、現在実行されている操作を示します。たとえば:

operation EQUALS Create User

ノート: このような条件を使用できるのは、目的の結果が常にtrueである場合です。

バルクを含むが自己登録ユーザーを除くすべての操作

requester

これは、すべてのリクエスタのユーザー・プロファイル属性、ロールおよび管理ロール・メンバーシップを示します。たとえば:

requester.Email CONTAINS @example.com
requester.adminRoles CONTAINS OrclOIMUserAdmin

この条件は、リクエスタの電子メールIDにexample.comが含まれるかどうか、およびリクエスタがOrclOIMUserAdmin管理ロールのメンバーであるかどうかを意味します。

ユーザーの作成

user

これは、ユーザーの作成時にリクエスタが指定できるすべてのユーザー・エンティティ属性を示します。たとえば:

user.Last Name EQUALS Doe

ユーザーの変更

user

これは、ユーザーの変更時にリクエスタが指定できる、変更中のユーザーのすべてのユーザー・エンティティ属性を示します。たとえば:

user.Organization EQUALS Marketing

「ユーザーの無効化」、「ユーザーの有効化」および「ユーザーの削除」

user

これは、ユーザーのプロファイルに現在設定されている、無効化、有効化または削除中のすべてのユーザー属性を示します。たとえば:

existingUser.Organization EQUALS Marketing

「ユーザーの無効化」、「ユーザーの有効化」および「ユーザーの削除」

request

これは、リクエスト・メタデータを示し、唯一許可されるサブ属性はisCertificationです。許容値はtrueとfalseのみであり、これらを手動で入力する必要があります。これを使用して、現在の操作/リクエストが認証リクエストであるかどうかをチェックできます。たとえば: 

request.isCertification EQUAL true

ノート: request.isCertificationはデフォルトのルール内で使用されます。request.isCertificationを使用してカスタム条件を作成することは推奨されません。

ロールの作成

role

これは、ロールの作成時に指定できるすべてのロール・エンティティ属性を示します。たとえば:

role.Name EQUALS ITAdmin

ロールの作成時にはカタログ・メタデータ属性も指定できるため、条件はカタログ・メタデータ属性にも基づいて許可されます。たとえば:

role.catalog.Category EQUAL Role

ロールの作成

identityAuditEnabled

これを使用して、OIG.IsIdentityAuditorEnabledシステム・プロパティの値に基づいて条件を作成できます。許容値はTRUEとFALSEのみであり、これらを手動で入力する必要があります。たとえば: 

identityAuditEnabled EQUALS TRUE

ノート: identityAuditEnabledはデフォルトのルール内で使用されます。identityAuditEnabledを使用してカスタム条件を作成することは推奨されません。

ロールの変更

role

これは、ロールの変更時に指定できるすべてのロール・エンティティ属性を示します。たとえば:

role.Name EQUAL ITAdmin

ロールの変更時にはカタログ・メタデータ属性も指定できるため、条件はカタログ・メタデータ属性にも基づいて許可されます。たとえば:

role.catalog.Category EQUAL Role

ロールの変更

existingRole

これは、変更対象のロールに対して現在設定されているすべてのロール・エンティティ属性を示します。たとえば:

existingRole.DisplayName EQUALS IT Administrator

ロールの変更時にはカタログ・メタデータ属性も指定できるため、条件はカタログ・メタデータ属性にも基づいて許可されます。たとえば:

role.catalog.Category EQUAL Role

ロールの変更

identityAuditEnabled

これを使用して、OIG.IsIdentityAuditorEnabledシステム・プロパティの値に基づいて条件を作成できます。許容値はTRUEとFALSEのみであり、これらを手動で入力する必要があります。たとえば: 

identityAuditEnabled EQUALS TRUE

ノート: identityAuditEnabledはデフォルトのルール内で使用されます。identityAuditEnabledを使用してカスタム条件を作成することは推奨されません。

ロールの削除

existingRole

これは、削除対象のロールに対して現在設定されているすべてのロール・エンティティ属性を示します。たとえば:

existingRole.DisplayName EQUALS IT Administrator

ロールの削除

identityAuditEnabled

これを使用して、OIG.IsIdentityAuditorEnabledシステム・プロパティの値に基づいて条件を作成できます。許容値はTRUEとFALSEのみであり、これらを手動で入力する必要があります。たとえば: 

identityAuditEnabled EQUALS TRUE

ノート: identityAuditEnabledはデフォルトのルール内で使用されます。identityAuditEnabledを使用してカスタム条件を作成することは推奨されません。

「ロールの割当て」、「ロールからの削除」

user

これは、ロールの割当て対象かロール・メンバーシップの失効対象であるユーザー/受益者のプロファイルに現在設定されているすべてのユーザー属性を示します。たとえば:

user.Organization EQUALS Marketing

「ロールの割当て」、「ロールからの削除」

role

これは、割当て対象かユーザーからの失効対象であるロールのすべての属性を示します。たとえば:

role.name EQUAL IT Administrator

「ロールの割当て」、「ロールからの削除」

catalogItem

これは、アクセス・リクエストの送信対象であるロールに対応するカタログ・メタデータ属性を示します。たとえば:

catalogItem.Category EQUAL Role

「ロールの割当て」、「ロールからの削除」

identityAuditEnabled

これを使用して、OIG.IsIdentityAuditorEnabledシステム・プロパティの値に基づいて条件を作成できます。許容値はTRUEとFALSEのみであり、これらを手動で入力する必要があります。たとえば:

identityAuditEnabled EQUALS TRUE

ノート: identityAuditEnabledはデフォルトのルール内で使用されます。identityAuditEnabledを使用してカスタム条件を作成することは推奨されません。

「ロールの割当て」、「ロールからの削除」

request

これは、リクエスト・メタデータを示し、唯一許可されるサブ属性はisCertificationです。許容値はtrueとfalseのみであり、これらを手動で入力する必要があります。これを使用して、現在の操作/リクエストが認証リクエストであるかどうかをチェックできます。たとえば: 

request.isCertification EQUAL true

ノート: request.isCertificationはデフォルトのルール内で使用されます。request.isCertificationを使用してカスタム条件を作成することは推奨されません。

ロール付与を変更

user

これは、ロール・メンバーシップの変更対象であるユーザー/受益者のプロファイルに現在設定されているユーザー属性を示します。たとえば:

user.Organization EQUALS Marketing

ロール付与を変更

role

これは、メンバーシップの変更対象であるロールの属性を示します。たとえば:

role.name EQUALS IT Administrator

ロール付与を変更

catalogItem

これは、アクセス・リクエストの送信対象であるロールに対応するカタログ・メタデータ属性を示します。たとえば:

catalogItem.Category EQUAL Role

ロール付与を変更

identityAuditEnabled

これを使用して、OIG.IsIdentityAuditorEnabledシステム・プロパティの値に基づいて条件を作成できます。許容値はTRUEとFALSEのみであり、これらを手動で入力する必要があります。たとえば: 

identityAuditEnabled EQUALS TRUE

ノート: identityAuditEnabledはデフォルトのルール内で使用されます。identityAuditEnabledを使用してカスタム条件を作成することは推奨されません。

ApplicationInstanceのプロビジョニング

user

これは、アカウントのプロビジョニング対象であるユーザー/受益者のユーザー・プロファイル属性を示します。たとえば:

user.Organization EQUALS Marketing

ApplicationInstanceのプロビジョニング

appType

これは、ユーザー/受益者へのプロビジョニング対象であるアカウントを示します。

appTypeは最上位属性で、appInstanceなどのサブ属性の階層になる場合があり、この後ろにはaccountが続いたり、場合によってはその後ろにアカウント固有の子表または権限が続くことがあります。また、accountの後ろに親フォーム属性が続いたり、子表または権限の後ろに特定の属性が続くこともあります。

例1:

appType[AD User].appInstance[VisionEmployeesDomain].account[*].Organization Name EQUAL Marketing

この条件は、Marketing組織内のVisionEmployeesDomain appInstanceでアカウントが作成対象であるかどうかを意味します。

ノート: ワークフロー・ルール評価では、リクエスト対象であるアカウントのみが考慮され、ユーザー/受益者が所有している可能性がある既存のアカウントは考慮されません。

例2:

appType[AD User].appInstance[*].account[*].Organization Name EQUAL Marketing

この条件は、Marketing組織内のAD Userターゲットに関連するappInstanceでアカウントが作成対象であるかどうかを意味します。

ApplicationInstanceのプロビジョニング

catalogItem

これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します(catalogItemなど)。

アカウントの変更

user

これは、アカウントの変更対象であるユーザー/受益者のユーザー・プロファイル属性を示します。たとえば:

user.Organization EQUALS Marketing

アカウントの変更

appType

これは、この操作の一環として変更対象であるアカウント情報を示します。たとえば:

existingAppType[AD User].appInstance[*].account[*].Organization Name EQUAL Manufacturing

これは、AD Userターゲットのユーザー・アカウントがManufacturing組織への転送対象であるかどうかを意味します。

アカウントの変更

existingAppType

これは、この操作の一環として変更対象である現在または既存のユーザー・アカウント情報を示します。たとえば:

appType[AD User].appInstance[*].account[*].Organization Name EQUAL Marketing

これは、AD Userターゲットのユーザー・アカウントがMarketing組織から他の組織への転送対象であるかどうかを意味します。

ノート: ワークフロー・ルール評価では、変更対象であるアカウントのみが考慮され、ユーザー/受益者が所有している可能性がある既存のアカウントは考慮されません。

アカウントの変更

catalogItem

これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します。たとえば:

catalogItem.Category EQUALS Role

「アカウントの有効化」、「アカウントの無効化」、「アカウントの失効」

user

これは、アカウントの有効化/無効化/失効対象であるユーザー/受益者のユーザー・プロファイル属性を示します。たとえば:

user.Organization EQUALS Marketing

「アカウントの有効化」、「アカウントの無効化」、「アカウントの失効」

existingAppType

これは、この操作の一環として有効化/無効化/失効対象である現在または既存のユーザー・アカウント情報を示します。たとえば:

existingAppType[AD User].appInstance[*].account[*].Organization Name EQUAL Marketing

この条件は、有効化/無効化/失効対象であるユーザー・アカウントがAD UserターゲットのMarketing組織に属するかどうかを意味します。

ノート: ワークフロー・ルール評価では、有効化/無効化/失効対象であるアカウントのみが考慮され、ユーザー/受益者が所有している可能性がある既存のアカウントは考慮されません。

「アカウントの有効化」、「アカウントの無効化」、「アカウントの失効」

catalogItem

これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します(catalogItemなど)。

「アカウントの有効化」、「アカウントの無効化」、「アカウントの失効」

request

これは、リクエスト・メタデータを示し、唯一許可されるサブ属性はisCertificationです。許容値はtrueとfalseのみであり、これらを手動で入力する必要があります。これを使用して、現在の操作/リクエストが認証リクエストであるかどうかをチェックできます。たとえば: 

request.isCertification EQUAL true

ノート: request.isCertificationはデフォルトのルール内で使用されます。request.isCertificationを使用してカスタム条件を作成することは推奨されません。

権限のプロビジョニング

user

これは、権限のプロビジョニング対象であるユーザー/受益者のユーザー・プロファイル属性を示します。たとえば:

user.Organization EQUALS Marketing

権限のプロビジョニング

appType

これは、操作の実行時に指定対象である権限情報またはデータを示します。たとえば:

appType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

この条件は、PasswordPolicyAdminGrp権限がVisionEmployeesDomain アプリケーション・インスタンスのユーザー/受益者への付与対象であるかどうかを意味します。

権限のプロビジョニング

catalogItem

これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します(catalogItemなど)。

権限の変更

user

これは、権限付与の変更対象であるユーザー/受益者のユーザー・プロファイル属性を示します。たとえば:

user.Organization EQUALS Marketing

権限の変更

appType

これは、操作の実行時に指定対象である権限情報またはデータを示します。たとえば:

appType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

この条件は、VisionEmployeesDomainアプリケーション・インスタンスのユーザー/受益者に対するPasswordPolicyAdminGrp権限付与が変更対象であるかどうかを意味します。

権限の変更

existingAppType

これは、権限情報または既存の権限フォーム・データ(開始日や終了日など)を示します。たとえば:

existingAppType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

この条件は、VisionEmployeesDomainアプリケーション・インスタンスのユーザー/受益者に対するPasswordPolicyAdminGrp権限付与が変更対象であるかどうかを意味します。

権限の変更

catalogItem

これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します(catalogItemなど)。

権限の失効

user

権限付与の失効対象であるユーザー/受益者のユーザー・プロファイル属性。たとえば:

user.Organization EQUALS Marketing

権限の失効

existingAppType

これは、権限情報または既存の権限フォーム・データ(開始日や終了日など)を示します。たとえば:

existingAppType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp

この条件は、VisionEmployeesDomainアプリケーション・インスタンスのユーザー/受益者に対するPasswordPolicyAdminGrp権限付与が変更対象であるかどうかを意味します。

権限の失効

catalogItem

これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します(catalogItemなど)。

権限の失効

request

これは、リクエスト・メタデータを示し、唯一許可されるサブ属性はisCertificationです。許容値はtrueとfalseのみであり、これらを手動で入力する必要があります。これを使用して、現在の操作/リクエストが認証リクエストであるかどうかをチェックできます。たとえば: 

request.isCertification EQUAL true

ノート: request.isCertificationはデフォルトのルール内で使用されます。request.isCertificationを使用してカスタム条件を作成することは推奨されません。

4.2.6 承認ワークフロー・ルールの変更

ワークフロー・ルールを変更することにより、ルール条件を追加、変更または削除できます。

「承認ワークフロー・ルールの作成」で追加したワークフロー・ルールを変更するには:

  1. Identity System Administrationの左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。「ワークフロー構成の承認」ページが表示されます。

  2. 「操作」セクションで、ルールを構成する操作を選択します。

  3. 「ルール」セクションで、「編集」をクリックします。ルールの編集ページが表示されます。

  4. 「操作」セクションで、ワークフロー・ルールを変更する操作を検索して選択します。この例の目的に従い、「ユーザーの作成」を選択します。「ユーザーの作成」操作のルールが「ルール」セクション内の表に表示されます。

  5. 「ルール」セクションで、編集するルールを選択し、「編集」をクリックします。ルールの編集ページが表示されます。

  6. ルール属性を変更する場合は、「ルールの編集」セクションで属性値を更新します。

  7. 「条件ビルダー」セクションで、オブジェクト、属性または値フィールドを変更することによって既存のルールを変更できます。また、既存の条件に条件を追加することも、ルール条件を削除することもできます。次のステップを実行し、リクエスタがUserHelpDesk管理ロールを持つ場合は「ユーザーの作成」操作にターゲット・ユーザー・マネージャの承認が必要であることを指定するルール条件を追加します。

    1. 「条件ビルダー」セクションで、「条件の追加」をクリックします。新しい行が追加されます。

    2. 右側の演算子リストから「OR」を選択します。

    3. 行の先頭フィールドで、「条件ビルダー」ダイアログ・ボックスを使用してrequester.adminRoleを指定します。「条件ビルダー」ダイアログ・ボックスでの値の選択の詳細は、「承認ワークフロー・ルールの作成」のステップ10を参照してください。

    4. 演算子リストから「CONTAINS」を選択します。

    5. 値フィールドで、「条件ビルダー」ダイアログ・ボックスを使用してOrclOIMUserHelpDeskを選択します。

    6. THENセクションの2つ各フィールドでworkflowおよびdefault/BeneficiaryManagerApproval!4.0を指定します。このため、完全なルール条件は次のようになります。

      IF
requester.adminRoles CONTAINS OrclOIMUserHelpDesk

THEN
workflow default/BeneficiaryManagerApproval!4.0

      このルール条件により、リクエスタがUserHelpDesk管理ロールを持つ場合はユーザーを作成するためにターゲット・ユーザー・マネージャの承認が必要になります。

  8. 「更新」をクリックします。ワークフロー・ルールは新しいルール条件を使用して更新されます。

  9. ルール条件を削除するには、ルール条件の左側のチェック・ボックスを選択し、「削除」をクリックします。次に、「更新」をクリックします。

4.2.7 承認ワークフロー・ルールの削除

すべての操作に対して定義したワークフロー・ルールを削除できます。ただし、デフォルトのルールは削除しないことをお薦めします。

ワークフロー・ルールを削除するには:

  1. Identity System Administrationの左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。「ワークフロー構成の承認」ページが表示されます。
  2. 「操作」セクションで、ワークフロー・ルールを削除する操作を選択します。
  3. 「ルール」セクションで、「削除」をクリックします。確認を求めるメッセージ・ボックスが表示されます。
  4. 「はい」をクリックします。

4.2.8 承認ワークフロー・ルール評価について

バルク操作と非バルク操作の承認ワークフロー・ルール評価について理解します。

操作(バルクまたは非バルク)が実行対象である場合、承認ワークフロー・ルール評価は次の方法で実行されます。

  1. 実行対象の操作に関連付けられた承認ワークフロー・ルールが構成時の順序で1つずつ評価されます。

  2. ルール評価が停止し、一致したルールの結果(ワークフローIDまたは直接)が戻されます。

    承認ワークフロー・ルールは最初に一致したルール(trueに評価されたルール)で停止し、このルールの結果が結果として戻されます。

  3. バルク操作の場合、一致するルールがない場合は、SOAConfigのdefaultRequestApprovalCompositeに構成されているSOAコンポジットが暗黙的に戻されます。

  4. 非バルク操作の場合、一致するルールがない場合は、SOAConfigのdefaultRequestApprovalCompositeに構成されているSOAコンポジットが暗黙的に戻されます。

承認ワークフロー・ルールによってワークフローID (UserManagerApprovalなど)が戻される場合、リクエストが作成され、対応するASYNC編成が開始されます。編成の一環として、ユーザーによって送信されたデータの一部が変更または追加される可能性があります。この結果、UserManagerApproval以外のワークフローIDが適用可能になる可能性があります。このようなシナリオを処理するために、ワークフローが開始される前に承認ワークフロー・ルールが再評価されます。再評価の結果として別のワークフローID (HRManagerApproval)が適用される場合、HRManagerApprovalが開始されます。

4.3 アップグレードされたOracle Identity Governanceデプロイメントでのリクエスト承認の管理

アップグレードされたデプロイメントでリクエスト承認を管理するには、アップグレードされたデプロイメントでのリクエスト承認プロセスと、ワークフロー・ルールが無効なリクエスト・プロセス・フローを理解し、承認ポリシーを移行し、ワークフロー・ルールを有効にします。

この項では、アップグレードされたOracle Identity Governanceデプロイメントでのリクエスト承認の管理について説明します。内容は次のとおりです。

4.3.1 アップグレードされたOracle Identity Governanceデプロイメントでのリクエスト承認について

アップグレードされたOracle Identity Managerデプロイメントのデフォルトでは、承認ワークフロー・ルール機能は無効です。

このため、操作が開始されると、次のようになります。

  • Oracle Identity Managerユーザーズ・ガイドのリクエストと直接操作に関する項で説明しているように、承認ポリシーおよび管理ロール割当てにより、操作に承認が必要かどうかが決まります。

  • 承認ポリシーは機能であり、承認が必要な場合にどのSOAワークフローを起動するかを決定します。

  • 承認には2つのレベルがあり、その機能はOracle Identity Managerユーザーズ・ガイド for 11gリリース2 (11.1.2.2)のリクエストの管理に関する項で説明されているとおりです。

  • ワークフロー・ポリシーを有効にすると、Oracle Identity Managerのフレッシュ・デプロイメントの場合と同じ方法でリクエストの生成と承認が行われます。ただし、「承認ポリシーから承認ワークフロー・ルールへの移行」で説明しているように、ワークフロー・ポリシーに承認ポリシーを移行する必要があります。

    ノート:

    ワークフロー・ポリシーは有効にしたら、再度無効にしないでください。ワークフローの有効化と無効化の切り替えはサポートされていません。

承認ポリシー機能のほとんどは、承認ワークフローを使用して実現できます。表4-5に、承認ワークフローを使用して実現できる承認ポリシー機能をリストします。

表4-5 承認ポリシーから承認ワークフローへ

承認ポリシー 承認ワークフロー・ルール

リクエスト・タイプの承認ポリシー

操作に固有の承認ワークフロー・ルール

リクエスト・レベルおよび操作レベルで構成された承認ポリシー・レベル

承認の単一レベル

スコープ・タイプ、スコープ

承認ワークフロー・ルール条件

承認プロセス構成: 自動承認

承認ワークフロー・ルール構成: 直接の選択

承認プロセス構成: 承認プロセス

ワークフロー・ルール構成: ワークフローの検索および選択

承認ポリシー・ルール

承認ワークフロー・ルール条件

異種リクエスト・タイプ

異種リクエスト・ポリシー

バルク・リクエスト・タイプ

操作のバルク・ポリシー(ユーザー・バルクの作成など)

リクエスト・レベルの承認ポリシー

承認ワークフロー・ルール

操作レベルの承認ポリシー

該当なし

優先度

ポリシーが構成されたポリシー順序

階層組織の範囲指定

次のような組織階層に基づくポリシー条件

user.Organization="VisionMarketing" OR user.parentOrganization="Vision" OR ...

4.3.2 承認ワークフロー・ルールが無効なリクエスト・プロセス・フローについて

アップグレードされたOracle Identity Managerデプロイメントのデフォルトでは、承認ワークフローは無効です。

図4-4に、承認ワークフローが無効である場合のリクエスト・プロセスを示します。

図4-4 ワークフロー・ルールが無効なリクエスト・プロセス・フロー

図4-4の説明が続きます
「図4-4 ワークフロー・ルールが無効なリクエスト・プロセス・フロー」の説明

承認ワークフロー・ルール機能が無効である場合、承認ポリシーの結果として戻されるApprovalRequired責任により、操作に承認が必要かどうかが決まります。

ApprovalRequiredがfalseである場合、リクエストは作成されず、直接操作になります。

ApprovalRequiredがtrueである場合、承認ポリシーが評価され、承認ポリシー評価によって戻されたSOAワークフローが開始されます。

4.3.3 承認ポリシーから承認ワークフロー・ルールへの移行

デフォルトでは、1つのワークフロー・ポリシーが1つの操作に使用できますが、操作またはリクエストの1つのタイプに対してリクエスト・レベルまたは操作レベルで複数の承認ポリシーを構成できます。

承認ポリシーから承認ワークフロー・ルールへ移行するには:

  1. 1つのリクエスト・タイプに対して適用可能な承認ポリシーをすべて識別します。リクエスト・レベルと操作レベルに複数のポリシーが存在する場合があるため、これらの優先度または順序を識別するために手動分析が必要です。

    1つの操作またはリクエスト・タイプには、リクエスト・レベルまたは操作レベルで複数の承認ポリシーが構成されている場合があります。これに対して、デフォルトでは、1つの操作に対して適用可能な承認ワークフロー・ポリシーは1つのみです。このデフォルトの承認ワークフロー・ポリシーは削除できませんが、同じものに対して新しいルールを追加することはできます。

  2. 優先度の順序の先頭または2番目にくる承認ポリシーを選択します。

  3. リクエスト・タイプに固有のデフォルトの承認ポリシー構成を開きます。現在の承認ポリシーをバルク・ワークフロー・ポリシー・ルールとして変更する必要がある場合は、デフォルトのバルク・ポリシー(「ユーザーのバルク変更」など)を開きます。

  4. 次のように、現在の承認ポリシーを承認ワークフロー・ルールとしてモデル化します。

    1. ステップ2で選択した承認ポリシー名と同じ名前で新しい承認ワークフロー・ルールを作成します。承認ワークフロー・ルールの説明を入力します。

      関連項目:

      承認ワークフロー・ルールを処理するためのユーザー・インタフェースの詳細は、「承認ワークフロー・ルールの作成」および「承認ワークフロー・ルールの変更」を参照してください

    2. Oracle Identity System Administrationの「ワークフロー構成の承認」ページで、承認ポリシーで承認プロセスとして構成されているワークフローを検索して選択します。

    3. 「ワークフロー構成の承認」ページで承認ポリシー・ルールを承認ワークフロー・ルール条件としてモデル化します。

  5. 1つのリクエスト・タイプに対して適用可能なすべての承認ポリシーに対してステップ2から4を繰り返します。

  6. すべてのリクエスト・タイプに対してステップ1から5を繰り返します。

4.3.4 承認ワークフロー・ルールの有効化

アップグレードされたデプロイメントで承認ワークフロー・ルールを有効化するには、ワークフロー・ルール機能を有効化し、進行中のリクエストのライフサイクルを理解します。

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

4.3.4.1 承認ワークフロー・ルール機能の有効化

アップグレードされたOracle Identity Managerデプロイメントのデフォルトでは、承認ワークフロー・ルール機能は無効です。この機能を有効にするには:

  1. SOAが有効であることを確認します。これを行うには、「ワークフロー有効」システム・プロパティの値がtrueであることを確認します。
  2. 「承認ポリシーから承認ワークフロー・ルールへの移行」で説明しているように承認ポリシーから承認ワークフローへの移行が完了していることを確認します。
  3. 「ワークフロー・ポリシー有効」システム・プロパティの値をtrueに設定します。
  4. Oracle Identity Managerの管理対象サーバーを再起動します。
4.3.4.2 進行中のリクエスト・ライフサイクルについて

Oracle Identity Governanceを19c (19.1.0.0.0)にアップグレードする場合、アップグレード後に処理する必要がある進行中のリクエストがいくつか存在する可能性があります。承認ワークフロー・ポリシー機能が有効になった後、進行中のリクエストすべてのライフサイクルは、ワークフロー決定を除いてOracle Identity Managerの以前のリリースの場合と同じです。開始されるSOAワークフローは、承認ポリシーではなくワークフロー・ポリシーに基づいて決定されます。進行中のリクエストは既存のリクエスト・ステージを経過します。これには、「リクエスト承認を取得しています」、「操作承認を取得しています」、「リクエスト承認が承認されました」、「操作承認が承認されました」、「リクエスト承認が却下されました」および「操作承認が却下されました」の各ステージがあります。

承認ワークフローを有効にした後、進行中のリクエストは次の方法で処理されます。

リクエスト承認待ちの進行中のリクエストの場合

図4-5に、リクエスト承認待ちの進行中のリクエストのライフサイクルを示します。

図4-5 リクエスト承認待ちの進行中のリクエストの場合

図4-5の説明が続きます
「図4-5 リクエスト承認待ちの進行中のリクエストの場合」の説明

リクエストが承認されると、承認ワークフロー・ルールが評価され、操作レベルで開始するSOAワークフローが決定されます。リクエストは「操作承認を取得しています」ステージに移動します。

リクエストが却下されると、リクエストは「リクエスト承認が却下されました」ステージに移動します。

操作承認待ちの進行中のリクエストの場合

図4-6に、操作承認待ちの進行中のリクエストのライフサイクルを示します。

図4-6 操作承認待ちの進行中のリクエストの場合

図4-6の説明が続きます
「図4-6 操作承認待ちの進行中のリクエストの場合」の説明

リクエストが承認されると、操作が開始されます。

リクエストが却下されると、リクエストは「操作承認が却下されました」ステージに移動します。

4.4 テストから本番へのワークフロー・ルールの移行

テスト環境のワークフロー・ルールを本番環境に移行できます。

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

4.4.1 テストから本番へのワークフロー・ルールの移行について

ワークフロー・ルールは、デプロイメント・マネージャを使用してソース環境(テスト環境など)からエクスポートしてターゲット環境(本番環境など)にインポートできます。

ワークフロー・ルールおよびルールから操作/ポリシー関係への移行は、デプロイメント・マネージャ・ウィザードのポリシーのカテゴリに分けられます。デプロイメント・マネージャの詳細は、「デプロイメント・マネージャを使用した増分移行」を参照してください。

ワークフロー・ルールは特定の操作に関連付けられているため、操作を最初に選択してから、エクスポートするルールを選択する必要があります。

ワークフロー・ルールをエクスポート/インポートする場合、ソース環境内のワークフロー・ルール構成によってターゲット環境内のワークフロー・ルール構成がオーバーライドされます。この結果、操作のワークフロー・ルールがインポートされると、この操作に構成されているすべてのルールが削除され、エクスポートしたルールがターゲット環境内のこの操作に関連付けられます。また、ソース環境内のルールの順序はターゲット環境に引き継がれます。

たとえば、ターゲット環境の「ユーザーの作成」操作にはルールRule1およびRule2が構成されているとします。しかし、ソース環境の「ユーザーの作成」操作にはルールRule1およびRule3が構成されており、これらが両方ともエクスポートされるとします。これらのルールがターゲット環境にインポートされると、Rule1およびRule2は削除され、Rule1およびRule3が「ユーザーの作成」操作に関連付けられます。

したがって、ソース/テスト環境をワークフロー・ルール構成の真のソースとして保持することをお薦めします。

4.4.2 デプロイメント・マネージャを使用したテストから本番へのワークフロー・ルールの移動

デプロイメント・マネージャを使用して、操作とポリシーをエクスポートし、それらをターゲット環境にインポートします。

デプロイメント・マネージャを使用してワークフロー・ルールをエクスポート/インポートするには:

  1. ソース/テスト環境のOracle Identity System Administrationにシステム管理者としてログインします。
  2. 左ペインの「システム構成」で、「エクスポート」をクリックします。「構成のエクスポート」ページが開き、「オブジェクトを検索」オプションが表示されます。
  3. オブジェクトの検索ページで「ポリシー」を選択し、「検索」アイコンをクリックします。検索結果が、「使用可能なエンティティ」表に表示されます。
  4. 「使用可能なエンティティ」表で、ワークフロー・ルールをエクスポートするポリシーのチェック・ボックスを選択します。「ポリシー」が「選択されたエンティティ」表に移動されます。
  5. 「次へ」をクリックするか、トレイン・リンクの「エクスポート・オプション」をクリックします。「エクスポート・オプション」ページが表示されます。
  6. 「依存性」を「はい」に設定し、選択した操作についてエクスポートするワークフロー・ルールを選択します。
  7. ウィザードの残りのステップを続行し、エクスポートを完了します。
  8. ターゲット/本番環境のOracle Identity System Administrationにシステム管理者としてログインします。
  9. 左ペインの「システム構成」で、「インポート」をクリックします。
  10. エクスポート(ステップ7)したワークフロー・ルールが含まれるファイルを選択し、インポート・プロセスを完了します。詳細なステップについては、「デプロイメントのインポート」を参照してください

ノート:

ワークフロー・ルール条件は、ロールやアプリケーション・インスタンスなどのエンティティを参照できます。このような依存エンティティはワークフロー・ルール移行の一環として移行できません。このような依存エンティティはターゲット/本番環境で手動で構成または移行する必要があります。それ以外の場合は、ルール評価結果が予測不可能になる可能性があります。

4.5 ワークフローなしでのOracle Identity Governanceの実行

Oracle Identity Managerは、デフォルトでインストールされて有効になっているSOAサーバーに依存します。しかし、インストール後の構成ステップとしてSOAを無効にすることにより、ワークフローを手動で無効にすることができます。

この章では、SOAを無効にする手順と、この手順の実行による機能的な影響について次の各項で説明します。

4.5.1 SOAサーバーの無効化

SOAサーバーを無効にするには、「ワークフロー有効」システム・プロパティの値を設定します。

SOAサーバーを無効にするには:

  1. SOA管理対象サーバーを停止します。
  2. 「ワークフロー有効」システム・プロパティの値をfalseに設定します。このシステム・プロパティの詳細は、表18-1を参照してください。
  3. Oracle Identity Managerの管理対象サーバーを再起動します。

SOAサーバーを再度有効にするには、「ワークフロー有効」システム・プロパティの値をtrueに設定します。

ノート:

SOAは無効にした後に再度有効にしないことをお薦めします。ワークフローの有効化と無効化の切り替えはサポートされていません。

4.5.2 ワークフローの無効化の影響について

ワークフローの無効化による主な機能的な影響は、すべての操作が自動承認されることです。つまり、操作は承認なしで完了します。承認ワークフローが開始されないため、承認ポリシーおよび承認ワークフロー・ルールはどちらも評価されません。

図4-7にワークフローの無効化の影響を示します。

図4-7 ワークフローの無効化

図4-7の説明が続きます
「図4-7 ワークフローの無効化」の説明

また、表4-6に、ワークフローが無効である場合に使用できない機能をリストします。

表4-6 ワークフローの無効時に使用不可能な機能

機能 詳細

リクエスト承認

  • 実行される操作はすべて直接操作であり、リクエストは作成されませんが、次のような例外があります。

    • バルク操作の場合はリクエストが常に作成されます。子リクエストが即時作成され、自動承認されます。

    • 有効日が将来であるすべての操作に対してリクエストが常に作成されます。

    新しく作成されたリクエストはすべて、手動での承認なしに自動承認されます。たとえば、すべての追加アクセス、自己プロファイル変更、およびアカウント/権限変更リクエストは直接操作です。

  • 承認ポリシーまたはワークフロー・ルールは評価されません。ワークフロー・ルールの詳細は、「ルールの条件について」を参照してください。

プロビジョニング操作

  • 接続なしアプリケーション・インスタンス: ワークフローがオフである場合、接続なしアプリケーション・インスタンスの手動処理タスクは機能しません。接続なしアプリケーション・インスタンスのプロビジョニング操作は失敗します。

  • アカウントと権限の依存性: ワークフローがオフである場合、受益者が1人である権限リクエストは、次の方法で機能します。

    • 選択したユーザーが1つのアカウントを持つ場合: アカウントは事前に選択され、影響はありません。

    • 選択したユーザーが複数のアカウントを持つ場合: アカウントを選択する必要があり、影響はありません。

    • 選択したユーザーにアカウントがない場合: アプリケーション・インスタンスはカートに自動的に追加され、バルク・リクエストが作成されます。SOAがオフであるため、バルク・リクエストおよび子リクエストは自動承認されます。

    • 選択したユーザーが保留中のアカウント・リクエストを持つ場合: 新しく作成した権限リクエストは、アカウント・リクエストに依存するように設定されます。アカウントの承認が保留中である場合、SOAがオフであるため、リクエストはこれ以上処理されません。アカウント・リクエストが有効日待ちである場合、権限リクエストはアカウント・リクエストが完了した後に処理されます。

    SOAがオフであるときに権限リクエストの受益者が複数いる場合、バルク・リクエストが生成されます。バルク・リクエストは自動承認され、子リクエストが作成されます。次に、特定のユースケースを示します。

    • ユーザーが1つのアカウントを持つ場合: 権限リクエスト: これは自動承認され、完了します。

    • ユーザーが複数のアカウントを持つ場合: 対応する権限の子リクエストは失敗します。

    • ユーザーがアカウントを持たない場合: 対応する権限の子リクエストは失敗します。

    • ユーザーが保留中のアカウント・リクエストを持つ場合: 権限の子リクエストは、アカウント・リクエストに依存するように設定されます。アカウントの承認が保留中である場合、SOAがオフであるため、リクエストはこれ以上処理されません。アカウント・リクエストが有効日待ちである場合、権限リクエストはアカウント・リクエストが完了した後に処理されます。

    SOAコンポジットに依存する次のアカウントと権限のユースケースは失敗します。

    • 1人以上の受益者がアカウントを持たず、進行中のアカウント・リクエストがない場合の、権限に対する複数の受益者リクエスト

    • 1人以上の受益者が複数のアカウントを持ち、アカウントが識別されていない場合の、権限に対する複数の受益者リクエスト

アイデンティティ監査機能

ワークフローがオフである場合、証明およびアイデンティティ監査機能は機能せず、証明および監査コンプライアンスに関連するUIリンクはIdentity Self ServiceとIdentity System Administrationの両方で表示されません。これは、「アイデンティティ監査機能セットの使用可否」システム・プロパティの値がTRUEに設定されている場合に該当します。

ワークフローがオフである場合、証明関連のスケジュール済ジョブは実行されず、適切なメッセージがログに記録されます。

UMS通知

UMS通知プロバイダは、ワークフローが有効かどうかに応じて機能します。UMSプロバイダは、SOAが使用できない場合は通知を送信しません。SOAが使用できない場合にUMSプロバイダが有効な状態で維持されている場合、UMSは通知を送信しようとせず、エラー・メッセージがログに記録されます。通知を送信し続けるには、EmailServiceProviderなどの代替メソッドを構成して有効にする必要があります。

Webサービス・コネクタ

SOAが無効である場合、Webサービス・コネクタは機能しません。

SILベースのSoD

操作の結果としてリクエストが生成されるとしても、ワークフローが無効である場合、SILベースのSoDチェックは行われません。ただし、SOAが使用できない場合でも、SILベースのSoDチェックはプロビジョニング・レベルで機能し続けます。

ユーザー管理

  • ユーザーの自己登録: SOAがオフである場合でも、ユーザーの自己登録は機能し続けます。組織はホーム組織決定ポリシーを介して計算され、自己登録リクエストは自動承認されます。

  • プロキシ・ユーザー管理: SOAがオフである場合、オプション機能は無効です。Identity Self Service内のプロキシを管理するためのパネルは表示されず、プロキシに関わるすべてのAPIによって例外がスローされ、次のメッセージが表示されます。 

    Proxy functionality is only supported when SOA and workflows are enabled.

ユーザー・インタフェース

「ワークフロー有効」システム・プロパティがfalseに設定されている場合、デフォルトのユーザー・インタフェースで次の機能は無効です(表示されません)。

  • Oracle Identity System Administrationの場合: 「承認ポリシー」リンク

  • Oracle Identity Self Serviceの場合:Self Serviceホーム・ページの「証明」、オープン・タスクおよび「保留中の承認」リンク/アイコン、および「リクエストの詳細」/「サマリー」ページの「承認」タブ

4.6 無効化または削除されたプロキシ・ユーザーのユース・ケース

ユーザーが無効化されている場合、Oracle Identity Governanceは、開始されているタスクのターゲット割当て先がすでに無効化されているか、保留中のタスクの現在の割当て先が無効化されていても、割当てを失うことなくタスクを処理します。タスクのタイプは、リクエスト/承認タスク、アイデンティティ監査(IDA)スキャン違反または証明のいずれかです。

Oracle Identity Governanceバンドル・パッチ12.2.1.4.210428を適用すると、次の拡張機能が提供されます:

ユーザーが無効化または削除された場合のプロキシ関係の削除

ユーザーが無効化または削除されると、そのユーザーで定義されたすべてのプロキシ関係は有効ではなくなります。ユーザーの無効化時にアクティブなプロキシがある場合、プロキシは終了します。つまり、Oracle Identity Governanceは、このユーザーのすべてのプロキシ・データをデータベースおよびSOAから削除します。

たとえば、User1およびUser2はプロキシをUser3に設定し、User3はプロキシをUser4に設定します。User3を無効にすると、これらのプロキシ関係は削除されます。

プロキシ・クリーンアップ・アクションは、Oracle Identity GovernanceデータベースとSOAの両方で実行されます。その結果、プロキシ・データはシステムから完全に削除されます。

プロキシによるタスクの割当て

ユーザーがプロキシを設定している場合、すべてのタスクがユーザーとそのプロキシの両方に委任されます。これは、両方のユーザーが最初に同じレベルの制御権を持っていることを意味します。一方のユーザーがタスクに対するアクションの実行を開始すると、他方の割当て先の同じタスクに対する変更アクションは制限されます。

現在の割当て先が無効化または削除された場合のタスクの再割当て

ユーザーが無効化または削除されると、このユーザーとの間の既存のプロキシが削除され、OIG.DefaultTaskReassigneeシステム・プロパティの構成に応じて、保留中のすべてのタスクが他のユーザーまたはロールに再割当てされます。このプロパティには、アクティブなユーザーまたはロールを設定することが重要です。

デフォルトでは、OIG.DefaultTaskReassigneeシステム・プロパティの値はSYSTEM ADMINISTRATORSロールであるため、ユーザーが無効化または削除された場合、保留中のタスクがSYSTEM ADMINISTRATORSロールに再割当てされます。

OIG.DefaultTaskReassigneeシステム・プロパティの値がマネージャの場合、現在のターゲット割当て先が無効になっていると、Oracle Identity Governanceは最も近いアクティブなマネージャを階層から検索します。

OIG.DefaultTaskReassigneeシステム・プロパティの値がユーザーの場合、Oracle Identity Governanceはタスクをユーザーに再割当てします。

OIG.DefaultTaskReassigneeシステム・プロパティの値がロールの場合、Oracle Identity Governanceはタスクをロールに再割当てします。ここでは、OIG.DefaultTaskReassigneeシステム・プロパティの値としてのロール名は大/小文字が区別されます。

Oracle Identity Governanceで有効な割当て先が見つからない場合、タスクはシステム管理者に再割当てされます。

ノート:

この機能は、Oracle Identity Governanceユーザー・インタフェースまたはAPIから開始された無効化および削除操作に対してのみ機能します。リコンシリエーションおよびバルク・ロードからユーザーを無効化および削除しても、この新機能はトリガーされません。

新規初期タスク割当て先の定義

作成中のリクエストのターゲット割当て先がすでに無効化されている場合、Oracle Identity Governanceは、次に説明するように、構成された承認ワークフローに基づいて初期ターゲット割当て先の最も近いマネージャを検索します:

  • OIG.BeneficiaryManagerApprovalWorkflows(リクエストのみ): 初期ターゲット割当て先がすでに無効化されている場合、Oracle Identity Governanceは、次に示すような承認ワークフローの定義を使用してリクエストの受益者の最も近いマネージャを検索します:

    OIG.BeneficiaryManagerApprovalWorkflows=default/BeneficiaryManagerApproval!4.0,default/MyCustomComposite!1.0

    カンマ区切りを使用して、複数のコンポジットを定義できます。

  • OIG.RequesterManagerApprovalWorkflows(リクエストのみ): 初期ターゲット割当て先がすでに無効化されている場合、Oracle Identity Governanceは、次に示すような承認ワークフローの定義を使用してリクエストのリクエスタの最も近いマネージャを検索します:

    OIG.RequesterManagerApprovalWorkflows=default/RequesterManagerApproval!4.0,default/MyCustomComposite2!1.0

    カンマ区切りを使用して、複数のコンポジットを定義できます。

    ノート:

    OIG.BeneficiaryManagerApprovalWorkflowsおよびOIG.RequesterManagerApprovalWorkflowsプロパティは、リクエストにのみ適用されます。デフォルトでは、OIG.BeneficiaryManagerApprovalWorkflowsはdefault/BeneficiaryManagerApproval!4.0に設定され、OIG.RequesterManagerApprovalWorkflowsはdefault/RequesterManagerApproval!4.0に設定されています。次のように承認ワークフローをさらに追加できます:

    OIG.BeneficiaryManagerApprovalWorkflows= default/BeneficiaryManagerApproval!4.0,default/DefaultOperationalApproval!5.0

  • アイデンティティ監査(IDA)スキャン違反および証明は、マネージャがすでに無効化されている場合、初期ターゲット割当て先の最も近いアクティブなマネージャに割り当てられます。

    有効な割当て先が見つからない場合、Oracle Identity Governanceは、OIG.DefaultTaskReassigneeに定義されたユーザーにIDAスキャン違反および証明を割り当て、次にSYSTEM ADMINISTRATORまたはデフォルトの証明割当て先(定義されている場合)に割り当てます。

    証明の作成時に、アクティブな上位マネージャおよびOIG.DefaultTaskReassigneeとXL.AlternativeReviewerIDForManagerに定義されたユーザーを参照した後でも、有効な割当て先が存在しない場合、Oracle Identity Governanceはそのような証明の作成をスキップします。したがって、2つのシステム・プロパティが、操作のための十分な権限を持つアクティブ・ユーザーで定義されていることを確認してください。

新しいバージョンのCertificationProcessコンポジットのデプロイ

このバンドル・パッチの適用後にこの機能を有効にするには、CertificationProcessコンポジットの新しいバージョンをデプロイします。そのように行うには:

  1. 次に示すように、SOAからCertificationProcessコンポジットの現在のバージョンのバックアップを作成します:
    1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。
    2. 「SOA」→「soa-infra」→「デフォルト」→「CertificationProcess[2.0]」に移動します。
    3. 「SOAコンポジット」メニューから、「コンポジットのエクスポート」を選択します。
  2. OIM_HOME/server/workflows/composites/CertificationProcess.zipファイルの内容を一時ディレクトリに抽出します。
  3. 次のステップを実行して、deploy/sca_CertificationProcess_rev2.1.jarファイルをデプロイします:
    1. Oracle Enterprise Manager Fusion Middleware Controlで、「SOA」→「soa-infra」→「デフォルト」に移動します。
    2. 「SOAコンポジット」メニューから、「SOAデプロイ」→「デプロイ」を選択します。
    3. /deploy/sca_CertificationProcess_rev2.1.jarファイルの完全パスを指定します。
    4. SOAサーバーを再起動します。