| Oracle® Fusion Middleware Oracle Identity Managerユーザーズ・ガイド 11gリリース2 (11.1.2.2.0) B69542-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managerユーザーズ・ガイド 11gリリース2 (11.1.2.2.0) B69542-07 |
|
前 |
次 |
Oracle Identity Managerでは、ロールの自身への追加やアプリケーション・インスタンスのプロビジョニングなどの様々な操作が、リクエストを介して実行されます。リクエストは特定のアクションを実行するユーザーまたは管理者が作成したエンティティで、アクションを実行するには、誰かまたはなんらかのプロセスから事前に任意の権限を取得しておく必要があります。たとえば、ユーザーはラップトップ・コンピュータへのアクセス権を取得するためのリクエストを作成し、マネージャはそのリクエストに基づいてオープン購買依頼を作成できます。
リクエストでは、リクエスタ、受益者(オプション)およびターゲット・エンティティを使用します。リクエスタは、リクエストを作成または要求します。リクエスタは、ユーザーまたはシステム自体の場合があります。システム生成リクエストのリクエスタは、機能コンポーネントによって決定されます。システム生成リクエストの例には、アクセス・ポリシーに基づいてシステムが作成するリクエストがあります。この場合、機能コンポーネントはアクセス・ポリシーです。未認証リクエストの場合、リクエスタはOracle Identity Managerに対して認証されないため、システムに存在しません。
受益者は、リクエストの完了後に実行されたアクションから利益を得るエンティティですが、このリクエストが完了するのは、リクエストが正常に実行された場合のみです。
Oracle Identity Managerでは、ロール、アプリケーション・インスタンスおよび権限などの用語はエンティティとして定義されます。各エンティティは、それぞれに属する属性のリストを保守します。各エンティティは、サポートする操作のリストも定義します。
ターゲット・エンティティは、受益者のためにリクエストされるリソースまたはエンティティです。
たとえば、ユーザーJohn DoeにUNIXアカウントをプロビジョニングするリクエストを作成します。この場合、自分はリクエスタ、John Doeは受益者、UNIXアカウントはJohn Doeのためにリクエストされるターゲット・エンティティです。
このガイドの前半で説明したように、Oracle Identity Managerでは、ロール、アプリケーション・インスタンスおよび権限などのエンティティのリクエストをサポートしています。リクエスト・カタログを使用すると、これらのエンティティをリクエストできます。
各リクエストは、システムで作成された後、特定のライフサイクルを通過します。このライフサイクルは、リクエスト・サービスによって管理および制御されます。ライフサイクルによって、リクエストは様々なステージに遷移します。リクエストが存在するステージによって、コントローラがそのステップで実行するアクション、リクエストに対して使用可能な操作、およびその時点で遷移が可能なステージが決定します。図9-1に、リクエストのプロセス・フローの概要を示します。
リクエスト・プロセス・フローの説明では、リクエストを介してユーザーにラップトップ・コンピュータをプロビジョニングする例を使用します。ステップは次のとおりです。
リクエスタは、リクエストUIを使用して、ユーザーにラップトップ・コンピュータを割り当てるリクエストを要求します。
|
注意: リクエストは、Oracle Identity Self Serviceを使用してあげることができます。また、リクエスタは、リクエストを下書きとして保存し、将来の変更、送信または削除に使用することもできます。 |
リクエストは、リクエスト・サービスに送信されます。
リクエストは、Oracle Identity Managerデータベースにも格納されます。
リクエスト・レベルの承認ワークフローは、サービス指向アーキテクチャ(SOA)のリクエスト・サービスによって開始されます。ワークフロー構成に基づいて、関連するタスクは対応する承認者に割り当てられます。
|
関連項目: 承認ワークフローの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認および手動プロビジョニングのワークフローの開発に関する説明を参照してください。 |
リクエスト・レベルの承認者は、アイデンティティ・セルフ・サービスの受信ボックスを使用してリクエストを承認します。この例では、リクエスタのマネージャ(承認者1)が、ユーザー1にラップトップを割り当てるかどうかを決定するリクエスト・レベルの承認者です。リクエスト・レベルの承認者がリクエストを却下すると、リクエストは「却下」ステージに移動します。
|
注意: ユーザーが項目をリクエストすると、Oracle Identity Managerは、リクエスタがそのカタログ項目を表示できるかどうか確認します。ただし、その項目を受益者に付与できるかどうかは確認しません。リクエストが承認されると、Oracle Identity Managerは、リクエストされたアクセスを受益者に付与できるかどうか確認します。 |
承認者1が自身のロールを承認者2に指定している場合は、承認者2が、ユーザー1にラップトップを割り当てるかどうかを決定するリクエスト・レベルの承認者です。承認者2がリクエストを却下すると、リクエストは「却下」ステージに移動します。
操作レベルの承認者は、受信ボックスを使用してリクエストを承認します。この例では、組織のIT管理者がユーザーへのラップトップの発行を担当する操作レベルの承認者(承認者2)です。操作レベルの承認者がリクエストを却下すると、リクエストは「却下」ステージに移動します。
|
注意: リクエストがリクエスト・レベルで却下された場合、操作レベルのリクエストは開始されません。 |
リクエスト操作はリクエスト・サービスで開始されて、リクエストが実行されます。
リクエスト操作が完了します。このステージで、リクエスト操作が「完了」ステータスになります。
リクエスト・ステータスが、Oracle Identity Managerデータベースで更新されます。
この章では、リクエスト管理について次の各項で説明します。
各リクエストは、システムで作成された後、特定のライフサイクルを通過します。このライフサイクルは、リクエスト・サービスによって管理および制御されます。ライフサイクルによって、リクエストは様々なステージに遷移します。リクエストが存在するステージによって、コントローラがそのステップで実行するアクション、リクエストに対してその時点で使用可能な操作、および遷移が可能なステージが決定します。図9-2に、リクエスト・サービスにおけるリクエストのライフサイクル・フローの概要を示します。
|
注意: リクエストが正常に送信されない場合は、エラー・メッセージがUIに表示されます。SPML開始リクエストの場合は、エラー・メッセージがSPMLにスローされます。 |
図9-2は、リクエストが通過できるすべてのステージを示しています。この図は、単純なリクエストの各ステージを示しています。バルク・リクエストの詳細は、「図9-3 バルク・リクエストと子リクエストのステージ」を参照してください。
各ステージは、リクエスト・ライフサイクルにおける論理的な次のステップを表しています。リクエストが1つのステージから次のステージに移動できるのは、操作が正常に実行された場合のみです。
表9-1に、ライフサイクルの様々なステージでのリクエストの機能、およびリクエストのこれらのステージへの到達方法を示します。
表9-1 リクエストのステージ
| リクエストのステージ | 説明 |
|---|---|
|
リクエストの下書きが作成されました |
「カート詳細」ページの「下書きとして保存」ボタンをクリックすることによってリクエストを下書きとして保存すると、リクエストは「リクエストの下書きが作成されました」ステージに移動します。 リクエスタは、リクエストを将来の変更、送信または削除用に保存できます。これは、リクエスタがリクエストの送信前に追加情報を待っている場合に役に立ちます。下書きリクエストの取消しまたはクローズはできません。 下書きリクエストの変更、送信または削除の詳細は、「下書きリクエストのトラッキング」を参照してください。 注意: 下書きモードで保存されたリクエスト・データにはパスワードなどの機密情報を含めないでください。それらがリクエストを下書きとして保存する前に入力したものであっても同様です。 |
|
リクエストが作成されました |
正常に送信されたリクエストは、「リクエストが作成されました」ステージに移動します。 |
|
情報の指定 |
これは、権限リクエストのリクエスタに割り当てられた新規タスク(受信ボックスからアクセス可能)で、権限のプロビジョニングが必要なアカウントを検索し、選択するためのタスクです。 |
|
承認の取得 |
作成されたリクエストに承認が定義されている場合は、リクエスト・エンジンがそのリクエストを「承認の取得」ステージに自動的に移動します。このステージでは、対応する承認がリクエスト・サービスを介して開始されます。完了と同時に、リクエスト・エンジンは、このリクエストに定義されているモデルを参照して承認の選択方法を検索し、インスタンス化する正確な承認プロセスを検出します。 リクエスト・エンジンは、開始する必要のある承認を検出すると、リクエスト・サービスを再度コールしてワークフローをインスタンス化します。 このステージでリクエストが取り消されるかクローズされた場合、リクエスト・エンジンはワークフロー・インスタンスごとにワークフローの取消しをコールします。タスクの取消しに関する通知が承認者に送信されます。 次のリクエスト・ステータスが「承認の取得」ステージに関連付けられています。
これらのリクエスト・ステータスの詳細は、「バルク・リクエストと子リクエスト」を参照してください。 これらのステータスを正常に完了したリクエストは、リクエスト承認済ステージに到達します。 リクエストが正常に作成された後にSoD検証チェックがプラグインされる場合、リクエストは次のステータスに関連付けられます。
注意: これらのSoDリクエスト・ステータスが可能なのは、リクエストが次のリクエスト・タイプのいずれかである場合です。
|
|
承認 |
操作承認が承認された場合のみ、リクエストは次のステージに移動し、リクエスト・エンジンは現在のステータスで更新されます。リクエスト・エンジンが検出する結果は、「承認」、「却下」または「保留」です。 次のリクエスト・ステータスがこのステージに関連付けられています。
|
|
却下 |
ワークフロー・インスタンスが更新されるたびに、リクエスト・サービスは、リクエスト・エンジンをそのインスタンスの現在のステータスで更新します。リクエスト・エンジンが想定しているリクエスト・サービスからの結果は、「承認」または「却下」です。インスタンス化されたワークフロー・インスタンスが却下された場合、リクエスト・エンジンはリクエストを「却下」ステージに移動します。任意のワークフロー・インスタンスが却下された場合、コントローラはすべての保留中のワークフローを取り消して、リクエストを「却下」ステージに移動します。 次のリクエスト・ステータスがこのステージに関連付けられています。
|
|
操作が開始されました |
リクエストが承認されると、リクエスト・エンジンはリクエストを「操作が開始されました」ステージに移動して、操作を開始します。 次のリクエスト・ステータスがこのステージに関連付けられています。
注意: バルク操作の場合、子リクエストはリクエスト・レベルの承認の後に作成され、親リクエストは「リクエストが子リクエストの完了待ちです」ステータスに移動します。 |
|
リクエストに失敗しました |
リクエストに指定されている関連操作の実行に失敗した場合、リクエストは保留中の操作を取り消して「リクエストに失敗しました」ステージに移動します。 次のリクエスト・ステータスがこのステージに関連付けられています。
|
|
取消し済 |
リクエスタはリクエストを取り消すことができます。このステージでは、リクエストが「リクエストが取り消されました」ステータスに関連付けられ、すべての承認の開始が取り消されます。 注意:
|
|
クローズ |
リクエストは、リクエスタによってクローズできます。このステージでは、リクエストが「リクエストがクローズされました」ステータスに関連付けられ、すべての承認の開始が取り消されます。 注意:
|
|
完了 |
リクエストに指定されたすべての操作の実行が完了すると、リクエスト・エンジンはリクエストを「リクエストが完了しました」ステージに移動します。 次のリクエスト・ステータスがこのステージに関連付けられています。
|
ステージに正常に到達すると、リクエストのステータスも対応するステータスに更新されます。
操作は、手動で実行するか、イベントに対応してシステムで自動的に実行できます。手動操作の例を次に示します。
リクエストの下書きとしての保存。
下書きリクエストの編集/更新。
リクエストの送信。
リクエストのクローズ/取消し。
承認ワークフローが正常に承認されたことがサービスに通知されたときのリクエストの承認。
自動操作の例を次に示します。
リクエストが送信されたときの承認の開始。
リクエストが承認され、かつ実行日が将来の日付かまたは指定されていない場合のリクエストの実行。
バルク・リクエストは、複数の受益者または複数のエンティティ(あるいはその両方)を含むリクエストです。たとえば、ユーザーJohn Doeに複数のロールを割り当てるリクエストでは、バルク・リクエストが生成されます。ユーザーJohn DoeおよびJane DoeにADユーザーなどのリソースをプロビジョニングするプロビジョニング・リクエストでも、バルク・リクエストが生成されます。バルク・リクエストには、2つの部分があります。
親リクエスト: 複数の受益者または複数のターゲット・エンティティ(あるいはその両方)を含めて送信されたリクエストは、親リクエストです。
子リクエスト: 親リクエストに対してリクエスト・レベルの承認が発生した場合は、複数の子リクエストが作成されます。親リクエストは、1人の受益者と1つのターゲット・エンティティを含む複数の子リクエストに分割されます。
バルク・リクエストのエンティティ・データは、リクエストに指定されている異なる受益者間で同じである必要があります。たとえば、「アプリケーション・インスタンスのプロビジョニング」タイプのリクエストの場合、複数の受益者が選択されていると、「バルク更新」とマークされたフォーム・フィールドのみが表示され、その値はすべての受益者で共通になります。
生成される子リクエスト数は、各受益者に関連付けられているターゲット・エンティティの数に依存します。各受益者の関連するターゲット・エンティティの1つを使用して、各子リクエストが生成されます。子リクエストには、1人の受益者と1つのターゲット・エンティティのみが含まれます。
受益者が含まれていないリクエストの場合は、ターゲット・エンティティごとに各子リクエストが生成されます。次に例を示します。
2人のユーザーの属性を変更するユーザーの修正バルク・リクエストの場合、各ユーザーの属性に2つの子リクエストが作成されます。
別の例について考えてみます。「アプリケーション・インスタンスのプロビジョニング」タイプのリクエストの場合、2人の受益者が存在します。2つのアプリケーション・インスタンスが受益者ごとにプロビジョニングされます。このシナリオでは、最初の受益者に対して2つの子リクエストがあり、2番目の受益者に対して2つの子リクエストがあります。各子リクエストには、各アプリケーション・インスタンスとそれに関連する受益者が存在します。したがって、このバルク・リクエストには、1つの親リクエストと4つの子リクエストの合計が存在します。
リクエスト・レベルの承認は、親リクエストの一部として実行されます。親リクエストは子リクエストを生成した後、子リクエストが操作レベルの承認を完了するまで「リクエストが子リクエストの完了待ちです」ステージに移動して待機します。すべての子リクエストが完了すると、親リクエストは「完了」ステージに移動します。
操作レベルの承認は、子リクエストに対してのみ実行されます。承認者は、子リクエストを個別に承認または却下できます。すべての子リクエストが承認または却下された場合、親リクエストは「完了」ステージに到達します。子リクエストの1つ以上(すべてではない)が失敗した場合、親リクエストは「リクエストの一部が失敗しました」ステージに到達します。すべての子リクエストが失敗した場合、親リクエストは「失敗」ステージに到達します。
図9-3に、リクエスト・サービスにおけるリクエストのライフサイクル・フローの概要を示します。
異種リクエストはタイプの異なるエンティティ用に作成されたリクエストです。Oracle Identity Managerでは、ロール、アプリケーション・インスタンス、権限など、本来はタイプが異なるエンティティのリクエストを一度に実行できます。
異種リクエストでは、次のリクエスト・タイプがサポートされています。
アプリケーション・インスタンスのプロビジョニング
ロールの割当て
権限のプロビジョニング
異なるエンティティについて送信されるリクエストの場合、リクエスト・タイプは「異種リクエスト」として設定されます。たとえば、ロールと権限などの2つの個別のエンティティについて1つのリクエストを送信する場合、リクエスト・タイプは「異種リクエスト」になります。
同じタイプの複数のエンティティについて送信されるリクエストの場合は、リクエスト・タイプは選択したエンティティに従って設定されます。たとえば、複数のロールについてリクエストを送信する場合、リクエスト・タイプは「ロールの割当て」になります。
Oracle Identity Managerのユーザーは、アプリケーションで様々な操作を実行できます。Oracle Identity Managerで実行可能なすべての操作は、定義されている認可ポリシーによって制御されます。組織内のユーザーに付与された管理ロールは、ユーザーがOracle Identity Managerで実行可能な操作が直接的なものかリクエストによるものかを決定します。たとえば、ユーザー管理者である場合は、ユーザーの作成、ユーザーの変更、アカウントの付与、ユーザー・アカウントの有効化などのすべての操作は、直接的な操作です。同様に、ユーザー・ビューア管理ロールを割り当てられている場合は、ユーザーの作成、ユーザーの有効化、ユーザーの削除、ロールの付与、権限の失効などの操作では、リクエストが作成されます。Oracle Identity Managerでの管理ロール、各管理ロールのユーザーに許可されている対応する権限、および操作が直接的なものなのかリクエストを使用するのかについての詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の「セキュリティ・アーキテクチャ」を参照してください。
操作がリクエストを使用するのか直接実行されるのかは、次によって決まります。
操作を実行しているユーザーに付与された管理ロール。ユーザーに付与された管理ロールに基づいて、操作がリクエストを使用するのか直接的なものなのかを決定するために認可チェックが実行されます。
バルク操作か1回の操作か。ユーザーに付与された管理ロールに関係なく、バルク操作では常にリクエストを使用します。
「有効日」フィールドに値が指定されているかどうか。「有効日」フィールドに値が指定されている場合は、1回の操作かバルク操作かに関係なく、操作でリクエストが使用されます。
有効日が指定されない1回の操作の場合:
自身に対して操作を実行している場合、リクエストが使用されます。
他のユーザーに対して操作を実行しており、自身が認可者である場合は、直接的な操作になります。
直接的な操作かリクエストかを決定するための認可チェックは、Oracle Identity Managerのすべての操作で行われるわけではありません。操作がリクエストかどうかの判断は、リクエスト可能な操作に対してのみ行われます。リクエスト可能なデフォルトの操作の詳細は、「リクエスト・カテゴリ」の表を参照してください。
直接的な操作かリクエストかのチェックは、操作に対応するリクエスト・モデルがある場合にのみ操作に適用されます。したがって、組織を作成するためのリクエスト・モデルはないため、この認可チェックは組織の作成ではなくユーザーの作成に対して実行されます。同様に、ユーザー・アカウントのロックおよびロック解除も、リクエストか直接的な操作かを決定するための認可チェックが実行されない操作です。したがって、これらの操作は直接的です。
リクエストの作成は、SOAワークフローが起動され、手動の承認が取得されることを必ずしも意味するわけではないことに注意してください。リクエストは作成されても、承認を必要としないシナリオがあります。次のサンプル・シナリオを考えてみます。
シナリオ1:
操作がバルクである場合、リクエストは作成されますが、操作レベルでは、リクエスタがエンティティの管理者であると判断された場合、自動承認とみなされます。
シナリオ2:
SoDチェックが有効な場合は、承認ワークフローは必ず開始される必要があります。これは、SoDチェックが承認ワークフローでのみ行われるためです。
エンド・ユーザーは、アプリケーション・インスタンス、権限、およびホーム組織に公開されたロールなどのエンティティのリクエストを、同じ組織内の自分または他人に送信できます。他の組織のユーザーのリクエストを送信するには、(ユーザーが属する各組織の)「ユーザー・ビューア」管理ロールと対応する「アプリケーション・インスタンス・ビューア」、「権限ビューア」または「ロール・ビューア」ロールを付与されている必要があります。
Oracle Identity Managerには、2つのリクエスト・カテゴリがあります。
カタログベースのリクエスト: このタイプのリクエストでは、アクセス・リクエスト・カタログを使用したユーザーに対するアクセス権の付与に焦点が当てられます。カタログベースのリクエストは、ロール、アプリケーション・インスタンスおよび権限などのエンティティに対して作成されるリクエストです。次に、カタログベースのリクエストのタイプを示します。
ロール・リクエスト: これはエンタープライズ・ロールに対するリクエストで、関連付けられたアクセス・ポリシーが1つ以上あります。
アプリケーション・インスタンス・リクエスト: これは、ターゲット・アプリケーションのアカウントに対するリクエストです。アプリケーション・インスタンスは、ターゲット・アプリケーションのアカウントを表し、通常、Oracle Identity ManagerではITリソース・インスタンスと呼ばれます。アプリケーション・インスタンスのリクエストおよびプロビジョニングは、ターゲット・アプリケーションにアカウントが作成されたことを意味します。
権限リクエスト: これは、ターゲット・アプリケーションでの追加のアクセスに対するリクエストです。たとえば、E-Business Suiteアカウントでは、CRM管理者または給与処理スーパーバイザなどの権限をリクエストできます。ユーザーが権限をリクエストすると、その権限がプライマリ・アカウントに追加されます。プライマリ・アカウントおよびプライマリ以外のアカウントの詳細は、「アカウントのリクエスト」を参照してください。
デフォルトでは、カタログはエンティティのタイプによって分類されます。カタログ項目を変更し、独自のカテゴリを指定できます。カタログ項目の表示および変更の詳細は、「アクセス・リクエスト・カタログの使用」を参照してください。
リクエスト項目をリクエスト・カートに追加することによって、カタログベースのリクエストを作成します。リクエスト・カートには、同じまたは異なるエンティティ・タイプの項目を含めることができます。
リクエスト項目をカートに追加した後、ターゲット・ユーザーを選択する場所のチェックアウトに進み、リクエストを送信します。選択可能なユーザー(つまり、リクエストの受益者)は、組織全体で持っている「ユーザー・ビューア」管理ロールによって決まります。
追加情報を指定する必要があるアプリケーション・インスタンスには、それ自体に関連付けられたフォームがあります。そのようなアプリケーション・インスタンス・リクエストは、フォームが完了しないと送信できません。
Oracle Identity Managerには、事前に定義された一連のリクエスト・タイプがあります。表9-2に、カタログベースのリクエストに対してOracle Identity Managerがデフォルトでサポートしている操作およびリクエスト・タイプを示します。
カタログベース以外のリクエスト: このタイプのリクエストは、リクエスト・カタログを使用せずに作成されます。カタログベース以外のリクエストの例には、自己登録、ユーザーの作成、ユーザーの変更、アカウントの変更、アカウントの失効、アカウントの有効化または無効化、ユーザーの有効化または無効化、およびユーザーのバルク変更が含まれます。
Oracle Identity Managerには、事前に定義された一連のリクエスト・タイプがあります。表9-3に、カタログベース以外のリクエストに対してOracle Identity Managerがデフォルトでサポートしている操作およびリクエスト・モデルを示します。
表9-3 カタログベース以外のリクエストに対するデフォルトの操作およびリクエスト・タイプ
| カテゴリ | リクエスト・タイプ | バルク | 受益者 |
|---|---|---|---|
|
ユーザー管理 |
ユーザーの作成 |
N |
N |
|
ユーザーの自己登録 |
N |
N |
|
|
ユーザー・プロファイルの変更 |
Y |
N |
|
|
ユーザーの有効化 |
Y |
N |
|
|
ユーザーの無効化 |
Y |
N |
|
|
ユーザーの削除 |
Y |
N |
|
|
プロビジョニング |
アカウントの変更 |
Y |
Y |
|
アカウントの有効化 |
Y |
Y |
|
|
アカウントの無効化 |
Y |
Y |
|
|
アカウントの失効 |
Y |
Y |
|
|
ロール管理 |
ロールの作成 |
N |
N |
|
ロールの削除 |
Y |
N |
|
|
ロールの変更 |
Y |
N |
|
|
ロールの割当て |
Y |
Y |
|
|
ロールからの削除 |
Y |
Y |
|
注意: 次のリクエスト・タイプは、現在のリリースでは非推奨になっています。
新しいリクエストは、これらの非推奨になったリクエスト・タイプに基づいて作成することはできません。 |
依存エンティティは、リクエスト可能エンティティであり、そのプロビジョニングは、Oracle Identity Managerおよびターゲット・システムのユーザーにプロビジョニングされた別のエンティティ(親エンティティ)に依存します。たとえば、ユーザーへの権限の付与は、そのユーザーにプロビジョニングされたアカウントに依存します。この場合は、権限が依存エンティティ、アカウントが独立したエンティティとなります。
依存リクエストは、別のリクエストに依存するリクエストです。依存リクエストは、独立したリクエストが処理されている間はその独立したリクエストを待ちます。依存リクエストの処理は、独立したリクエストの完了後に再開されます。
リクエストの依存性は、システムで内部的に設定されます。たとえば、ユーザーが権限E1をリクエストしようとすると、アプリケーション・インスタンスA1がカートに自動的に追加され、カート・レベルの依存性が設定されます。リクエストが送信されると、バルク・リクエストが作成されます。リクエスト・レベルの承認が承認された後は、アカウント用と権限用の2つの子リクエストが生成されます。権限リクエストは、アカウント・リクエストに依存するようOracle Identity Managerによって内部的に設定されます。
次のシナリオでは、リクエストにおける権限とアカウント間の依存性について詳しく説明します。
アプリケーション・インスタンスにプロビジョニングされているアカウントがない受益者の権限をユーザーがリクエストする場合は、アプリケーション・インスタンスがカートに自動的に追加されます。アカウントのプロビジョニングに成功した場合のみ権限が付与されます。リクエストの依存性は、次のフローチャートに示すとおりに処理されます。
このシナリオでは、次のようになります。
ユーザーは、リクエストを使用して権限のアカウント・データを指定することにより、アカウントを作成します。
リクエストされた権限がアカウントのものと同じアプリケーション・インスタンスにある場合は、アプリケーション・インスタンスがカート(リクエスト)に自動的に追加されます。
リクエストされた1つまたは複数の権限がアカウントのものとは異なるアプリケーション・インスタンスにある場合は、アプリケーション・インスタンスがそれぞれカート(リクエスト)に自動的に追加されます。
ユーザーは、これらの自動追加された項目をカートから削除できません。
受益者にプロビジョニングされたアカウントの数に応じて、リクエストは次のように処理されます。
アプリケーション・インスタンスにプロビジョニングされているアカウントを1つ所有する受益者の権限をユーザーがリクエストする場合は、権限がアカウントに自動的に付与されます。
同一または複数のアプリケーション・インスタンスにプロビジョニングされている複数のアカウントを持つ受益者の権限をユーザーがリクエストする場合は次のようになります。
選択されたアカウントのものと同じアプリケーション・インスタンスに定義された権限のみがリクエスト・カタログに表示されます。
ユーザーは、権限の付与が必要なアカウントを選択できます。
リクエストに複数の権限がある場合、ユーザーは、それぞれの権限に対して権限の付与が必要なアカウントを選択できます。
リクエスタは、当該のリクエストに他の受益者を追加することはできません。
複数の受益者にプロビジョニングされたアカウントの数に応じて、リクエストの依存性は次のように処理されます。
リクエストされた1つまたは複数の権限に対してすべての受益者が1つのアカウントを所有している場合は、ユーザーによるリクエストの送信が可能です。
リクエストされた1つまたは複数の権限に対して1人または複数の受益者がゼロまたは複数のアカウントを所有している場合は、リクエスト内の1人または複数の受益者のアカウント情報が一意に特定できないという内容の警告がユーザーに表示されます。その後に、ユーザーによるリクエストの送信が可能になります。
ゼロまたは複数のアカウントを持つ1人または複数の受益者に対してバルク・リクエストが作成されるときは、リクエスト・レベルの承認後に子リクエストが作成されます。
アカウントがない場合の受益者と権限の組合せでは、Oracle Identity Managerにより、権限リクエスタと同様のリクエスタを使用したアカウント・リクエストの作成が行われます。権限リクエストは、新しく作成されたアカウント・リクエストに依存するように設定されます。アカウント・リクエストのリクエスタには、アカウント・フォーム・データを指定するための「情報の指定」という新規タスク(受信ボックスからアクセス可能)が割り当てられます。
複数のアカウントを持つ場合の受益者と権限の組合せでは、権限のプロビジョニングが必要なアカウントを検索し、選択するための「情報の指定」という新規タスク(受信ボックスからアクセス可能)が権限リクエストのリクエスタに割り当てられます。
受益者または権限の追加/削除など、カート項目レベルでのリクエストにおいて変更があるときは常にリクエスト(カート)内の依存性が再評価されます。次にいくつかのシナリオを示します。
1人の受益者を持つカートに受益者が追加された場合は、「複数のアカウントを持つ複数の受益者」で説明しているリクエストの依存性が適用されます。
ユーザーに事前警告が表示された後は、次のアクションが実行されます。
カートに自動的に追加されたアプリケーション・インスタンスが削除されます。
カート・レベルの依存性が削除されます。
権限に対して選択されたアカウントを含めて、ユーザーが追加したアカウント関連情報が削除されます。
カートから受益者が削除された後にまだ複数の受益者がカートに含まれている場合は、どのアクションも実行されません。「複数のアカウントを持つ複数の受益者」で説明しているリクエストの依存性が適用されます。
カートから受益者が削除された後に1人の受益者がカートに含まれている場合は、カートが再評価されます。「アカウントがない受益者」および「1つまたは複数のアカウントを持つ受益者」で説明しているリクエストの依存性が適用されます。
複数の受益者を持つカートに権限が追加された場合は、どのアクションも実行されません。「複数のアカウントを持つ複数の受益者」で説明しているリクエストの依存性が適用されます。
1人の受益者を持つカートに権限が追加された場合は、「1つまたは複数のアカウントを持つ受益者」で説明しているリクエストの依存性が適用されます。
リクエストに指定されている関連操作の実行に失敗した場合、リクエストは保留中の操作を取り消して「リクエストに失敗しました」ステージに移動します。「リクエストに失敗しました」ハイパーリンクをクリックすると、リクエスト失敗の理由が表示されます。
リクエストの失敗には、次のいずれかの理由が考えられます。
ロールをリクエストしている場合、職務分掌違反によりリクエストが失敗する可能性があります。
アプリケーション・インスタンスをリクエストしており、そのアプリケーション・インスタンスが別のアプリケーション・インスタンスに依存する場合、親アプリケーション・インスタンスがプロビジョニングされていないため、リクエストは「承認済リクエスト履行が保留中です」ステータスに進みます。たとえば、ユーザーにMicrosoft Exchangeアカウントを正常にプロビジョニングするためには、ユーザーは、Exchange Serverのユーザーを管理しているドメイン・コントローラでMicrosoft Active Directoryアカウントを所有している必要があります。
前述の理由の他に、誤ったパスワード、パスワード・ポリシー違反、ターゲット・システムが使用不可能であるなどの理由で、失敗することがあります。
リクエストのためのカタログ項目を選択すると、その項目はリクエスト・カートに追加されます。リクエスト・カートは、顧客に製品を販売するWebサイトのショッピング・カートに似ています。カートの選択した項目を表示したり、リクエスト・カートを編集して項目を追加または削除することができます。
リクエスト・プロファイルとは、ユーザーが今後再利用するために保存されるリクエスト・カートのことです。ユーザーが何千ものカタログ項目を検索せずに、リクエスト・カートを使用してエンティティのリクエストができるように、リクエスト・カートはカタログ管理者またはシステム管理者によって保存されます。
|
注意: ユーザーがリクエスト・プロファイルを使用してリクエストを作成する場合、項目は認可ポリシーに基づいてフィルタされます。つまり、ユーザーがリクエストに必要な権限を持っていない項目がカートから自動的に削除されます。ユーザーにプロファイルのどの項目もリクエストする権限がない場合は、カート項目は空になります。 |
このセクションのトピックは次のとおりです:
|
注意: リクエスト・プロファイルの作成、変更または削除を実行できるのは、カタログ管理者またはシステム管理者のみです。 |
リクエスト・プロファイルを作成する手順は、次のとおりです。
「カタログ」ページで1つ以上のカタログ項目を選択し、「カートに追加」をクリックします。カタログ項目がリクエスト・カートに追加されます。
「チェックアウト」をクリックします。「カート詳細」ページが表示されます。選択したカタログ項目が「カート項目」セクションに表示されます。
「プロファイルとして保存」をクリックします。「カートのリクエスト」ダイアログ・ボックスが表示され、リクエスト・プロファイルのカタログ項目が表示されます。
「プロファイル名の保存」フィールドに、リクエスト・プロファイルの名前を入力します。
「説明」フィールドに、リクエスト・プロファイルの説明を入力します。
「保存」をクリックします。リクエスト・プロファイルが作成されます。
リクエスト・プロファイルを変更する手順は、次のとおりです。
「カタログ」ページの「リクエスト・プロファイル」セクションで、変更するリクエスト・プロファイルをクリックします。「カート詳細」ページが表示されます。
「カート項目」セクションで、項目の詳細を表示するカート項目を選択します。
「詳細」セクションで、必要に応じて、リクエストの詳細を変更します。これを行うには、「詳細」セクションで値を設定または変更し、「送信準備ができています」をクリックします。
カートにさらに項目を追加する手順は、次のとおりです。
「カタログに戻る」をクリックします。
「カタログ」ページで、カートに追加する項目を検索して選択し、「カートに追加」をクリックします。
「チェックアウト」をクリックします。「カート詳細」ページが表示されます。
「プロファイルとして保存」をクリックします。「プロファイルとして保存」ダイアログ・ボックスが表示されます。
「プロファイル名の保存」フィールドに、変更するリクエスト・プロファイルの名前を入力します。新しい名前を入力すると、新しいリクエスト・プロファイルが作成されます。既存のリクエスト・プロファイルの名前を入力した場合は、そのリクエスト・プロファイルが最近の変更で更新されます。
「説明」フィールドに、リクエスト・プロファイルの説明を入力します。
「保存」をクリックします。既存のリクエスト・プロファイルの名前を入力したのか新しい名前を入力したのかによって、リクエスト・プロファイルはそれぞれ作成または更新されます。
|
注意: 「ターゲット・ユーザー」、「理由」または「有効日」に追加または指定した値は、リクエスト・プロファイルに保存されません。 |
この項では、次のトピックでリクエストの作成方法について説明します。
Identity Self Serviceのログイン・ページを使用して、Oracle Identity Managerに自身を登録するリクエストを作成できます。これは、自己登録リクエストと呼ばれ、Oracle Identity Managerに存在しないユーザー(匿名ユーザー)が要求できます。自己登録リクエストを作成するには、「登録リクエストの送信」を参照してください。自己登録リクエストの送信後、ログイン・ページに移動し、「自分の登録のトラッキング」をクリックすることでトラッキングできます。
|
注意: この項で説明した手順は、ロール、権限およびアプリケーション・インスタンスのリクエストに適用されます。 |
「アイデンティティ・セルフ・サービス」では、「ホーム」ページ、「マイ・アクセス」ページ、ユーザーおよびロールのエンティティ詳細ページなどの様々なページからリクエストを作成することができます。リクエストを作成しているページまたはタブに関係なく、リクエスト・カタログを使用してリクエストを作成します。
リクエスト・カタログを使用してリクエストを作成する手順は、次のとおりです。
Identity Self Serviceにログインします。
「リクエスト」で、「カタログ」をクリックします。「カタログ」ページが表示されます。
リクエストする項目を検索します。これを行うには、「検索」フィールドにキーワードを入力し、右側の「検索」アイコンをクリックします。検索結果が表示されます。図9-4に示すように、検索条件に一致するカタログ項目が「カタログ項目」セクションに表示されます。
「検索の絞込み」セクションで、1つ以上のカテゴリを選択して、それらのカテゴリのカタログ項目を表示します。「すべて選択」をクリックして、カテゴリに属するすべての項目を表示または非表示にします。
リクエストするカタログ項目を選択します。情報アイコンをクリックして、ポップアップ・ウィンドウでカタログ項目の詳細情報を表示できます。
また、[Ctrl]を押しながら項目をクリックすると、複数の項目を選択できます。
「選択した項目をカートに追加」をクリックします。
選択した項目がリクエスト・カートに追加されます。また「カートに追加」をクリックすることによっても、項目を1つずつ追加できます。
「リクエスト対象」領域で、作成されたリクエストの対象者に応じて「自分」または「その他」を選択します。
必要に応じて、「編集」をクリックして、カートに追加されたカタログ項目を表示します。図9-5に示すように、「カートのリクエスト」ダイアログ・ボックスが表示され、カートのカタログ項目のリストが表示されます。
必要に応じて、カタログ項目を選択してその項目に関する詳細情報を表示します。詳細情報を確認し、カートから項目を削除する場合は、対応する項目の「削除」をクリックします。
または、「すべて削除」をクリックして、カートからすべての項目を削除します。
「チェックアウト」をクリックします。または、「カタログ」ページで「チェックアウト」をクリックします。
図9-6に示すように、「カート詳細」ページが表示されます。
「ターゲット・ユーザー」セクションには、リクエストの受益者のユーザー名が表示されます。ユーザーの「ユーザーの詳細」アイコンをクリックすると、ユーザーの詳細が表示されます。
リクエストに受益者を追加する手順は、次のとおりです。
緑色の「+」記号をクリックします。「ターゲット・ユーザーの拡張検索」ダイアログ・ボックスが表示されます。
追加する1人以上のユーザーを検索して選択します。
選択したユーザーを「選択したユーザー」リストに追加するには、「選択した項目の追加」をクリックします。または、「すべて追加」をクリックして、すべてのユーザーを「選択したユーザー」リストに追加します。
「追加」をクリックします。選択したユーザーまたは受益者が、「カート詳細のリクエスト」ページの「ターゲット・ユーザー」セクションに追加されます。
また、受益者のリストから削除するユーザーを選択して、十字アイコンをクリックすることもできます。
必要に応じて、「理由」および「有効日」セクションで、理由とリクエストがアクティブになる有効日を各フィールドで指定します。
必要に応じて、「カート項目」セクションでカート項目を選択し、「詳細」をクリックして項目の詳細を表示します。
必要に応じて、カート項目を選択して「削除」をクリックし、リクエストからのアカウントを削除します。
カートの各項目について詳細を確認および変更した後で、「下書きとして保存」をクリックして後で使用するためにリクエストを保存でき、あるいは「送信」をクリックしてリクエストを送信できます。
「送信」ボタンがアクティブでない場合、「送信準備ができていません」ステータスの各リクエストの「送信準備ができています」をクリックします。リクエストが承認のために送信され、「リクエスト・サマリー」ページが表示され、サマリー情報、ターゲット・ユーザーまたは受益者情報、およびリクエストと承認の詳細が表示されます。図9-7は、「リクエスト・サマリー」ページを示しています。
|
注意: 「リクエスト・サマリー」ページで、実行フェーズが開始される前にリクエストを取り消す場合は、「リクエストの取消し」をクリックし、「はい」をクリックして確認します。「アイデンティティ・セルフ・サービス」の他のページからリクエストを取り消す場合は、「リクエストの取消し」を参照してください。 図9-7では、すでに実行フェーズが開始されているため、リクエストを取り消すオプションがありません。このステージでは、リクエストをクローズすることしかできません。詳細は、「リクエストのクローズ」を参照してください。 |
リクエスト・プロファイルを使用してリクエストを作成する手順は、次のとおりです。
「アイデンティティ・セルフ・サービス」の「リクエスト」の「カタログ」をクリックします。「カタログ」ページが表示され、自身に作成されたリクエスト・プロファイルが表示されます。
リクエストの作成に使用するリクエスト・プロファイル名をクリックします。「カート詳細」ページが表示されます。
「ターゲット・ユーザー」セクションには、リクエストの受益者のユーザー名が表示されます。各ユーザーに対する情報アイコンをクリックすると、詳細が表示されます。
リクエストに受益者を追加する手順は、次のとおりです。
「追加」アイコンをクリックします。「ターゲット・ユーザーの拡張検索」ダイアログ・ボックスが表示されます。
追加する1人以上のユーザーを検索して選択します。
選択したユーザーを「選択したユーザー」リストに追加するには、「選択した項目の追加」をクリックします。または、「すべて追加」をクリックして、すべてのユーザーを「選択したユーザー」リストに追加します。
「追加」をクリックします。選択したユーザーまたは受益者が、「カート詳細のリクエスト」ページの「ユーザー」セクションに追加されます。
また、受益者のリストから削除するユーザーを選択して、「削除」アイコンをクリックすることもできます。
必要に応じて、「理由」および「有効日」セクションで、理由とリクエストがアクティブになる有効日を各フィールドで指定します。
「カート項目」セクションで、項目の詳細を表示するカート項目を選択します。
カート内の各リクエストの詳細を確認および変更した後、「送信」をクリックします。「送信」ボタンがアクティブでない場合、「送信準備ができていません」ステータスの各カート項目の「送信準備ができています」をクリックします。
リクエストが承認のために送信され、「リクエスト・サマリー」ページが表示され、サマリー情報、ターゲット・ユーザーまたは受益者情報、およびリクエストと承認の詳細が表示されます。
リクエストをトラッキングする手順は、次のとおりです。
「アイデンティティ・セルフ・サービス」の「リクエスト」の「リクエストのトラッキング」をクリックします。「リクエストのトラッキング」ページが表示されます。
トラッキングするリクエストを検索します。手順は次のとおりです。
次のいずれかを選択します。
すべて: このオプションを選択すると、検索はAND条件で実行されます。つまり、検索操作によって、指定されたすべての検索基準に一致するリクエストが返されます。
いずれか: このオプションを選択すると、検索はOR条件で実行されます。つまり、検索操作によって、指定された検索基準のいずれかに一致するリクエストが返されます。
「リクエストID」などの検索可能なリクエスト属性フィールドで、値を指定します。属性値にはワイルドカード文字(*)を含めることができます。
一部の属性については、「参照」から属性値を選択します。たとえば、「ステータス」リストから「操作承認を取得しています」ステータスを持つすべてのリクエストを検索するには、「次と等しい」検索演算子を選択し、横にあるリストから「操作承認を取得しています」を選択します。
指定した各属性値に対して、リストから検索演算子を選択します。たとえば、「リクエストID」で次の検索演算子を使用できます。
次で始まる
次で終わる
次と等しい
次と等しくない
次を含む
次を含まない
他のフィールドについては(例: 「ステータス」、「リクエスト・タイプ」、「受益者」および「リクエスタ」)、「次と等しい」および「次と等しくない」演算子のみが利用できます。
日付タイプのフィールドの検索演算子は、次のとおりです。
次と等しい
次と等しくない
次より前
次より後
それ以前
それ以後
検索可能なリクエスト属性を「リクエストのトラッキング」ページに追加するには、「フィールドの追加」をクリックして、属性のリストから属性を選択します。
たとえば、リクエスタによってすべてのリクエストをトラッキングする場合は、「リクエスタ」属性を検索可能なフィールドとして追加し、検索条件を指定できます。
必要に応じて、「リセット」をクリックし、指定した検索条件をリセットします。通常、この手順を実行すると、指定した検索条件を削除し、新しい検索条件を指定します。
「検索」をクリックします。検索結果が表形式で表示されます。
実行したリクエスト検索で多数のレコードが表示される場合は、リクエスト検索結果をフィルタ処理できます。手順は次のとおりです。
「表示」リストから、次のいずれかを選択します。
自分で要求したリクエスト: デフォルトで選択されています。ログイン・ユーザーによって作成されたリクエストが返されます。
自分に対して要求されたリクエスト: ログインしたユーザーが受益者またはターゲット・ユーザーとして存在するリクエストが返されます。
Reporteeに対して: このオプションを使用できるのは、ログイン・ユーザーがユーザーのマネージャである場合です。
ユーザーに対して: このオプションを使用できるのは、ログイン・ユーザーにユーザー管理者ロールまたはヘルプデスク管理ロールが付与されている場合です。
すべて: 検索結果のすべてのリクエストが返されます。このオプションを使用できるのは、ログイン・ユーザーに「システム管理者」ロールが付与されている場合です。
「リクエストID」または「ステータス」などのいずれかの列で検索結果のリクエストをソートするには、列で「昇順ソート」または「降順ソート」矢印をクリックします。検索結果のリクエストは、選択した列でソートされます。
リクエスト検索結果で、リクエストをクリックして、リクエストの詳細を表示します。リクエストの詳細が、次の情報を含むページに表示されます。
サマリー情報: このセクションには、リクエストID、リクエスト・ステータス、有効日などの一般的なリクエストの詳細が表示されます。
ターゲット・ユーザー: このセクションには、リクエストの受益者またはターゲット・ユーザーが表示されます。
関連リクエスト: このセクションには、オープン・リクエスト(ある場合)に関連するリクエストが表示されます。
リクエストの詳細: このタブには、リクエストされたカタログ項目が表示されます。項目を選択すると、その項目のサマリー情報が表示されます。
承認の詳細: このタブには、リクエストが割当てられている各承認者による、リクエスト承認のステータスが表示されます。
|
注意: HelpDeskユーザーおよび受益者は、リクエスト承認の詳細を確認できます。ただし、リクエスト・サマリー・ページにコメントまたは添付ファイルを追加することはできません。 |
リクエスタは、リクエストを将来の変更、送信または削除用に保存できます。これは、リクエスタがリクエストの送信前に追加情報を待っている場合に役に立ちます。
下書きリクエストの変更、送信または削除ができるのはリクエスタのみです。他のユーザーが保存した下書きリクエストをシステム管理者や受益者などのユーザーが表示することはできません。
下書きリクエストをトラッキングする手順は次のとおりです。
「アイデンティティ・セルフ・サービス」の「リクエスト」の「リクエストのトラッキング」をクリックします。「リクエストのトラッキング」ページが表示されます。
「ステータス」リストから「次と等しい」検索演算子を選択し、隣のリストから「リクエストの下書きが作成されました」を選択します。
「検索結果」リージョンの「表示」リストから、「自分で要求したリクエスト」フィルタを選択します。
(オプション)「リクエストのトラッキング」で説明しているその他の検索基準を使用します。
「検索」をクリックします。検索結果が表形式で表示されます。
下書きリクエストの取消しまたはクローズはできません。下書きリクエストを削除するには、リクエストを選択して「リクエストの削除」をクリックします。
下書きリクエストを開いて変更または送信を行うには、「リクエストID」列のリンクをクリックします。「下書きリクエストの編集」ページで、「送信」をクリックすると下書きリクエストを送信できます。「送信」ボタンがアクティブでない場合は、「カート項目」リージョンでカート項目をそれぞれ選択および編集し、「送信準備ができています」をクリックします。リクエスト・データを変更および保存するには、「下書きリクエストの更新」をクリックします。
下書きリクエストが管理者または認可者によって送信されたときは、下書きリクエストが直接承認されません。標準のリクエスト・フローのとおり、リクエスト・レベルは開始済、操作レベルは自動承認となります。
|
注意: 下書きモードで保存されたリクエスト・データにはパスワードなどの機密情報を含めないでください。たとえそれらがリクエストを下書きとして保存する前に入力したものであっても同様です。 |
リクエスタはリクエストを取り消すことができますが、取り消すことができるのは実行フェーズが開始されていないリクエストのみです。また、受益者はリクエストを取り消すことができません。取り消すことができるのは、次のステージにあるリクエストです。
承認の取得
承認
|
注意: 承認されたリクエストは、そのリクエストが「リクエストが完了待ちです」ステータスにある場合を除きクローズできません。 下書きリクエストが「リクエストの下書きが作成されました」ステータスの場合は取り消すことができません。 |
リクエストを取り消す手順は、次のとおりです。
「アイデンティティ・セルフ・サービス」の「リクエスト」の「リクエストのトラッキング」をクリックします。「リクエストのトラッキング」ページが表示されます。
取り消すリクエストを検索します。検索結果には、各リクエストに「リクエストの取消し」ボタンを含む、検索基準に一致するリクエストのリストが表示されます。
取り消すリクエストに対して、「リクエストの取消し」をクリックします。または、リクエストIDをクリックしてリクエストの詳細を開いてから、「リクエストの詳細」ページで、「リクエストの取消し」をクリックします。
確認メッセージ・ボックスで「はい」をクリックします。リクエストが取り消され、リクエストの受益者およびリクエスタに通知が送信されます。取消しが成功した場合、リクエストは「リクエストが取り消されました」ステージに移動します。リクエストに関連付けられている保留中の承認タスクは取り消されます。
|
注意:
|
管理者は、実行フェーズを開始していないリクエストを途中でクローズできます。これには、承認を待機しているすべてのリクエスト、または承認を完了しているが操作を開始していないすべてのリクエストが含まれます。次の状態のリクエストをクローズできます。
承認の取得
承認
|
注意:
|
リクエストをクローズする手順は、次のとおりです。
「アイデンティティ・セルフ・サービス」の「リクエスト」の「リクエストのトラッキング」をクリックします。「リクエストのトラッキング」ページが表示されます。
クローズするリクエストを検索します。検索条件に一致するリクエストが、表形式で表示されます。
クローズするリクエストを選択します。
「アクション」メニューから「リクエストのクローズ」を選択します。または、ツールバーにある「リクエストのクローズ」アイコンをクリックします。
確認メッセージ・ボックスで「はい」をクリックします。リクエストがクローズされ、このリクエストのリクエスタとターゲット・ユーザーに通知が送信されます。リクエストが正常にクローズされると、リクエストは「リクエストがクローズされました」ステージに移動します。
|
注意:
|
