ここでは、次の項目について説明します。
ワークフロー・ルール、リクエスト・プロセス・フロー(ワークフローがある場合とない場合)、およびリクエスト・ライフサイクル(1つのリクエストとバルク・リクエスト)について理解します。
この項では、承認ワークフローについて説明します。内容は次のとおりです。
リクエストの生成と承認は、ワークフロー・ルールの使用と構成によって異なります。
リクエストの生成および承認は次によって制御されます。
Oracle Identity Managerがワークフローを使用して実行されているかどうか。Oracle Identity Managerではワークフローはデフォルトで有効になっています。ワークフローなしでのOracle Identity Managerの実行の詳細は、「ワークフローなしでのOracle Identity Governanceの実行」を参照してください。
サポートされている操作に対して定義された承認ワークフロー・ルール。
注意:
承認ポリシーは、ワークフロー・ポリシーを優先するために非推奨になっています。このマニュアルで説明するように、リクエストの生成および承認はワークフロー・ポリシーによって管理されます。
以前のリリースからOracle Identity Managerをアップグレードした場合、Oracle Identity Manager管理者ガイドfor 11gリリース2 (11.1.2.2)の承認ポリシーの管理に関する項で説明されているように、承認ポリシーは引き続き動作します。
ただし、既存の承認ポリシーはすべてワークフロー・ポリシーに移行することをお薦めします。
ワークフロー・ルールにより、次が決定されます。
操作の承認が必要かどうか
特定の操作に対してどのワークフローを起動する必要があるか
リクエストのプロセス・フローは、操作が許可されるかどうか、単独の操作かバルク操作か、デプロイメントにワーフクローが含まれるかどうかによって異なります。
図4-1に、承認ワークフロー・ルールによって制御されるリクエストの生成および承認のプロセスを示します。
リクエスト・プロセス・フローは次のようになります。
ユーザーに付与されている管理ロールに基づいて認可チェックが実行されます。このチェックにより、操作の実行がユーザーに許可されるかどうかが決まります。
操作が認可されない場合、エラーが返され、フローは終了します。
操作が許可されると、バルク操作または先日付操作であるかがチェックされます。
バルク操作または先日付操作である場合、リクエストが作成され、ワークフロー・ルール評価に基づいて承認が開始され、承認後に操作は終了します。
バルク操作または先日付操作でない場合、承認ワークフロー・ルールが評価されます。この評価の結果により、リクエストが作成されるかどうかが決まります。
結果が直接である場合、リクエストは作成されず、操作は直接実行されます。
SOAワークフローIDが結果として返される場合、リクエストが作成され、ポリシー評価によって返されたワークフローが起動されます。
バルク・リクエストは次の方法で処理されます。
バルク・リクエストが許可された結果として、リクエストが常に作成されます。
バルク・リクエスト用として構成されている承認ワークフロー・ルールが表示されます。
ルール評価の結果としてワークフローIDが生成される場合、バルク・リクエストが作成され、対応するSOAワークフローが開始されます。
ルール評価の結果としてワークフローIDが生成されない場合、バルク・リクエストが作成されて自動承認されます。
バルク・リクエストが承認(自動承認またはSOAワークフロー承認)された後、子リクエストが作成されます。
子リクエストは承認ワークフロー・ルール評価(非バルク)を受け、その結果に基づいて処理されます。
各リクエストは、システムで作成された後、特定のライフサイクルを通過します。ライフサイクルによって、リクエストは様々なステージに遷移します。リクエストが存在するステージによって、コントローラがそのステップで実行するアクション、リクエストに対してその時点で使用可能な操作、および遷移が可能なステージが決定します。
リクエスト・ライフサイクルについては、次に示す項で説明します。
表4-1に、ライフサイクルの様々なステージでのリクエストの機能、およびリクエストのこれらのステージへの到達方法を示します。
表4-1 リクエストのステージ
リクエストのステージ | 説明 |
---|---|
リクエストの下書きが作成されました |
「カート詳細」ページの「下書きとして保存」ボタンをクリックすることによってリクエストを下書きとして保存すると、リクエストは「リクエストの下書きが作成されました」ステージに移動します。 リクエスタは、リクエストを将来の変更、送信または削除用に保存できます。これは、リクエスタがリクエストの送信前に追加情報を待っている場合に役に立ちます。下書きリクエストの取消しまたはクローズはできません。 注意: 下書きモードで保存されたリクエスト・データにはパスワードなどの機密情報を含めないでください。それらがリクエストを下書きとして保存する前に入力したものであっても同様です。 |
リクエストが作成されました |
正常に送信されたリクエストは、「リクエストが作成されました」ステージに移動します。 |
情報の指定 |
これは、権限リクエストのリクエスタに割り当てられたタスク(受信ボックスからアクセス可能)で、権限のプロビジョニングが必要なアカウントを検索し、選択するためのタスクです。 |
承認待ちのリクエスト |
作成されたリクエストに承認が定義されている場合は、リクエストは このステージでリクエストが取り消されるかクローズされた場合、リクエスト・エンジンはワークフロー・インスタンスごとにワークフローの取消しをコールします。タスクの取消しに関する通知が承認者に送信されます。 これらのステータスを正常に完了したリクエストは、リクエスト承認済ステージに到達します。 リクエストが正常に作成された後にSoD検証チェックがプラグインされる場合、リクエストは次のステータスに関連付けられます。
注意: これらのSoDリクエスト・ステータスが可能なのは、リクエストが次のリクエスト・タイプのいずれかである場合です。
|
リクエストが承認されました |
リクエストは、承認された場合のみ、次のステージに移動し、現在のステータスで更新されます。結果は「承認済」、「却下」または「保留」です。 |
リクエストが自動承認されました |
リクエストは、承認された場合のみ、次のステージに移動し、現在のステータスで更新されます。 |
否認されたリクエスト |
ワークフロー・インスタンスが更新されるたびに、リクエスト・サービスは、リクエスト・エンジンをそのインスタンスの現在のステータスで更新します。リクエスト・エンジンが想定しているリクエスト・サービスからの結果は、「承認」または「却下」です。インスタンス化されたワークフロー・インスタンスが却下された場合、リクエスト・エンジンはリクエストを「却下」ステージに移動します。任意のワークフロー・インスタンスが却下された場合、コントローラはすべての保留中のワークフローを取り消して、リクエストを「却下」ステージに移動します。 |
操作が開始されました |
リクエストが承認されると、リクエスト・エンジンはリクエストを「操作が開始されました」ステージに移動して、操作を開始します。 次のリクエスト・ステータスがこのステージに関連付けられています。
注意: バルク操作の場合、子リクエストはリクエスト・レベルの承認の後に作成され、親リクエストは「リクエストが子リクエストの完了待ちです」ステータスに移動します。 |
リクエストに失敗しました |
リクエストに指定されている関連操作の実行に失敗した場合、リクエストは保留中の操作を取り消して「リクエストに失敗しました」ステージに移動します。 次のリクエスト・ステータスがこのステージに関連付けられています。
|
リクエストが取り下げられました |
リクエスタはリクエストを取り消すことができます。このステージでは、リクエストが「リクエストが取り消されました」ステータスに関連付けられ、すべての承認の開始が取り消されます。 注意:
|
リクエストがクローズされました |
リクエストは、リクエスタによってクローズできます。このステージでは、リクエストが「リクエストがクローズされました」ステータスに関連付けられ、すべての承認の開始が取り消されます。 注意:
|
リクエストが完了しました |
リクエストに指定されたすべての操作の実行が完了すると、リクエスト・エンジンはリクエストを「リクエストが完了しました」ステージに移動します。 次のリクエスト・ステータスがこのステージに関連付けられています。
|
ステージに正常に到達すると、リクエストのステータスも対応するステータスに更新されます。
操作は、手動で実行するか、イベントに対応してシステムで自動的に実行できます。手動操作の例を次に示します。
リクエストの下書きとしての保存。
下書きリクエストの編集/更新。
リクエストの送信
リクエストのクローズ/取消し。
承認ワークフローが正常に承認されたことがサービスに通知されたときのリクエストの承認。
自動操作の例を次に示します。
リクエストが送信されたときの承認の開始。
リクエストが承認され、かつ実行日が将来の日付かまたは指定されていない場合のリクエストの実行。
1つのリクエストまたは非バルク・リクエストは、単一レベルの承認を受けます。承認ワークフローが起動されると、図4-2に示すように、リクエストは「承認待ちのリクエスト」
ステージに移動し、承認後に「リクエストが承認されました」
ステージに移動します。
バルク・リクエストまたは親リクエストのライフサイクルは、バルク・リクエストが「リクエストが承認されました」
ステージに移行するまでは、1つのリクエストまたは非バルク・リクエストと同じです。この後、図4-3に示すように、子リクエストに分割されてから、「操作が開始されました」
ステージの「リクエストが子リクエストの完了待ちです」
ステータスに移動します。
各子リクエストは、「1つのリクエスト・ライフサイクル」で説明しているライフサイクルを通過します。子リクエストが完了すると、バルク・リクエストまたは親リクエストは「リクエストが完了しました」
ステージに移動します。
承認ワークフロー・ルールを構成するには、ワークフロー・ルール、ルール条件、システム定義の操作とルールを理解し、承認ワークフロー・ルールを作成し、カスタム・ルール条件を構成し、承認ワークフロー・ルールを変更し、承認ワークフロー・ルールを削除し、承認ワークフロー・ルール評価を理解します。
この項では、承認ワークフロー・ルールの構成について説明します。内容は次のとおりです。
承認ワークフロー・ルールを構成することにより、操作に承認が必要かどうかを決定できます。また、承認が必要な場合、このルールにより、どのSOAワークフローを開始するかも示します。
操作および対応するワークフロー・ルールのリストは、Oracle Identity Managerに事前定義されています。これらのシステム定義のルールにより、承認が必要かどうか、および開始するSOAワークフローが決まります。すべての非バルク操作には、事前定義済の承認ワークフロー・ルールが構成されています。
サポートされている操作および対応するルールのリストは、「システム定義の操作およびルールについて」を参照してください。
注意:
Oracle Identity Managerでは、新しい操作および対応するルールを作成することはできません。ただし、既存の操作のルールを作成および変更することはできます。
承認ワークフロー・ルールは、サポートされているすべての操作に対して定義できます。これらは、次のとおりです。
ユーザーの自己登録
ユーザーの作成
ユーザーの変更
ユーザーの無効化
ユーザーの有効化
ユーザーの削除
ロールの作成
ロールの変更
ロールの削除
ロールの割当て
ロールからの削除
ロール付与を変更
ApplicationInstanceのプロビジョニング
アカウントの変更
アカウントの無効化
アカウントの有効化
アカウントの失効
権限のプロビジョニング
権限の変更
権限の失効
異種リクエスト
ユーザー・プロファイルの一括変更
ユーザーの一括無効化
ユーザーの一括有効化
ユーザーの一括削除
ロールの一括削除
ロールの一括割当て
ロールからの一括削除
ApplicationInstanceの一括プロビジョニング
アカウントの一括無効化
アカウントの一括有効化
アカウントの一括失効
権限の一括プロビジョニング
権限の一括失効
承認ワークフロー・ルールは、次に示すルールの条件と結果で構成されています。
承認ワークフロー・ルールは、次で構成されています。
条件: 操作レベルで定義されている許容入力に基づくルール条件
結果: 操作に対して開始するSOAワークフローIDであるワークフローID
「ユーザーの変更」操作の承認ワークフロー・ルールの例を次に示します。
ルールの条件:
requester.adminroles CONTAINS OrclOIMUserAdmin
ルールの結果:
Direct
ここでは、ルール条件により、リクエスタが受益者の組織内のユーザー管理者管理ロールのメンバーであるかどうかをチェックしています。条件が満たされる場合、承認ワークフローを開始せずに操作が実行されます。
ルール条件は操作ごとに異なります。たとえば、「ユーザーの作成」操作にはリクエスタ・データとともにユーザー・データが必要であり、「ロールの割当て」操作にはリクエスタ・データとともにロール情報およびユーザー・データが必要です。リクエスタ・データはすべての操作に必要です。Oracle Identity System Administrationでは、選択した操作に基づいて必要なロール条件を入力できます。
各承認ワークフローには複数のルールを関連付けることができますが、これらは一定の順序で定義する必要があります。たとえば、「ユーザーの作成」承認ワークフローには、契約者の作成、サプライヤの作成および「パートナの作成」などのルールを順番に定義できます。承認ワークフロー内のルールが評価される順序は、これらのルールがポリシー内に定義されている順序によって決まります。
各操作のルール条件の例は、「カスタム・ルール条件について」を参照してください。
各操作/ワークフロー・ポリシーにはデフォルトのルールがあり、その結果は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!5.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!5.0 |
アカウントの失効 |
Revoke Account Certification Rule |
request.isCertification Equal TRUE |
ワークフロー default/DefaultRequestApproval!5.0 |
権限の失効 |
Revoke Entitlement Certification Rule |
request.isCertification Equal TRUE |
ワークフロー default/DefaultRequestApproval!5.0 |
ロール付与を変更 |
Modify Role Grant IdentityAuditorEnabled Rule |
identityAuditEnabled EQUAL TRUE |
ワークフロー default/DefaultOperationalApproval!5.0 |
関連項目:
request.isCertification
およびidentityAuditorEnabled
条件の詳細は、表4-4。
注意:
表4-3に示されたワークフロー・ルールは、表4-2に示されたデフォルト・ルールより先に(順序に関して)構成されます。したがって、これらのルールは、デフォルト・ルールの前に評価されます。ワークフロー・ルールの評価の詳細は、「承認ワークフロー・ルール評価について」を参照してください。
たとえば、ロールの割当て操作には、2つのルールが次の順序でデフォルトで構成されています。
Assign Roles IdentityAuditorEnabled Rule
Assign Roles Default Rule
ロールの割当て操作のために開始する承認ワークフローを決定するには、Assign Roles IdentityAuditorEnabled Rule
ルールが最初に評価されます。ルールが一致しない(trueになる)場合、Assign Roles Default Rule
が評価されます。
承認ワークフロー・ルールを構成することにより、操作に承認が必要かどうかを決定できます。また、承認が必要な場合、このルールにより、どのSOAワークフローを開始するかも示します。
承認ワークフロー・ルールを作成するには:
Oracle Identity System Administrationにログインします。
左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。「ワークフロー構成の承認」ページが表示されます。
「ルールを構成する操作を選択します」セクションで、ルールを構成する操作を選択します。操作に関連付けられたルールがページ下部の「ルール」セクションに表示されます。このセクションには、操作に関連付けられたルール名、ルールの説明およびワークフローが表示されます。
「ルール」セクションでは、新しいルールを作成したり、既存のルールを選択して更新または削除できます。
注意:
承認ワークフロー・ポリシーに複数のルール条件が指定されている場合、ルールが評価される順序は、これらのルールがポリシー内で構成されている順序に基づいて決まります。この順序は、ルールの作成後は変更できません。したがって、これらのルールは、評価する順序で作成する必要があります。
「ルール」セクションの「作成」をクリックします。ルールの作成ページが表示されます。
「名前」ボックスに、ルールの名前を入力します。これは必須フィールドです。
「説明」ボックスに、ルールの説明を入力します。
「所有者」ボックスに、ルールの所有者を指定します。これを行うには、「所有者」フィールドの横の検索アイコンをクリックしてから、所有者を検索して選択します。
「ステータス」リストから、ルールのステータスを選択します。デフォルトでは、ルールは「有効」ステータスです。
「条件ビルダー」セクションで、IFおよびTHEN句でルール条件を指定します。これを行うには、次の手順を実行し、ユーザーが最上位組織のメンバーである場合は「ユーザーの作成」操作が自動承認される、サンプルのルール条件を作成します。
IF句の下にある空の行の先頭フィールドで、オブジェクトおよび属性を指定するには、フィールドの横の検索アイコンをクリックします。「条件ビルダー」ダイアログ・ボックスが表示されます。
注意:
オブジェクトおよび属性の正確な名前がわかっている場合は、検索アイコンをクリックするかわりに、先頭フィールドに条件(requester.Organization Name
など)を入力できます。
リクエスタ・データに基づいて条件を指定するため、「リクエスタ」をクリックします。リクエスタ・オブジェクトに対して指定可能な属性のリストが表示されます。ページ番号アイコンをクリックして選択すると、属性間を移動できます。それ以外の場合、検索フィールドに属性名を入力し、検索アイコンをクリックします。
注意:
「条件ビルダー」ダイアログ・ボックス内の任意の画面で「開始」をクリックすると、先頭の画面に戻り、オブジェクトを選択して新しい条件の指定を開始できます。
「組織名」属性をクリックします。「条件ビルダー」ダイアログ・ボックスに条件requester.Organization Name
が表示されます。
「OK」をクリックします。IF句の先頭フィールドに条件が追加されます。
「演算子」リストから「次と等しい」を選択します。
選択できる演算子は、次のとおりです。
EQUAL
NOT_EQUAL
CONTAINS
DOES_NOT_CONTAIN
BEGINS_WITH
DOES_NOT_BEGIN_WITH
ENDS_WITH
DOES_NOT_END_WITH
右側のフィールドで値を指定するには、検索アイコンをクリックします。「条件ビルダー」ダイアログ・ボックスが表示されます。
注意:
正確な値がわかっている場合は、検索アイコンをクリックするかわりに、値(Top
など)を入力できます。
次のオプションのいずれかを選択します。
値: 属性の値を指定します。
式: 式に基づいて条件を指定します。
この例の目的に従い、「値」オプションを選択します。「組織名」属性の値がリストされます。これは、ルールに指定されているオブジェクトおよび属性がrequester.Organization Name
であるためです。
「Top」をクリックします。Top組織が選択されます。
「OK」をクリックします。値フィールドにTop組織が移入されます。
別の条件を追加するには、「条件の追加」をクリックします。IF句の下に別の行が追加されます。右側の演算子リストから、「AND」または「OR」演算子を選択し、手順aからiで説明しているように別のルール条件を入力できます。
行を削除するには、行の左側のチェック・ボックスを選択し、「削除」をクリックします。
複数のルール条件を追加した場合、条件をグループ化できます。これを行うには、条件の左側のチェック・ボックスを選択し、「グループ」をクリックします。同様に、条件のグループを削除するには、条件の左側のチェック・ボックスを選択し、「グループ解除」をクリックします。
注意:
一度にグループ化できる条件は2つのみです。3つ以上の条件を選択する場合、「グループ」ボタンは無効になっています。また、「グループ解除」ボタンが有効になるのは、グループ化されている条件の1つを選択する場合のみです。ただし、複数のグループを選択すると、このボタンは無効になります。
最大2つの条件をグループ化できます。したがって、AND演算子を使用してグループ化された4つの条件を持つルールを作成する場合、条件は2セットでグループ化されます。しかし、条件の1つがOR演算子を使用してグループ化されている場合、ルールは正しく更新されます。
THEN句で、先頭フィールドの横の検索アイコンをクリックし、「条件ビルダー」ダイアログ・ボックスを開きます。
「workflow」を選択し、「OK」をクリックします。
ワークフローの値フィールドで、「AutoApproval!1.0」を選択します。このワークフローを選択すると、リクエストは自動承認されます。
「OK」をクリックします。値フィールドにワークフロー値が移入されます。
したがって、指定したルール条件は次のようになります。
IF requester.Organization Name EQUALS Top THEN workflow default/AutoApproval!1.0
「作成」をクリックし、ルール条件を作成します。ルール条件を作成した操作を選択すると、そのルール条件が表内に表示されます。
注意:
「リスク」属性を使用してルールの条件を定義する場合、ルールを正しく評価するために、リクエストが行われる前にリスク集計ジョブというスケジュール済ジョブを実行する必要があります。
アプリケーション・インスタンスの場合、属性をフィルタ処理して除外するメカニズムがありません。アプリケーション・インスタンスのすべての属性がルールを書き込むことができる条件ビルダーに表示されます。ロールでは、ロール名を選択すると、ロール・エンティティの属性リストが表示されます。属性リストの表示には、アスタリスク(*)ワイルドカード文字を選択できます。
各ワークフロー操作のルール条件の例は、「カスタム・ルール条件について」を参照してください。
注意:
このリリースでは、ワークフロー・ルールの作成時に、「ロール」ではなく「ユーザー・タイプ」を使用します。たとえば、次のルール条件では、user.User Type
がuser.Role
のかわりに使用されます。IF user.User Type=Contractor
THEN capability=selfModifyUser
カスタム・ルール条件の構文は、操作と、それに対応する条件の最上位属性で構成されます。
表4-4に、カスタム・ルール条件の指定方法と例を示します。
表4-4 承認ワークフロー・ルールの構文と例
操作 | 条件の最上位属性 | ワークフロー・ルール条件の作成(最上位属性に基づく) |
---|---|---|
バルクを含むすべての操作 |
operation |
これは、現在実行されている操作を示します。次に例を示します。 operation EQUALS Create User 注意: このような条件を使用できるのは、目的の結果が常に |
バルクを含むが自己登録ユーザーを除くすべての操作 |
requester |
これは、すべてのリクエスタのユーザー・プロファイル属性、ロールおよび管理ロール・メンバーシップを示します。例: requester.Email CONTAINS @mydomain.com requester.adminRoles CONTAINS OrclOIMUserAdmin この条件は、リクエスタの電子メールIDにmydomain.comが含まれるかどうか、およびリクエスタがOrclOIMUserAdmin管理ロールのメンバーであるかどうかを意味します。 |
ユーザーの作成 |
user |
これは、ユーザーの作成時にリクエスタが指定できるすべてのユーザー・エンティティ属性を示します。例: user.Last Name EQUALS Doe |
ユーザーの変更 |
user |
これは、ユーザーの変更時にリクエスタが指定できる、変更中のユーザーのすべてのユーザー・エンティティ属性を示します。例: user.Organization EQUALS Marketing |
「ユーザーの無効化」、「ユーザーの有効化」および「ユーザーの削除」 |
user |
これは、ユーザーのプロファイルに現在設定されている、無効化、有効化または削除中のすべてのユーザー属性を示します。例: existingUser.Organization EQUALS Marketing |
「ユーザーの無効化」、「ユーザーの有効化」および「ユーザーの削除」 |
request |
これは、リクエスト・メタデータを示し、唯一許可されるサブ属性は request.isCertification EQUAL true 注意: |
ロールの作成 |
role |
これは、ロールの作成時に指定できるすべてのロール・エンティティ属性を示します。例: role.Name EQUALS ITAdmin ロールの作成時にはカタログ・メタデータ属性も指定できるため、条件はカタログ・メタデータ属性にも基づいて許可されます。例: role.catalog.Category EQUAL Role |
ロールの作成 |
identityAuditEnabled |
これを使用して、 identityAuditEnabled EQUALS TRUE 注意: |
ロールの変更 |
role |
これは、ロールの変更時に指定できるすべてのロール・エンティティ属性を示します。例: role.Name EQUAL ITAdmin ロールの変更時にはカタログ・メタデータ属性も指定できるため、条件はカタログ・メタデータ属性にも基づいて許可されます。例: role.catalog.Category EQUAL Role |
ロールの変更 |
existingRole |
これは、変更対象のロールに対して現在設定されているすべてのロール・エンティティ属性を示します。例: existingRole.DisplayName EQUALS IT Administrator ロールの変更時にはカタログ・メタデータ属性も指定できるため、条件はカタログ・メタデータ属性にも基づいて許可されます。例: role.catalog.Category EQUAL Role |
ロールの変更 |
identityAuditEnabled |
これを使用して、 identityAuditEnabled EQUALS TRUE 注意: |
ロールの削除 |
existingRole |
これは、削除対象のロールに対して現在設定されているすべてのロール・エンティティ属性を示します。例: existingRole.DisplayName EQUALS IT Administrator |
ロールの削除 |
identityAuditEnabled |
これを使用して、 identityAuditEnabled EQUALS TRUE 注意: |
「ロールの割当て」、「ロールからの削除」 |
user |
これは、ロールの割当て対象かロール・メンバーシップの失効対象であるユーザー/受益者のプロファイルに現在設定されているすべてのユーザー属性を示します。例: user.Organization EQUALS Marketing |
「ロールの割当て」、「ロールからの削除」 |
role |
これは、割当て対象かユーザーからの失効対象であるロールのすべての属性を示します。例: role.name EQUAL IT Administrator |
「ロールの割当て」、「ロールからの削除」 |
catalogItem |
これは、アクセス・リクエストの送信対象であるロールに対応するカタログ・メタデータ属性を示します。例: catalogItem.Category EQUAL Role |
「ロールの割当て」、「ロールからの削除」 |
identityAuditEnabled |
これを使用して、 identityAuditEnabled EQUALS TRUE 注意: |
「ロールの割当て」、「ロールからの削除」 |
request |
これは、リクエスト・メタデータを示し、唯一許可されるサブ属性は request.isCertification EQUAL true 注意: |
ロール付与を変更 |
user |
これは、ロール・メンバーシップの変更対象であるユーザー/受益者のプロファイルに現在設定されているユーザー属性を示します。例: user.Organization EQUALS Marketing |
ロール付与を変更 |
role |
これは、メンバーシップの変更対象であるロールの属性を示します。例: role.name EQUALS IT Administrator |
ロール付与を変更 |
catalogItem |
これは、アクセス・リクエストの送信対象であるロールに対応するカタログ・メタデータ属性を示します。例: catalogItem.Category EQUAL Role |
ロール付与を変更 |
identityAuditEnabled |
これを使用して、 identityAuditEnabled EQUALS TRUE 注意: |
ApplicationInstanceのプロビジョニング |
user |
これは、アカウントのプロビジョニング対象であるユーザー/受益者のユーザー・プロファイル属性を示します。例: user.Organization EQUALS Marketing |
ApplicationInstanceのプロビジョニング |
appType |
これは、ユーザー/受益者へのプロビジョニング対象であるアカウントを示します。
例1: appType[AD User].appInstance[VisionEmployeesDomain].account[*].Organization Name EQUAL Marketing この条件は、 注意: ワークフロー・ルール評価では、リクエスト対象であるアカウントのみが考慮され、ユーザー/受益者が所有している可能性がある既存のアカウントは考慮されません。 例2: appType[AD User].appInstance[*].account[*].Organization Name EQUAL Marketing この条件は、 |
ApplicationInstanceのプロビジョニング |
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 |
これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します( |
「アカウントの有効化」、「アカウントの無効化」、「アカウントの失効」 |
request |
これは、リクエスト・メタデータを示し、唯一許可されるサブ属性は request.isCertification EQUAL true 注意: |
権限のプロビジョニング |
user |
これは、権限のプロビジョニング対象であるユーザー/受益者のユーザー・プロファイル属性を示します。例: user.Organization EQUALS Marketing |
権限のプロビジョニング |
appType |
これは、操作の実行時に指定対象である権限情報またはデータを示します。例: appType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp この条件は、 |
権限のプロビジョニング |
catalogItem |
これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します( |
権限の変更 |
user |
これは、権限付与の変更対象であるユーザー/受益者のユーザー・プロファイル属性を示します。例: user.Organization EQUALS Marketing |
権限の変更 |
appType |
これは、操作の実行時に指定対象である権限情報またはデータを示します。例: appType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp この条件は、 |
権限の変更 |
existingAppType |
これは、権限情報または既存の権限フォーム・データ(開始日や終了日など)を示します。例: existingAppType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp この条件は、VisionEmployeesDomainアプリケーション・インスタンスのユーザー/受益者に対する |
権限の変更 |
catalogItem |
これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します( |
権限の失効 |
user |
権限付与の失効対象であるユーザー/受益者のユーザー・プロファイル属性。例: user.Organization EQUALS Marketing |
権限の失効 |
existingAppType |
これは、権限情報または既存の権限フォーム・データ(開始日や終了日など)を示します。例: existingAppType[AD User].appInstance[VisionEmployeesDomain].account [*].UD_ADUSRC[*].Group Name EQUAL PasswordPolicyAdminGrp この条件は、 |
権限の失効 |
catalogItem |
これは、アクセス・リクエストの送信対象であるカタログ項目に設定されているカタログ・メタデータ属性を示します( |
権限の失効 |
request |
これは、リクエスト・メタデータを示し、唯一許可されるサブ属性は request.isCertification EQUAL true 注意: |
ワークフロー・ルールを変更することにより、ルール条件を追加、変更または削除できます。
「承認ワークフロー・ルールの作成」で追加したワークフロー・ルールを変更するには:
Identity System Administrationの左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。「ワークフロー構成の承認」ページが表示されます。
「操作」セクションで、ルールを構成する操作を選択します。
「ルール」セクションで、「編集」をクリックします。ルールの編集ページが表示されます。
「操作」セクションで、ワークフロー・ルールを変更する操作を検索して選択します。この例の目的に従い、「ユーザーの作成」を選択します。「ユーザーの作成」操作のルールが「ルール」セクション内の表に表示されます。
「ルール」セクションで、編集するルールを選択し、「編集」をクリックします。ルールの編集ページが表示されます。
ルール属性を変更する場合は、「ルールの編集」セクションで属性値を更新します。
「条件ビルダー」セクションで、オブジェクト、属性または値フィールドを変更することによって既存のルールを変更できます。また、既存の条件に条件を追加することも、ルール条件を削除することもできます。次の手順を実行し、リクエスタがUserHelpDesk管理ロールを持つ場合は「ユーザーの作成」操作にターゲット・ユーザー・マネージャの承認が必要であることを指定するルール条件を追加します。
「条件ビルダー」セクションで、「条件の追加」をクリックします。新しい行が追加されます。
右側の演算子リストから「OR」を選択します。
行の先頭フィールドで、「条件ビルダー」ダイアログ・ボックスを使用してrequester.adminRole
を指定します。「条件ビルダー」ダイアログ・ボックスでの値の選択の詳細は、「承認ワークフロー・ルールの作成」の手順10を参照してください。
演算子リストから「CONTAINS」を選択します。
値フィールドで、「条件ビルダー」ダイアログ・ボックスを使用してOrclOIMUserHelpDesk
を選択します。
THENセクションの2つ各フィールドでworkflowおよびdefault/BeneficiaryManagerApproval!3.0を指定します。このため、完全なルール条件は次のようになります。
IF requester.adminRoles CONTAINS OrclOIMUserHelpDesk THEN workflow default/BeneficiaryManagerApproval!3.0
このルール条件により、リクエスタがUserHelpDesk管理ロールを持つ場合はユーザーを作成するためにターゲット・ユーザー・マネージャの承認が必要になります。
「更新」をクリックします。ワークフロー・ルールは新しいルール条件を使用して更新されます。
ルール条件を削除するには、ルール条件の左側のチェック・ボックスを選択し、「削除」をクリックします。次に、「更新」をクリックします。
すべての操作に対して定義したワークフロー・ルールを削除できます。ただし、デフォルトのルールは削除しないことをお薦めします。
ワークフロー・ルールを削除するには:
バルク操作と非バルク操作の承認ワークフロー・ルール評価について理解します。
操作(バルクまたは非バルク)が実行対象である場合、承認ワークフロー・ルール評価は次の方法で実行されます。
実行対象の操作に関連付けられた承認ワークフロー・ルールが構成時の順序で1つずつ評価されます。
ルール評価が停止し、一致したルールの結果(ワークフローIDまたは直接)が戻されます。
承認ワークフロー・ルールは最初に一致したルール(trueに評価されたルール)で停止し、このルールの結果が結果として戻されます。
バルク操作の場合、一致するルールがない場合は、SOAConfigのdefaultRequestApprovalComposite
に構成されているSOAコンポジットが暗黙的に戻されます。
非バルク操作の場合、一致するルールがない場合は、SOAConfigのdefaultRequestApprovalComposite
に構成されているSOAコンポジットが暗黙的に戻されます。
承認ワークフロー・ルールによってワークフローID (UserManagerApproval
など)が戻される場合、リクエストが作成され、対応するASYNC編成が開始されます。編成の一環として、ユーザーによって送信されたデータの一部が変更または追加される可能性があります。この結果、UserManagerApproval
以外のワークフローIDが適用可能になる可能性があります。このようなシナリオを処理するために、ワークフローが開始される前に承認ワークフロー・ルールが再評価されます。再評価の結果として別のワークフローID (HRManagerApproval
)が適用される場合、HRManagerApproval
が開始されます。
アップグレードされたデプロイメントでリクエスト承認を管理するには、アップグレードされたデプロイメントでのリクエスト承認プロセスと、ワークフロー・ルールが無効なリクエスト・プロセス・フローを理解し、承認ポリシーを移行し、ワークフロー・ルールを有効にします。
この項では、アップグレードされた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 ... |
アップグレードされたOracle Identity Managerデプロイメントのデフォルトでは、承認ワークフローは無効です。
図4-4に、承認ワークフローが無効である場合のリクエスト・プロセスを示します。
承認ワークフロー・ルール機能が無効である場合、承認ポリシーの結果として戻されるApprovalRequired責任により、操作に承認が必要かどうかが決まります。
ApprovalRequiredがfalseである場合、リクエストは作成されず、直接操作になります。
ApprovalRequiredがtrueである場合、承認ポリシーが評価され、承認ポリシー評価によって戻されたSOAワークフローが開始されます。
デフォルトでは、1つのワークフロー・ポリシーが1つの操作に使用できますが、操作またはリクエストの1つのタイプに対してリクエスト・レベルまたは操作レベルで複数の承認ポリシーを構成できます。
承認ポリシーから承認ワークフロー・ルールへ移行するには:
1つのリクエスト・タイプに対して適用可能な承認ポリシーをすべて識別します。リクエスト・レベルと操作レベルに複数のポリシーが存在する場合があるため、これらの優先度または順序を識別するために手動分析が必要です。
1つの操作またはリクエスト・タイプには、リクエスト・レベルまたは操作レベルで複数の承認ポリシーが構成されている場合があります。これに対して、デフォルトでは、1つの操作に対して適用可能な承認ワークフロー・ポリシーは1つのみです。このデフォルトの承認ワークフロー・ポリシーは削除できませんが、同じものに対して新しいルールを追加することはできます。
優先度の順序の先頭または2番目にくる承認ポリシーを選択します。
リクエスト・タイプに固有のデフォルトの承認ポリシー構成を開きます。現在の承認ポリシーをバルク・ワークフロー・ポリシー・ルールとして変更する必要がある場合は、デフォルトのバルク・ポリシー(「ユーザーのバルク変更」など)を開きます。
次のように、現在の承認ポリシーを承認ワークフロー・ルールとしてモデル化します。
手順2で選択した承認ポリシー名と同じ名前で新しい承認ワークフロー・ルールを作成します。承認ワークフロー・ルールの説明を入力します。
関連項目:
承認ワークフロー・ルールを処理するためのユーザー・インタフェースの詳細は、「承認ワークフロー・ルールの作成」および「承認ワークフロー・ルールの変更」を参照してください
Oracle Identity System Administrationの「ワークフロー構成の承認」ページで、承認ポリシーで承認プロセスとして構成されているワークフローを検索して選択します。
「ワークフロー構成の承認」ページで承認ポリシー・ルールを承認ワークフロー・ルール条件としてモデル化します。
1つのリクエスト・タイプに対して適用可能なすべての承認ポリシーに対して手順2から4を繰り返します。
すべてのリクエスト・タイプに対して手順1から5を繰り返します。
アップグレードされたデプロイメントで承認ワークフロー・ルールを有効化するには、ワークフロー・ルール機能を有効化し、進行中のリクエストのライフサイクルを理解します。
この項では、次の項目について説明します。
アップグレードされたOracle Identity Managerデプロイメントのデフォルトでは、承認ワークフロー・ルール機能は無効です。この機能を有効にするには、次の手順を実行します。
「ワークフロー有効」
システム・プロパティの値がtrue
であることを確認します。「ワークフロー・ポリシー有効」
システム・プロパティの値をtrue
に設定します。Oracle Identity Managerを12cリリース2 (12.2.1.2.0)にアップグレードする場合、アップグレード後に処理する必要がある進行中のリクエストがいくつか存在する可能性があります。承認ワークフロー・ポリシー機能が有効になった後、進行中のリクエストすべてのライフサイクルは、ワークフロー決定を除いてOracle Identity Managerの以前のリリースの場合と同じです。開始されるSOAワークフローは、承認ポリシーではなくワークフロー・ポリシーに基づいて決定されます。進行中のリクエストは既存のリクエスト・ステージを経過します。これには、「リクエスト承認を取得しています」、「操作承認を取得しています」、「リクエスト承認が承認されました」、「操作承認が承認されました」、「リクエスト承認が却下されました」および「操作承認が却下されました」の各ステージがあります。
承認ワークフローを有効にした後、進行中のリクエストは次の方法で処理されます。
リクエスト承認待ちの進行中のリクエストの場合
図4-5に、リクエスト承認待ちの進行中のリクエストのライフサイクルを示します。
リクエストが承認されると、承認ワークフロー・ルールが評価され、操作レベルで開始するSOAワークフローが決定されます。リクエストは「操作承認を取得しています」
ステージに移動します。
リクエストが却下されると、リクエストは「リクエスト承認が却下されました」
ステージに移動します。
操作承認待ちの進行中のリクエストの場合
図4-6に、操作承認待ちの進行中のリクエストのライフサイクルを示します。
リクエストが承認されると、操作が開始されます。
リクエストが却下されると、リクエストは「操作承認が却下されました」
ステージに移動します。
テスト環境のワークフロー・ルールを本番環境に移行できます。
この項では、次の項目について説明します。
ワークフロー・ルールは、デプロイメント・マネージャを使用してソース環境(テスト環境など)からエクスポートしてターゲット環境(本番環境など)にインポートできます。
ワークフロー・ルールおよびルールから操作/ポリシー関係への移行は、デプロイメント・マネージャ・ウィザードのポリシーのカテゴリに分けられます。デプロイメント・マネージャの詳細は、「デプロイメント・マネージャを使用した増分移行」を参照してください。
ワークフロー・ルールは特定の操作に関連付けられているため、操作を最初に選択してから、エクスポートするルールを選択する必要があります。
ワークフロー・ルールをエクスポート/インポートする場合、ソース環境内のワークフロー・ルール構成によってターゲット環境内のワークフロー・ルール構成がオーバーライドされます。この結果、操作のワークフロー・ルールがインポートされると、この操作に構成されているすべてのルールが削除され、エクスポートしたルールがターゲット環境内のこの操作に関連付けられます。また、ソース環境内のルールの順序はターゲット環境に引き継がれます。
たとえば、ターゲット環境の「ユーザーの作成」操作にはルールRule1およびRule2が構成されているとします。しかし、ソース環境の「ユーザーの作成」操作にはルールRule1およびRule3が構成されており、これらが両方ともエクスポートされるとします。これらのルールがターゲット環境にインポートされると、Rule1およびRule2は削除され、Rule1およびRule3が「ユーザーの作成」操作に関連付けられます。
したがって、ソース/テスト環境をワークフロー・ルール構成の真のソースとして保持することをお薦めします。
デプロイメント・マネージャを使用して、操作とポリシーをエクスポートし、それらをターゲット環境にインポートします。
デプロイメント・マネージャを使用してワークフロー・ルールをエクスポート/インポートするには:
注意:
ワークフロー・ルール条件は、ロールやアプリケーション・インスタンスなどのエンティティを参照できます。このような依存エンティティはワークフロー・ルール移行の一環として移行できません。このような依存エンティティはターゲット/本番環境で手動で構成または移行する必要があります。それ以外の場合は、ルール評価結果が予測不可能になる可能性があります。
Oracle Identity Managerは、デフォルトでインストールされて有効になっているSOAサーバーに依存します。しかし、インストール後の構成手順としてSOAを無効にすることにより、ワークフローを手動で無効にすることができます。
この章では、SOAを無効にする手順と、この手順の実行による機能的な影響について次の各項で説明します。
SOAサーバーを無効にするには、「ワークフロー有効」
システム・プロパティの値を設定します。
SOAサーバーを無効にするには:
「ワークフロー有効」
システム・プロパティの値をfalse
に設定します。このシステム・プロパティの詳細は、表19-1を参照してください。SOAサーバーを再度有効にするには、「ワークフロー有効」
システム・プロパティの値をtrue
に設定します。
注意:
SOAは無効にした後に再度有効にしないことをお薦めします。ワークフローの有効化と無効化の切り替えはサポートされていません。
ワークフローの無効化による主な機能的な影響は、すべての操作が自動承認されることです。つまり、操作は承認なしで完了します。承認ワークフローが開始されないため、承認ポリシーおよび承認ワークフロー・ルールはどちらも評価されません。
図4-7にワークフローの無効化の影響を示します。
また、表4-6に、ワークフローが無効である場合に使用できない機能をリストします。
表4-6 ワークフローの無効時に使用不可能な機能
機能 | 詳細 |
---|---|
リクエスト承認 |
|
プロビジョニング操作 |
|
アイデンティティ監査機能 |
ワークフローがオフである場合、証明およびアイデンティティ監査機能は機能せず、証明および監査コンプライアンスに関連するUIリンクはIdentity Self ServiceとIdentity System Administrationの両方で表示されません。これは、 ワークフローがオフである場合、証明関連のスケジュール済ジョブは実行されず、適切なメッセージがログに記録されます。 |
UMS通知 |
UMS通知プロバイダは、ワークフローが有効かどうかに応じて機能します。UMSプロバイダは、SOAが使用できない場合は通知を送信しません。SOAが使用できない場合にUMSプロバイダが有効な状態で維持されている場合、UMSは通知を送信しようとせず、エラー・メッセージがログに記録されます。通知を送信し続けるには、EmailServiceProviderなどの代替メソッドを構成して有効にする必要があります。 |
Webサービス・コネクタ |
SOAが無効である場合、Webサービス・コネクタは機能しません。 |
SILベースのSoD |
操作の結果としてリクエストが生成されるとしても、ワークフローが無効である場合、SILベースのSoDチェックは行われません。ただし、SOAが使用できない場合でも、SILベースのSoDチェックはプロビジョニング・レベルで機能し続けます。 |
ユーザー管理 |
|
ユーザー・インタフェース |
|