| Oracle® Fusion Middleware Oracle Identity Manager管理者ガイド 11g リリース2 (11.1.2.2.0) B69535-08 |
|
 前 |
 次 |
承認ポリシーはリクエスト管理の構成可能なエンティティで、リクエスト・レベルおよび操作レベルの承認のみに対してリクエスト・サービスで定義された承認プロセスに、各種リクエスト・タイプを関連付けるのに役立ちます。これは、リクエスト・タイプに対して、リクエスト・レベルまたは操作レベルで開始される承認ワークフローを関連付けます。承認ポリシーを使用して、SOAベース・ワークフローである様々な承認プロセスに各種リクエスト・タイプを関連付けることができます。承認ポリシーによって、リクエスト・データ評価に基づいてどの承認プロセスを起動するかが制御されます。
1つのリクエスト・タイプに対して複数の承認ポリシーを定義できます。各承認ポリシーは1つの承認プロセスに関連付けられます。承認開始フェーズでリクエストが送信されると、そのリクエスト・タイプに関連付けられたすべての承認プロセスが動的に取得されます。各承認ポリシーには、バックエンドに優先度が設定されます。各承認ポリシーでは、承認ポリシー優先度および承認ポリシー・ルールに基づいて、起動するプロセスを決定します。
承認ポリシー優先度は、次に基づいています。
リクエスト・レベルの場合: リクエスト・タイプ + リクエスト・レベル
操作レベルの場合: リクエスト・タイプ + 操作レベル + スコープ(リクエストに関連付けられた特定のエンティティ)
リクエスト・エンジンは、承認ワークフローを開始するとき、そのリクエスト・タイプに対して使用可能なすべての承認ポリシーを優先度順に取得します。優先度の最も高い承認ポリシーが取得され、その承認ポリシー・ルールが評価されます。その評価が失敗すると、優先度が次に高い承認ポリシーの承認ポリシー・ルールが評価されます。評価の結果が「True」の場合は、承認ポリシーに関連付けられた対応する承認プロセスが、そのリクエストのワークフローとして選択されます。承認ポリシー・ルールの作成については、「承認ポリシーの作成」を参照してください。
|
注意: 1つの承認ポリシーに対して承認ポリシー・ルールは1つのみです。ルールは、複数の条件や他のルールが含まれて複雑になる可能性があります。ルールは独立したエンティティとして存在しないため、他の承認ポリシーで再利用できません。承認ポリシーに対するデフォルト・ルールはありません。ルールが定義されていない場合、承認ポリシーは評価されません。 |
承認ポリシーの作成および変更では、アプリケーション・インスタンスのプロビジョニング、権限のプロビジョニング、権限の失効などのリクエスト・タイプがサポートされます。さらに承認ポリシーでは、同一のリクエスト内で複数のエンティティがリクエストされる、異種リクエスト・タイプもサポートします。異種リクエスト・タイプの場合、リクエスト・レベルでのみ承認ポリシーを作成できます。操作レベルでは、適切なリクエスト・タイプは、エンティティ・タイプおよび子リクエストに関連付けられた操作に基づいて設定されます。異種リクエストの詳細は、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』の異種リクエストに関する説明を参照してください。
この章の項目は次のとおりです。
承認プロセスの選択方法とは、開始する承認ワークフローを選択するアルゴリズムです。リクエスト・エンジンは、リクエスト・タイプおよび承認レベルに基づいて、使用する方法を決定し、それに従って承認プロセスを評価します。
リクエスト・レベルで承認が定義されていない場合は、デフォルト承認プロセスが起動されます。
|
注意: リクエストおよび操作レベルで起動されるデフォルト・コンポジットは変更できません。 |
デフォルト承認プロセスはOracle Identity Managerに付属しており、管理者に割り当てられます。操作レベルで承認が定義されていない場合は、デフォルト承認プロセスが起動されます。
|
注意: エンティティに対する認可者権限がリクエスタに付与されている場合は、承認ポリシーに関係なく、操作レベルの承認リクエストが生成されません。認可者権限については、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の管理ロールの割当てに関する項を参照してください。 |
次の方法が使用されます。
この方法は、すべてのリクエスト・タイプに対して、承認のリクエスト・レベルで使用されます。リクエスト・レベルの選択方法の決定アルゴリズムは次のとおりです。
リクエスト・レベル、およびリクエストが関連付けられたリクエスト・タイプに対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。
各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエスト・レベルの承認は自動的に承認されます。
承認ポリシー・ルールを満たす承認ワークフローがない場合は、リクエスト・レベルで構成された承認ワークフローがないとみなされます。
該当する承認ワークフローがない場合は、デフォルト・リクエスト・レベルの承認が選択されます。
この方法は、ユーザー関連のすべてのリクエスト・タイプ(「ユーザーの作成」、「ユーザーの変更」、「ユーザーの無効化」、「ユーザーの有効化」、「ユーザーの削除」など)に対して、承認の操作レベルで使用されます。操作レベルでの組織ベースの選択方法の決定アルゴリズムは次のとおりです。
リクエストが作成される、ユーザーの組織エンティティを取得します。
操作レベル、リクエストに関連付けられたリクエスト・タイプ、またはすべての組織に対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。
各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエストは操作レベルで自動的に承認されます。
承認ポリシー・ルールを満たす承認ワークフローがない場合、この組織の操作レベルで構成された承認ワークフローはないとみなされます。
その組織エンティティに対して構成された承認ワークフローがない場合は、ルート・ノードまたはドメイン境界(組織階層のルート組織)まで組織階層を移動します。組織ノードごとにステップ2を繰り返します。
該当する承認ワークフローがない場合は、デフォルト操作レベルの承認が選択されます。
この方法は、ロール関連のすべてのリクエスト・タイプに対して、承認の操作レベルで使用されます。操作レベルでのロール・ベースの選択方法の決定アルゴリズムは次のとおりです。
ユーザーに割り当てられるか、またはユーザーから削除されるロール・エンティティを取得します。
操作レベル、リクエストに関連付けられたリクエスト・タイプ、または割り当てるか削除されるすべてのロールに対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。
各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエストは操作レベルで自動的に承認されます。
承認ポリシー・ルールを満たす承認ワークフローがない場合、このロールの操作レベルで構成された承認ワークフローはないとみなされます。
該当する承認ワークフローがない場合は、デフォルト操作レベルの承認が選択されます。
また、この方法も権限関連リクエスト(プロビジョニング/失効/変更)で使用されます。操作レベルでのアプリケーション・インスタンスベースの選択方法の決定アルゴリズムは次のとおりです。
リクエストに関連付けられたアプリケーション・インスタンス・エンティティを取得します。権限リクエストの場合にこの手順で、権限に関連付けられたアプリケーション・インスタンスが取得されます。
操作レベル、リクエストに関連付けられたリクエスト・タイプ、またはリクエストに関連付けられたすべてのアプリケーション・インスタンスに対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。
各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエストは操作レベルで自動的に承認されます。
承認ポリシー・ルールを満たす承認ワークフローがない場合、このアプリケーション・インスタンスの操作レベルで構成された承認ワークフローはないとみなされます。
該当する承認ワークフローがない場合は、デフォルト操作レベルの承認が選択されます。
Oracle Identity System Administrationにログインします。
左ペインの「ポリシー」で、「承認ポリシー」をクリックします。Oracle Identity Manager拡張管理が新しいウィンドウに表示されます。
|
注意: Oracle Identity Manager拡張管理がすでに開いている場合は、「ポリシー」タブをクリックし、「承認ポリシー」をクリックします。または、「ようこそ」ページで、「ポリシー」の下にある「承認ポリシーの検索」をクリックします。 |
左ペインの「アクション」メニューから「作成」を選択します。または、ツールバーにあるプラス(+)記号が付いたアイコンをクリックして、「承認ポリシーの作成」ウィザードを開始することもできます。ステップ1. 承認ポリシーの詳細の設定ページ(「承認ポリシーの作成」ウィザード)が表示されます。
次のフィールドに値を入力し、「次」をクリックします。
ポリシー名: 承認ポリシーの名前を入力します。これは必須属性です。
説明: この承認ポリシーの機能について説明を入力します。
リクエスト・タイプ: LOVからリクエスト・タイプ(「ロールの割当て」など)を選択します。これは必須属性です。
|
注意: 次のリクエスト・タイプは非推奨になっており、LOVには表示されません。
|
レベル: この承認ポリシーに対して実装する承認レベルを選択します。これは必須属性です。リクエスト・レベルおよび操作レベルの承認の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のワークフローの概念に関する項を参照してください。
スコープ・タイプ: 選択したリクエスト・タイプに基づいて自動的に設定されます。例:
リクエスト・タイプを「ユーザーの作成」に設定すると、「スコープ・タイプ」は「組織」に自動的に設定されます。
リクエスト・タイプを「ロールの割当て」に設定すると、「スコープ・タイプ」は「ロール」に自動的に設定されます。
アプリケーション・インスタンスや権限をプロビジョニングするようにリクエスト・タイプを設定すると、「スコープ・タイプ」は「アプリケーション・インスタンス」に自動的に設定されます。
|
注意: 「スコープ・タイプ」、「すべてのスコープ」および「スコープ」フィールドは、「レベル」フィールドを「操作レベル」に設定した場合のみ有効になります。「レベル」フィールドを「リクエスト・レベル」に設定した場合、これらのフィールドは無効になります。 |
すべてのスコープ: このオプションを選択して、特定のエンティティ・タイプのすべてのエンティティに関連付ける承認ポリシーを指定します。たとえば、「ユーザーの作成」リクエスト・タイプの場合、「スコープ・タイプ」は「組織」です。「すべてのスコープ」を選択すると、この承認ポリシーはOracle Identity Managerのすべての組織に適用可能になります。これは、スコープが「アプリケーション・インスタンス」および「ロール」の場合も同様です。
スコープ: このオプションを選択して、特定のエンティティ・タイプの特定のエンティティに関連付ける承認ポリシーを指定します。承認ポリシーは、「スコープ・タイプ」に基づいて特定のスコープに関連付けることができます。
「スコープ」フィールドは、「すべてのスコープ」フィールドが設定されると無効になります。「すべてのスコープ」フィールドが設定されない場合、このフィールドは必須になり、値を設定する必要があります。
自動承認: このオプションを選択して、「レベル」フィールドでの選択に基づき、リクエスト・レベルまたは操作レベルでの自動承認を指定します。
承認プロセス: この承認ポリシーに関連付けるワークフローを選択します。このフィールドは、「自動承認」が選択されると無効になり、値を設定できません。「自動承認」が設定されない場合、このフィールドは必須になります。
|
注意: 承認に基づくコンポジットのみを選択できます。承認に基づかないコンポジットはここでは選択できません。たとえば、default/DisconnectedProvisioning!1.0/default/DefaultSODApproval!1.0は選択できません。 |
ステップ2. 承認ルールおよびコンポーネントの設定ページで、「ルール名」フィールドに承認ポリシー・ルールの名前(例: RuleTest1)を入力します。
「ルール・コンポーネント」セクションで、承認ポリシー・ルールのパラメータを定義できます。これを行うには、「表示」リストの横にあるアイコンをクリックします。「単純ルールの追加」ダイアログ・ボックスが表示されます。このダイアログ・ボックスで、次のフィールドの値を選択し、「保存」をクリックします。
エンティティ: 承認ポリシー・ルールが関連付けられるエンティティ(「リクエスタ」、「受益者」、「アプリケーション・インスタンス」など)。これは、選択したリクエスト・タイプおよび承認レベルに基づいて決まります。
属性: 前述の選択したエンティティの属性。
|
注意: 単純ルール式を記述するとき、エンティティ属性にエンコード値がある場合は、参照コード定義ではなくエンコード値を使用して式が作成されます。たとえば、「アカウント・ステータス」属性の場合、デコード値の「ロック」または「ロック解除」ではなく、エンコード値の1または0を使用して式が作成されます。 |
条件: 承認ポリシー・ルールの条件(「次と等しい」、「次と等しくない」、「次で始まる」など)。
値: 条件の値。
|
注意: ルール式で「ユーザー・ログイン」属性を使用する場合は、対応する「ユーザー・ログインID」の値をすべて大文字で入力する必要があり、そうしないと、式で「True」と評価されません。 |
親ルール・コンテナ: この承認ポリシー・ルールを関連付ける必要があるルール・コンテナ。
ルール・コンテナは、「AND」と「OR」を組み合せて複雑な条件をモデル化するために使用できます。承認ポリシー・ルールのルール・コンテナを追加するには、「ルール・コンポーネント」セクションで、「アクション」メニューから「ルール・コンテナの追加」を選択します。「ルール・コンテナの追加」ダイアログ・ボックスが表示されます。このダイアログ・ボックスで、次のフィールドの値を入力または選択し、「追加」をクリックします。
ルール・コンテナ名: ルール・コンテナの名前。
親ルール・コンテナ: このルール・コンテナを作成するルール・コンテナの名前。ルール・コンテナには、別のルール・コンテナを含めたり、「AND」や「OR」演算子を使用してルール要素を階層的に順番に含めることができます。
演算子: 演算子は「AND」および「OR」です。
承認ルールの作成の完了後に、「次」をクリックします。
ステップ3. 承認ポリシー・サマリーの確認ページで、承認ポリシーに関して指定した情報を確認します。必要な場合は、「戻る」ボタンをクリックして情報を変更できます。「終了」をクリックして、承認ポリシーを作成します。
承認ポリシーが作成されたことを確認するメッセージが表示されます。「OK」をクリックします。
Oracle Identity Manager拡張管理で、「承認ポリシー」タブの左ペインにある「検索」フィールドに、承認ポリシーを検索するための検索基準を入力します。アスタリスク(*)ワイルドカード文字を指定して、検索基準を指定できます。
|
注意: 承認ポリシーの単純検索および拡張検索では、翻訳された承認ポリシー名での検索はサポートされていません。Oracle Identity Managerでは、承認ポリシーについて英語の文字列検索のみサポートされています。デフォルトの承認ポリシーの場合は、データベースに格納されている英語のポリシー名で検索できます。ただし、別の言語でポリシー名を指定して承認ポリシーを作成した場合は、同じ文字列(その他の言語でなく)を使用してポリシーを検索できます。 |
検索アイコンをクリックします。検索結果表に、次のフィールドを含む承認ポリシーのリストが表示されます。
ポリシー名: 承認ポリシーの名前。
リクエスト・タイプ: 承認ポリシーに関連付けられたリクエスト・タイプの名前。
|
注意: この章で前述したように、次のリクエスト・タイプは非推奨です。
現在のリリースにアップグレードした場合、(非推奨リクエスト・タイプに基づいて)以前のリリースで作成された承認ポリシーの検索や変更を行うと、これらの非推奨リクエスト・タイプを表示できます。さらに、以前のリリースで作成された非推奨リクエスト・タイプに基づいてリクエストをOracle Identity Self Serviceの「リクエストの追跡」ページに表示できます。 |
スコープ: 関連付けられたアプリケーション・インスタンス、組織またはロール名。スコープは、操作レベルのリクエストに関連付けられた承認ポリシーの場合のみ表示されます。
レベル: 承認レベル。
ルール名: 承認ポリシー・ルールの名前。
承認プロセス: 承認ポリシーに関連付けられた承認プロセス。
優先度: 承認ポリシーの優先度。
「承認ポリシー」タブの「拡張検索」オプションを使用して、拡張検索基準に基づいて承認ポリシーを検索することもできます。これを行うには、次のようにします。
「承認ポリシー」タブの左ペインで、「拡張検索」をクリックします。「拡張検索: 承認ポリシー」ページが表示されます。
フィールドに値を入力して検索基準を指定します。検索基準を指定する際には、承認ポリシー名、承認ポリシーに関連付けられたリクエスト・タイプの名前、承認レベル、スコープ・タイプ(アプリケーション・インスタンス、組織、ロールなど)およびスコープを組み合せて指定できます。
「検索」をクリックします。検索結果に承認ポリシーのリストが表示され、優先度、ポリシー名、リクエスト・タイプ、スコープ、レベル、ルール名および承認プロセスの情報が表示されます。
「アクション」メニューから「開く」を選択します。「承認ポリシーの詳細」フォームが表示されます。
「ポリシーの詳細」セクションで、フィールドを編集して承認ポリシーを変更します。
|
注意: 承認ポリシー・ルール名および承認ポリシー優先度属性は変更できません。 |
必要に応じて、「承認ルール」セクションで承認ポリシー・ルールを変更します。承認ポリシー・ルールを変更するには、単純ルールの追加、ルール・コンテナの追加、ルール・コンポーネントの変更またはルール・コンポーネントの削除を行うことができます。承認ポリシー・ルールおよびルール・コンテナの追加方法の詳細は、「承認ポリシーの作成」のステップ5から7を参照してください。
ルール・コンポーネントを変更する手順は、次のとおりです。
承認ポリシー・ルールを選択します。
「アクション」メニューから「ルール・コンポーネントの変更」を選択します。「ルール・コンポーネントの変更」ダイアログ・ボックスが表示されます。
表示されたフィールドの値を編集し、「適用」をクリックします。
ルール・コンポーネントを削除する手順は、次のとおりです。
削除する承認ポリシー・ルールを選択します。
「アクション」メニューから「ルール・コンポーネントの削除」を選択します。確認を求めるメッセージ・ボックスが表示されます。
「はい」をクリックして削除を確認します。
「保存」をクリックして、承認ポリシーに対する変更内容を保存します。
承認ポリシーの検索結果から、優先度を変更するポリシーを選択します。
「アクション」メニューから「優先度の設定」を選択します。「承認ポリシー優先度の変更」ウィザードが表示されます。
「ポリシーの詳細の設定」ページで、必須フィールドに値を指定します。このページのフィールドについては、「承認ポリシーの作成」のステップ4を参照してください。次に、「次」をクリックします。
「ポリシー優先度の設定」ページで、承認ポリシーの優先度を指定する数値を入力します。次に、「次」をクリックします。
「確認および確定」ページに、設定したポリシー名と優先度が確認のために表示されます。現在の優先度を変更する場合は、「戻る」をクリックします。
それ以外の場合は、「終了」をクリックします。承認ポリシー優先度が正常に変更されたことを示すメッセージが表示されます。
「OK」をクリックします。
|
注意: Oracle Identity Managerでは検証が実行されないため、同じ優先度を複数の承認ポリシーに設定することが可能です。同じ優先度を複数の承認ポリシーに設定することはお薦めしません。 |
承認ポリシーの検索結果から、削除する承認ポリシーを選択します。
「アクション」メニューから「削除」を選択します。確認を求めるメッセージ・ボックスが表示されます。
「はい」をクリックして削除を確認します。
承認ポリシーを使用するのではなく、SOAのOracle Business Rules (OBR)を利用することをお薦めします。ビジネス・ルールをSOAで使用する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認および手動プロビジョニングのワークフローの開発に関する項を参照してください。
さらに、次のガイドラインに従ってください。
すべての承認要件を見直し、フローのセットにまとめます。
リクエストレベルの承認が必要かどうかを評価します。
運用コンポジットでは、付与、失効、変更などのリクエストのタイプに基づいてリクエストWebサービスを利用して、高いレベルの分割にします。その後できめ細かな分割にします。ここで再びリクエストWebサービスとデフォルト・ペイロードを利用して、意思決定ができます。また、OBRを使用することで簡単に使用したりメンテナンスするように評価を外部化できます。
1つ以上のヒューマン・タスクとデシジョン・ポイントを追加し、複数のヒューマン・タスク間で選択します。ヒューマン・タスクは実際の承認ワークフローを示します。
新しいコンポジットのみを最後のオプションとして作成します。
