| Oracle® Fusion Middleware Oracle Identity Manager管理者ガイド 11g リリース2 (11.1.2) B69535-02 |
|
 前 |
 次 |
アプリケーション・インスタンスは、11g リリース2 (11.1.2)で使用される新しい抽象化です。これは、ITリソース・インスタンス(ターゲットの接続性とコネクタ構成)およびリソース・オブジェクト(プロビジョニング・メカニズム)の組合せです。
R2リリースより前では、リクエストの作成はリソースの名前に基づいて管理者中心で行われ、テクノロジについての詳しい知識が必要でした。11g リリース2 (11.1.2)では、ユーザーのアカウントと権限は、ITリソース・インスタンスやリソース・オブジェクトではなく、アプリケーション・インスタンスに関連付けられるようになりました。これにより、エンド・ユーザーはより簡単に操作できるようになります。
アプリケーション・インスタンスは組織に公開され、その組織のユーザーがリクエストできます。Microsoft Active Directory (AD)が、全世界の様々な組織または部門に属するユーザーにプロビジョニングされるとします。次のもので構成されるアプリケーション・インスタンスを定義できます。
AD (リソース・オブジェクト)
URLおよびパスワードなどの接続情報を含む各ADサーバー・インスタンス(IT リソース)
リソース・オブジェクトは全ユーザーに対して同じですが、ポート番号などの接続情報は、異なる組織に属するユーザーでは異なる場合があるため、このような構成になります。これにより、ユーザーが接続情報を知らなくても、ADリソース・オブジェクトをアプリケーション・インスタンスとしてプロビジョニングできます。
アプリケーション・インスタンスは、プロビジョニング可能なエンティティです。特定のターゲット内にあるアカウントを取得するには、エンド・ユーザーがアプリケーション・インスタンスをリクエストする必要があります。エンド・ユーザーは、リソースをリクエストし、それとは別にITリソース・インスタンスを構成するかわりに、アプリケーション・インスタンスをリクエストできます。リクエストは、承認者による承認が必要です。リクエストが承認されると、ユーザーにリソースがプロビジョニングされ、ターゲット・システムにアカウントが作成されます。
|
注意: 管理者からのリクエストには承認が不要の場合がありますが、エンド・ユーザーからのリクエストには承認者による承認が必要です。 |
この章では、次のトピックでアプリケーション・インスタンスについて説明します。
アプリケーション・インスタンスはプロビジョニング可能なエンティティであり、カタログに公開されます。11g リリース2 (11.1.2)では、アプリケーション・インスタンス、権限およびロールを付与するカタログベースのリクエストを作成する機能が提供されます。アーキテクチャには、プロビジョニング・モジュールでアプリケーション・インスタンスおよび権限のリクエストをサポートするために必要な機能拡張が含まれます。図8-1に、アプリケーション・インスタンスのアーキテクチャを示します。
アプリケーション・インスタンスの概念については、次の各項で説明します。
企業内のユーザーは、1つのアプリケーション・インスタンスに対して複数のアカウントを持つことができます。これは、HR管理者が、管理アカウントを使用して組織の他の従業員のための様々なタスクを実行するようなシナリオで必要です。同じHR管理者が、自身のための特定のタスクを実行する場合には、別のユーザー・アカウントを使用してログインします。この例では、同じユーザーに、システムにログインして異なる種類の操作を行うための2つの異なるアカウントが必要です。
さらに、潜在的なセキュリティ上の脅威を防ぐためにも、ユーザーが複数アカウントを使用できるようにする必要があります。たとえば、あるユーザーが同じアカウントを使用して環境にログインし、管理タスク、自分自身と他のユーザーの標準ビジネス・タスクおよびITインフラストラクチャ関連タスクを実行するとします。システムに侵入されアカウントがハッキングされた場合、ハッカーはインフラストラクチャのデータおよびその他の機密情報にアクセスできます。ユーザーがタスクの種類ごとに異なる複数のアカウントを持っており、標準アカウントがハッキングされた場合は、ITインフラストラクチャに関する機密情報およびその他の重要なリソースはハッカーから守られます。
Oracle Identity Managerでは、1つのアプリケーション・インスタンスにおける複数アカウントの使用がサポートされます。作成される最初のアカウントはプライマリ・アカウントとしてタグが付けられ、1人のユーザーに対して作成できるプライマリ・アカウントは1つのみです。同じアプリケーション・インスタンス上に作成された後続アカウントは「その他」のタグが付与されます。ユーザーが権限をリクエストすると、プライマリ・アカウントに権限が追加されます。
ユーザーがアプリケーション・インスタンスに対してプロビジョニングされると、Oracle Identity Managerにより、それがそのアプリケーション・インスタンスでそのユーザーに対してプロビジョニングされる最初のアカウントであるかどうかがチェックされます。最初のアカウントである場合、そのアカウントは「プライマリ」とマークされます。アプリケーション・インスタンスから既存のユーザー・アカウントがリコンサイルされる場合、リコンサイルされる最初のアカウントは「プライマリ」とマークされます。「プライマリ」とマークされたアカウントが実際のプライマリ・アカウントではない場合、手動でそのアカウントの「プライマリ」タグを変更して、別のアカウントを「プライマリ」とマークできます。
ターゲット・システムのアカウントに付与される権限により、アカウント所有者(ユーザー)は特定のタスクや機能を実行できます。権限は、ロール、職責またはグループ・メンバーシップの場合があります。たとえば、ユーザーRichardがターゲット・システムでInventory Analystロールを付与されている場合、Richardはその権限を使用してターゲット・システムの在庫関連レポートにアクセスし、生成できます。
Oracle Identity Managerでは、OIMユーザーにプロビジョニングされるアカウント(リソース)ごとに1つのプロセス・フォームがあります。権限データは、子プロセス・フォームに格納されます。前述の例では、ターゲット・システムのRichardのアカウントのプロセス・フォームには、Inventory Managerロール・データを保持する子プロセス・フォームがあります。
|
注意: ターゲット・システムで作成された権限をOracle Identity Managerにリコンシリエーションするには、最初に参照フィールド同期のスケジュール済ジョブを実行してから、権限リスト・スケジュール済ジョブを実行する必要があります。 |
子プロセス・フォームに格納される権限データを構成する属性は、ターゲット・システムによって異なる可能性があります。また、ロールと職責などの異なるタイプの権限は、異なる属性を持つ場合があります。
管理アカウントに関連付ける必要がある権限は、管理アカウントにおけるリソースの変更をリクエストすることによりプロビジョニングされます。管理者は、ユーザーのリソース(アカウント)プロファイルから管理アカウントの変更をリクエストし、このアカウントの子表へ管理権限を追加でき、これによってこの権限が該当する管理アカウントにプロビジョニングされます。権限は権限のリクエストを使用してリクエストすることもできます。
あらゆる種類の権限をリクエスト・カタログでリクエストできます。管理権限のリクエストが承認されると、管理アカウントではなくプライマリ・アカウントに管理権限が関連付けられます。
Oracle Identity System Administrationの「アプリケーション・インスタンス」セクションを使用して、権限を編集できます。
権限の詳細は、「権限の開発」を参照してください。
Oracle Identity Managerにおけるセルフ・サービス、委任管理、リクエスト管理およびロールベースのプロビジョニング機能はデプロイできますが、プロビジョニングを自動化するためのプロビジョニングおよびリコンシリエーション・コネクタはデプロイできません。委任管理操作、リクエストの承認またはロールベースのプロビジョニングが完了すると、手動のプロビジョニング・タスクが管理者に割り当てられます。続けて管理者は、ターゲットのアプリケーション・インスタンスで、プロビジョニングを手動で実行します。この例には、物理アクセス・カードのプロビジョニングがあります。Oracle Identity Managerでは物理アクセス・カードをプロビジョニングできないため、接続なしリソースのアプリケーション・インスタンスがプロビジョニングされます。
Oracle Identity Managerでは、接続なしリソースの手動プロビジョニング用のSOAワークリストを使用して、接続なしリソースのプロビジョニングをサポートします。ロールベースのプロビジョニングの決定またはSOAリクエストの承認が完了し、対応するアプリケーション・インスタンスが接続なしアプリケーション・インスタンスであると判別されると、新しいSOAワークフローが開始されます。この新しいSOAワークフローは、手動プロビジョニング管理者に割り当てられます。
接続なしリソースのプロビジョニングを行うために、接続なしタイプのアプリケーション・インスタンスを作成できます。手動プロビジョニング管理者は、Oracle Identity Self Serviceの「保留中の承認」セクションを使用して、リクエストの全フィールドを更新できます。手動プロビジョニング管理者が手動プロビジョニング・ワークリスト項目を送信すると、手動プロビジョニング管理者の応答に基づいて、プロビジョニング・インフラストラクチャにより基礎となるプロビジョニング・タスクに「完了」のマークが付けられます。管理者がそのタスクが手動で完了されたことを示すと、ステータスがプロビジョニング済に変更されます。
アプリケーション・インスタンスは、組織の公開メカニズムによってセキュリティ・プリミティブが関連付けられたエンティティでもあります。マルチテナント環境では、複数の組織によりリソース定義を共有できますが、実際にターゲットにプロビジョニングできるのは、そのうちアプリケーション・インスタンスが公開されている組織のみです。
Oracle Identity System Administrationを使用してアプリケーション・インスタンスを管理します。次のものが含まれます。
|
関連項目: 接続なしアプリケーション・インスタンスから接続アプリケーション・インスタンスへの変換の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の接続なしアプリケーション・インスタンスから接続アプリケーション・インスタンスへの変換に関する説明を参照してください。 |
アプリケーション・インスタンスを作成するには:
Oracle Identity System Administrationにログインします。
左ペインの「構成」で、「アプリケーション・インスタンス」をクリックします。「アプリケーション・インスタンス」ページが表示されます。
「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「アプリケーション・インスタンスの作成」ページが表示されます。
表8-1に示すように属性の値を入力します。
表8-1 「アプリケーション・インスタンスの作成」ページのフィールド
| 属性 | 説明 |
|---|---|
|
名前 |
アプリケーション・インスタンスの名前。これは必須フィールドです。 注意: ASCIIでない文字を「名前」フィールドに入力した場合、アプリケーション・インスタンスを保存しようとすると、エラー・メッセージが表示されます。「名前」フィールドにASCIIまたは英数字の文字列のみを入力することをお薦めします。 |
|
表示名 |
アプリケーション・インスタンスの表示名。これは必須フィールドです。 |
|
説明 |
アプリケーション・インスタンスの説明。 |
|
切断 |
アプリケーション・インスタンスを接続なしとして指定する場合に選択します。このオプションを選択すると、手動プロビジョニング管理者に割り当てられる新しい承認プロセスが作成されます。詳細は、「接続なしアプリケーション・インスタンス」を参照してください。 注意: 接続なしアプリケーション・インスタンスは、サンドボックスがアクティブな場合にのみ作成できます。サンドボックスの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のサンドボックスの管理に関する説明を参照してください。 |
|
リソース・オブジェクト |
リソース・オブジェクト名。このフィールドの隣にある検索アイコンをクリックすると、リソース・オブジェクトを検索して選択できます。 |
|
ITリソース・インスタンス |
ITリソース・インスタンス名。このフィールドの隣にある検索アイコンをクリックすると、ITリソース・インスタンスを検索して選択できます。 |
|
フォーム |
フォームまたはデータセット名を選択します。選択したリソース・オブジェクトに関連付けられているフォームが「フォーム」リストに移入されます。 ここでは、新しいフォームを作成したり、既存のフォームを編集できます。詳細は、「フォームの作成および変更」を参照してください。 |
|
親AppInstance |
新しいアプリケーション・インスタンスの親として指定するアプリケーション・インスタンスの名前。新しいアプリケーション・インスタンスは、親アプリケーション・インスタンスのプロパティをすべて継承します。 |
「保存」をクリックします。アプリケーション・インスタンスが作成され、アプリケーション・インスタンスの詳細がページに表示されます。
アプリケーション・インスタンスを検索するには:
Oracle Identity System Administrationの「構成」で、「アプリケーション・インスタンス」をクリックします。「アプリケーション・インスタンス」ページが表示されます。
次のいずれかを選択します。
すべて: このオプションを選択すると、検索はAND条件で実行されます。つまり、指定されたすべての検索基準を満たす場合のみ検索操作が成功します。
いずれか: このオプションを選択すると、検索はOR条件で実行されます。つまり、指定された選択基準のいずれかに一致する場合に検索操作が成功します。
「表示名」などの、検索可能なアプリケーション・インスタンス属性フィールドで、値を指定します。属性値にはワイルドカード文字(*)を使用できます。
一部の属性では、「参照」から属性値を選択します。たとえば、特定のリソース・オブジェクトを持つアプリケーション・インスタンスをすべて検索するには、「リソース・オブジェクト」フィールドにそのリソース・オブジェクトの名前を指定します。
指定する属性値ごとに、リストから検索演算子を選択します。次の検索演算子から選択できます。
次で始まる
次で終わる
次と等しい
次と等しくない
次を含む
検索演算子とワイルドカード文字を組み合せて、検索条件を指定できます。アスタリスク(*)文字をワイルドカード文字として使用します。
「アプリケーション・インスタンス」ページに検索可能なアプリケーション・インスタンス属性を追加するには、「フィールドの追加」をクリックし、属性のリストから属性を選択します。
たとえば、親アプリケーション・インスタンスの下にあるすべてのアプリケーション・インスタンスを検索するには、「親AppInstance」属性を検索可能なフィールドとして追加し、検索条件を指定します。
オプションで、「リセット」をクリックすると、指定した検索条件がリセットされます。このステップは通常、指定した検索条件を削除して、新しい検索条件を指定する場合に実行します。
「検索」をクリックします。検索結果は、図8-2に示すように表形式で表示されます。
|
ヒント: 例による問合せ機能を使用すると、特定の値に基づいて検索を絞り込めます。詳細は、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』の例による問合せに関する説明を参照してください。 |
アプリケーション・インスタンスを開いて、属性の変更、アプリケーション・インスタンスを使用できる組織の割当てと失効、アプリケーション・インスタンスに関連付けられた権限の編集を行うことができます。これらのタスクについては、次の各項で説明します。
アプリケーション・インスタンスの属性を変更するには:
「アプリケーション・インスタンス」ページで、開くアプリケーション・インスタンスを検索して選択します。
「アクション」メニューで「開く」をクリックします。または、ツールバーにある「開く」をクリックします。アプリケーション・インスタンスの表示名をクリックすることもできます。
アプリケーション・インスタンスの詳細ページが表示されます。
「属性」タブが表示されていることを確認します。変更できないフィールドはグレー表示されています。
「表示名」、「説明」、「フォーム」、「親AppInstance」などのフィールドの値を編集します。
「適用」をクリックします。属性の変更が保存されます。
|
注意: アプリケーション・インスタンスを変更した後、変更された詳細がOracle Identity Self Serviceの「カタログ」ページに反映されているが、ユーザー詳細ページには反映されていない場合、 ユーザー詳細ページを閉じてから再び開きます。更新されたアプリケーション・インスタンス詳細が反映されます。 |
アプリケーション・インスタンスを組織に公開して、アプリケーション・インスタンスのリクエストとそれに続くユーザーへのプロビジョニングを可能にする必要があります。その組織に属するユーザー、その組織でユーザー・ビューア・ロールを持っているユーザーまたはその組織でアプリケーション・インスタンス・ビューア・ロールとユーザー・ビューア・ロールを持っているユーザーが、アプリケーション・インスタンスをリクエストできます。Oracle Identity Managerにおける認可の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。
アプリケーション・インスタンスの詳細ページの「組織」タブでは、組織へのアプリケーション・インスタンスの公開とアプリケーション・インスタンスからの組織の失効を行うことができます。
また、アプリケーション・インスタンスを組織とその下位組織に公開して、下位組織のユーザーもアプリケーション・インスタンスをリクエストできるようにすることもできます。権限を持つ組織にアプリケーション・インスタンスを公開して、その組織のユーザーが、権限が関連付けられたアプリケーション・インスタンスをリクエストできるようにすることもできます。
|
注意: 管理者ユーザーは、管理者が表示できるすべての組織にエンティティを公開できます。たとえば、権限管理者は、自身が表示権限を持つすべての組織に対し、管理権限付きの権限を公開できます。 |
この項で説明するタスクは次のとおりです。
アプリケーション・インスタンスを組織に公開するには:
アプリケーション・インスタンスの詳細ページで、「組織」タブをクリックします。開いているアプリケーション・インスタンスの公開先となる組織のリストが表示されます。
各組織について、「階層対応」列に「下位組織を含める」オプションが表示されます。組織とその下位組織が、開いているアプリケーション・インスタンスを使用できるようにする場合に、このオプションを選択します。その組織のみが、開いているアプリケーション・インスタンスを使用できるようにする場合は、このオプションの選択を解除します。
「アクション」メニューで「割当て」をクリックします。または、ツールバーにある「割当て」をクリックします。「組織の選択」ダイアログ・ボックスが表示されます。
開いているアプリケーション・インスタンスの公開先となる組織を検索します。
「選択した項目の追加」をクリックします。選択した組織が「選択した組織」表に追加されます。
すべての組織を選択するには、「すべて追加」をクリックします。
「選択した組織」表に追加された各組織の「階層」列にチェック・ボックスが表示されます。開いているアプリケーション・インスタンスを、選択した組織の下位組織に公開する場合は、この「階層」オプションを選択します。
開いているアプリケーション・インスタンスを、選択した組織のみに公開する場合は、「階層」オプションの選択を解除したままにします。
開いているアプリケーション・インスタンスを、そのアプリケーション・インスタンスに関連付けられた権限を持つ選択された組織に公開するには、「権限に適用」オプションを選択します。それ以外の場合は、このオプションの選択を解除されたままにします。
図8-3に、「階層」および「権限に適用」オプションが示された「組織の選択」ダイアログ・ボックスを示します。
「OK」をクリックします。アプリケーション・インスタンスが選択された組織に公開されます。
「下位組織を含める」オプションは、「組織の選択」ダイアログ・ボックスで「階層」オプションを選択した組織に表示されます。
アプリケーション・インスタンスから組織を失効させるには:
「組織」タブで、開いているアプリケーション・インスタンスから失効させる組織を選択します。
「アクション」メニューから「失効」を選択します。または、ツールバーにある「失効」をクリックします。選択した組織を示す確認ボックスが表示されます。
「はい」をクリックして確認します。アプリケーション・インスタンスから組織が失効されます。
アプリケーション・インスタンスに関連付けられた権限を変更するには:
アプリケーション・インスタンスの詳細ページで、「権限」タブをクリックします。開いているアプリケーション・インスタンスに関連付けられている権限のリストが表示されます。
変更する権限を選択します。
「アクション」メニューから「編集」を選択します。または、ツールバーにある「編集」をクリックします。選択した権限の詳細がページに表示されます。
属性の属性を変更して、「保存」をクリックします。権限の変更が保存されます。
アプリケーション・インスタンスは、次のいずれかの方法で削除できます。
Oracle Identity System Administrationの「アプリケーション・インスタンス」セクションからアプリケーション・インスタンスを削除します。
アプリケーション・インスタンスの構成要素であるITリソースを削除します。
これらのいずれかの方法でアプリケーション・インスタンスを削除した場合、アプリケーション・インスタンスはOracle Identity Managerからハード削除されるわけではありません。アプリケーション・インスタンスはソフト削除されます。これは、そのアプリケーション・インスタンスの結果としてプロビジョニングされたアカウントが、ターゲット・システム内に存在する場合があるためです。そのため、アプリケーション・インスタンスを削除した後で、次の操作を行うためのスケジュール済ジョブを実行する必要があります。
エンティティ・パブリケーションからアプリケーション・インスタンスを非公開にします。
エンティティ・パブリケーションから関連付けられた権限を非公開にします。
アプリケーション・インスタンスのすべてのアカウントを失効させるか、ハード削除するか、削除済としてマークします。
アプリケーション・インスタンスを削除するには:
Oracle Identity System Administrationの「構成」で、「アプリケーション・インスタンス」をクリックします。「アプリケーション・インスタンス」ページが表示され、組織に公開されているアプリケーション・インスタンスのリストが示されます。
削除するアプリケーション・インスタンスを検索して選択します。
「アクション」メニューから「削除」を選択します。または、ツールバーにある「削除」をクリックします。確認を求めるメッセージ・ボックスが表示されます。
「削除」をクリックして確認します。アプリケーション・インスタンスが、Oracle Identity Managerでソフト削除されます。
アプリケーション・インスタンスのITリソースを削除して、そのアプリケーション・インスタンスを削除することもできます。ITリソースの削除の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のITリソースの管理に関する説明を参照してください。
アプリケーション・インスタンスの削除後処理ジョブ・スケジュール済ジョブを実行します。このスケジュール済ジョブは、次のいずれかのモードで実行できます。
失効: アプリケーション・インスタンスは削除されたが、プロビジョニングされたアカウントがまだターゲット・システム内に存在する場合にこのモードを使用します。「失効」モードを使用すると、ターゲット・システムからアカウントが削除されます。
削除: ターゲット・システムが存在せず、Oracle Identity Managerにアカウントの痕跡がない場合にこのモードを使用します。「削除」モードを使用すると、すべてのプロビジョニング・タスクおよびターゲットからアカウントがハード削除され、続けてOracle Identity Managerからもハード削除されます。
廃止: ターゲット・システムが存在せず、プロビジョニングされたアカウントをターゲット・システムから失効させることができない場合にこのモードを使用します。「廃止」モードを使用すると、アカウントのステータスが「失効」に変更され、Oracle Identity Managerでそのアカウントの「プロビジョニング済」状態が解除されます。
スケジュール済ジョブの詳細は、「スケジューラの管理」を参照してください。
|
注意: アプリケーション・インスタンスの削除後処理ジョブ・スケジュール済ジョブは、各アプリケーション・インスタンスの削除後に実行できます。 |
カタログ同期化ジョブ・スケジュール済ジョブを実行します。このスケジュール済ジョブでは、ソフト削除されたアプリケーション・インスタンスを特定し、それらをカタログから削除します。
|
注意:
|
図8-4に、アプリケーション・インスタンスのソフト削除のフローとそれに伴って行われる変更を示します。
Oracle Identity System Administrationの「アプリケーション・インスタンス」セクションで、リソース・オブジェクトに関連付けられ、続けてアプリケーション・インスタンスに関連付けられているフォームを作成および変更できます。
|
関連項目:
|
この項の内容は次のとおりです。
アプリケーション・インスタンスに関連付けられたフォームを作成するには:
|
注意: フォームを直接作成することはできません。フォームを作成する前に、サンドボックスを作成してアクティブ化する必要があります。サンドボックスの作成およびアクティブ化の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のサンドボックスの管理に関する説明を参照してください。 |
「アプリケーション・インスタンスの作成」ページまたはアプリケーション・インスタンスの詳細ページの「属性」タブを開きます。
「フォーム」フィールドの隣の「作成」をクリックします。「フォームの作成」ページが表示されます。
「名前」フィールドで、フォームに関連付けられるリソース・オブジェクトの名前が表示されていることを確認します。リソース・オブジェクト名を変更するには、「名前」フィールドの隣にある検索アイコンをクリックし、「検索と選択: 名前」ダイアログ・ボックスで名前を検索して選択します。
「フォーム名」フィールドにフォーム名を入力します。
「使用可能なフォーム・フィールド」セクションに、フォーム・フィールド名と説明のリストおよび表示名が表示されます。これらのフィールドは、作成するフォームで使用できます。使用可能な各フォーム・フィールドに対し、次のオプションを1つ以上選択します。
作成で使用: このオプションを選択すると、フォーム・フィールドをエンティティの作成に使用できるようになります。
バルク更新: このオプションを選択すると、フォーム・フィールドをエンティティのバルク更新に使用できるようになります。
暗号化済: このオプションを選択すると、フォーム・フィールドの値が暗号化形式で表示されます。
「作成」をクリックします。フォームが作成されたことを示すメッセージが表示されます。
「アプリケーション・インスタンスの作成」ページまたはアプリケーション・インスタンスの詳細ページの「属性」タブで、「フォーム」フィールドの隣にある「リフレッシュ」をクリックします。新しく作成したフォームを「フォーム」リストで選択できます。
|
注意: フォームを直接変更することはできません。フォームを作成する前に、サンドボックスを作成してアクティブ化する必要があります。サンドボックスの変更およびアクティブ化の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のサンドボックスの管理に関する説明を参照してください。 |
アプリケーション・インスタンスに関連付けられたフォームを変更するには:
「アプリケーション・インスタンスの作成」ページまたはアプリケーション・インスタンスの詳細ページの「属性」タブを開きます。
「フォーム」リストから、変更するフォームを選択します。
「フォーム」フィールドの右側にある「編集」をクリックします。図8-5に示すようなフォームの管理ページが表示されます。
フォームの変更の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプロセス・フォームの開発に関する説明を参照してください。
カスタム・フィールドの作成および編集の詳細は、「カスタム属性の構成」を参照してください。
アプリケーション・インスタンス・フォームをローカライズするには:
ローカライズ対象となるアプリケーション・インスタンス・フォームのあるサンドボックスを公開します。
MDSファイル(/xliffBundles/oracle/iam/ui/runtime/BizEditorBundle.xlf)をエクスポートします。このファイルには、メッセージ・キーとローカライズ対象メッセージがあります。
sessiondef.oracle.iam.ui.runtime.form.model.testAppInstance.entity.testAppInstanceEO.UD_TES8393_ACCOUNTID__c_LABEL
|
関連項目: メタデータ・ファイルのエクスポートの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の「カスタマイズのデプロイとアンデプロイ」を参照してください。 |
ファイルをエクスポートして、ドイツ語などにローカライズします。
/xliffBundles/oracle/iam/ui/runtime/BizEditorBundle_de.xlf
|
注意: このファイルはMDSに存在しない場合があります。存在しない場合、新規作成しますが、パスは同じにする必要があります。 |
ドイツ語でローカライズしたメッセージを用意しますが、手順2でエクスポートされたファイルと同じ形式に従ってください。
|
関連項目: リソース・バンドルをメタデータ・サービスのメタデータ・リポジトリから翻訳する方法の詳細は、Oracle Fusion Applications拡張性ガイドを参照してください。 |
/xliffBundles/oracle/iam/ui/runtime/BizEditorBundle_de.xlfをMDSにインポートします。
ログアウトしてから再びログインします。
Oracle Identity System Administrationを使用して、アプリケーション・インスタンスを構成できます。次のものが含まれます。
接続(ADユーザー)アプリケーション・インスタンスに対してプロビジョニングを構成するには:
Oracle Identity System Administrationにアクセスします。
「構成」で、「アプリケーション・インスタンス」をクリックします。
ActiveDirectoryApplicationInstance (ADユーザー)などの接続アプリケーション・インスタンスを選択します。
必要なフィールドに入力し、「適用」をクリックします。
リソース・オブジェクトを構成する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリソース・オブジェクト・フォームに関する項を参照してください。
ITリソースの構成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のITリソースの作成に関する項とITリソースの管理に関する項を参照してください。
アプリケーション・インスタンスのパスワード・ポリシーを構成するには:
Oracle Identity System Administrationにアクセスします。
「ポリシー」で、「パスワード・ポリシー」をクリックします。
必要なフィールドを設定して、パスワードの新しいルールを設定します。
構成可能な「ポリシー・ルール」フィールドと「カスタム・ポリシー」フィールドを示します。
アプリケーション・インスタンスのパスワード・ポリシーの設定が完了したら、新しいポリシーを接続(ADユーザー)アプリケーション・インスタンスにアタッチする必要があります。これを行うには、次のようにします。
Design Consoleにアクセスします。
「リソース管理」で、「リソース・オブジェクト」をクリックします。
パスワード・ポリシー・ルール・タブをクリックします。
作成した新しいパスワード・ポリシー(AD pwdpolicy)を選択して、接続アプリケーション・インスタンスにアタッチします。
「追加」をクリックします。
ターゲット・システムのアカウントに付与される権限により、アカウント所有者(ユーザー)は特定のタスクや機能を実行できます。権限は、ロール、職責またはグループ・メンバーシップの場合があります。たとえば、ユーザーRichardがターゲット・システムでInventory Analystロールを付与されている場合、Richardはその権限を使用してターゲット・システムの在庫関連レポートにアクセスし、生成できます。
Oracle Identity Managerでは、OIMユーザーにプロビジョニングされるアカウント(リソース)ごとに1つのプロセス・フォームがあります。権限データは、プロセス・フォームの子プロセス・フォームに格納されます。前述の例では、ターゲット・システムのRichardのアカウントのプロセス・フォームには、Inventory Managerロール・データを保持する子プロセス・フォームがあります。
子プロセス・フォームに格納される権限データを構成する属性は、ターゲット・システムによって異なる可能性があります。また、ロールと職責などの異なるタイプの権限は、異なる属性を持つ場合があります。たとえば、ターゲット・システムAに、次のロール・データの属性が含まれます。
ロール名
ロールの説明
開始日
終了日
同じターゲット・システムに、職責データの異なる属性のセットが含まれる場合があります。
職責ID
割当て日
代理ユーザー
エスカレーション・ユーザー
ターゲット・システムの権限を一意に識別する属性をマークまたは強調表示できます。前述のサンプル・ロールおよび職責データの属性で、「ロール名」属性と「職責ID」属性は、ターゲット・システムAのロール権限および職責権限を一意に識別します。権限を一意に識別する属性をマークすることにより、他のアイデンティティ管理ソリューションで使用可能であり、レポートでも表示される権限データの取得を有効にします。
|
注意: このリリースのOracle Identity ManagerでSAP User Managementコネクタのリリース9.xを使用する場合、「ロール」と「プロファイル」の権限が適切に動作するように次の手順を実行してください。
|
この項の内容は次のとおりです。
ターゲット・システムには、定義済で、ターゲット・システムのアカウント(ユーザー)に割り当てる準備ができた一連の権限を含めることができます。このターゲット・システムをOracle Identity Managerと統合すると、ターゲット・システムからOracle Identity ManagerのLKV表に権限データをインポート(同期)できます。
|
注意: 事前定義済コネクタを使用してターゲット・システムを統合する場合は、スケジュール済タスクを使用してこの表に権限データをフェッチすることができます。 |
権限リスト・スケジュール済ジョブでは、LKVからENT_LISTに権限を同期します。このジョブではまた、カタログ同期化ジョブを開始して、カタログに権限を同期します。権限は、カタログで検出されるようになった時点で使用できます。カタログ同期化の構成の詳細は、16.3.2.3項「進行中の同期」を参照してください。
プロビジョニング操作中に、カタログを使用して権限をリクエストします。アプリケーション・インスタンスのリクエストの送信時に、権限データと親データをともにリクエスト・データセットとして移入することもできます。このマニュアルでは、アカウントに割り当てられる権限を割り当てられた権限と呼びます。割り当てられた権限に関するデータは、子プロセス・フォーム表に格納されます。
各子プロセス・フォームの権限属性をマークした後、次のプロセスが実行されます。
次の手順では、使用可能権限に関するデータの取得方法について説明します。
|
注意:
|
ターゲット・システムとの同期により、使用可能権限に関するデータがLKV表に格納されます。
権限リスト・スケジュール済タスクをスケジュールし、実行します。
スケジュール・タスクにより、プロセス・フォームの権限プロパティから権限が判別されます。
スケジュール済タスクで、使用可能権限に関するデータがLKV表からENT_LIST表にコピーされます。
この項では、割り当てられた権限に関するデータの取得方法について説明します。子プロセス・フォームで権限属性にマークが付けられている場合、対応するUD表でトリガーが作成されます。権限属性にマークが付けられたフォームが、コネクタのインストールによってインポートされる場合も同様です。
|
注意: これらの手順で説明するプロセスを有効にするには、各子プロセス・フォームUD_表の権限属性をマークする必要があります。その方法については、この章で後述します。 |
権限割当ては、そのほとんどがトリガーを通じてリアルタイムで行われます。
トリガー:
権限がUD表に挿入されたときに、割り当てられた権限をUD表からent_assign表にコピーします。
UD表から権限が削除されたときに、割り当てられた権限をent_assignからent_assign_listに移動します。UD表で権限が更新されたときに、新しく割り当てられた権限をUD表からent_assign表にコピーし、前に割り当てられていた権限をent_assign_list表に移動します。
トリガーにより権限が正しく割り当てられない場合は、権限割当てスケジュール済タスクを使用して完全同期を実行できます。
たとえば、アカウント・リコンシリエーションスケジュール済タスクをターゲットから実行して新しい権限割当てをもたらしても、権限定義がENT_LISTに存在しないと、トリガーベースのメカニズムは機能しません。この条件では、このようなエントリをトリガーで無視し、スケジュール済タスクを介して処理する必要があります。権限がターゲットからリコンシリエーションされた後、適用可能になります。
権限データを取得するリソースの子プロセス・フォームUD_表の権限属性をマークする必要があります。ユーザーの操作環境に、15のターゲット・システムがあるとします。15個のリソースのうち12個のリソースの権限データを取得する場合は、それらの12個のリソースの権限属性をマークする必要があります。
この項で説明する手順を実行する際には、次のガイドラインに従います。
子プロセス・フォームで、権限データを保持する1つの属性のみをマークできます。
マークする属性は、LookupFieldタイプであり、そのプロパティは次のどちらかである必要があります。
参照コード
参照問合せ
「参照問合せ」は次の条件を満たす必要があります。
問合せでLKU表およびLKV表が使用される
問合せの「参照コード」はLKU表のものである
LKV_ENCODED列値が保存に使用される
LKV_DECODED列値が表示目的で使用される
子プロセス・フォームのフィールドを権限としてマークするには、次の手順を実行します。
Design Consoleにログインします。
「開発ツール」を開き、「フォーム・デザイナ」をダブルクリックします。
権限をマークする子フォームを検索し、開きます。
たとえば、UD_ADUSRC子フォームの権限をマークできます。
「新しいバージョンの作成」をクリックします。
新規バージョンのラベルを入力し、「保存」アイコンをクリックしてダイアログ・ボックスを閉じます。
「現在のバージョン」リストから、作成するバージョンを選択します。
「プロパティ」タブで権限としてマークするフィールドを選択し、「プロパティの追加」をクリックします。
「プロパティの追加」ダイアログ・ボックスの「プロパティ名」リストから、「権限」を選択します。
|
注意: 列タイプがLookupFieldに設定され、プロパティ名が「参照コード」に設定されている場合にのみ、「権限」をフィールドのプロパティとして設定できます。 |
「プロパティ値」フィールドに、trueと入力します。
ダイアログ・ボックスの他のフィールドに値を指定する必要はありません。
次のスクリーンショットは、参照フィールドの「プロパティの編集」ダイアログ・ボックスを示しています。
「保存」アイコンをクリックしてダイアログ・ボックスを閉じます。
権限の「開始日」および「終了日」値の取得を有効にする場合は、次の手順を実行します。
|
注意: 「開始日」および「終了日」値の取得は、両方のフィールドの列タイプがDateFieldDlgである場合にのみ有効にできます。 |
「プロパティ」タブで「開始日」フィールドを選択し、「プロパティの追加」をクリックします。
「プロパティの追加」ダイアログ・ボックスの「プロパティ名」リストから、「権限有効期限開始」を選択します。
「プロパティ値」フィールドに、trueと入力します。
「保存」アイコンをクリックしてダイアログ・ボックスを閉じます。
「プロパティ」タブで「終了日」フィールドを選択し、「プロパティの追加」をクリックします。
「プロパティの追加」ダイアログ・ボックスの「プロパティ名」リストから、「権限有効期限終了」を選択します。
「プロパティ値」フィールドに、trueと入力します。
次のスクリーンショットは、「開始日」フィールドの「プロパティの編集」ダイアログ・ボックスを示しています。
「保存」アイコンをクリックしてダイアログ・ボックスを閉じます。
「保存」アイコンをクリックして、子プロセス・フォームに行った変更を保存します。
次のスクリーンショットは、子プロセス・フォームの「プロパティ」タブを示しています。
|
注意: 「開始日」と「終了日」のマークはオプションです。 |
「バージョンをアクティブにする」をクリックします。
|
注意: 親フォームに最新バージョンの子フォームが含まれていることを確認してください。子の親を作成、編集およびアクティブ化した場合、同じ操作を親フォームにも行わないかぎり、自動的に親フォームに最新バージョンの子フォームが含まれることはありません。 |
Oracle Identity Managerでは、次の属性のうち設定されているものに基づいて、重複した権限または子データを検証します。
キー属性
権限属性
子データで重複を検証する前に、前述の属性の構成がチェックされます。表8-2に、有効な構成と無効な構成に関する概要を示します、
表8-2 可能なシナリオと重複の検証基準
| 権限属性 | リコンシリエーション・フィールドのマッピング用のキー属性 | 構成検証 | |
|---|---|---|---|
| 接続アプリケーション・インスタンス | 接続なしアプリケーション・インスタンス | ||
|
未定義 注意: このシナリオでは、構成が適切に定義されないので、ユーザーには重複権限や子データを追加する危険性があります。警告メッセージがサーバーのログに記録され、ユーザーに対して権限属性を定義するように促し、リコンシリエーション・フィールド・マッピングに一致させるようにします。 |
未定義 |
有効 |
有効 |
|
定義済。UD_CHILD1_ENT1などの属性はEntitlement=trueです。 注意: 権限属性には、リコンシリエーション・フィールド・マッピングで定義された一致キー属性がありません。 |
未定義 |
無効 |
有効 |
|
未定義 |
定義済。 UD_CHILD1_ENT1などの属性は、リコンシリエーション・フィールド・マッピングでキー属性に設定されます。 |
有効 |
有効 |
|
定義済。 UD_CHILD1_ENT1などの属性はEntitlement=trueです。 |
定義済。 UD_CHILD1_ENT1などの属性は、リコンシリエーション・フィールド・マッピングでキー属性に設定されます。 |
有効 |
有効 |
|
定義済。 UD_CHILD1_ENT1などの属性はEntitlement=trueです。 注意: 権限属性はリコンシリエーション・フィールド・マッピング・キー属性のサブセットです。 |
定義済。 UD_CHILD1_ENT1やUD_CHILD1_ENT2などの複数の属性が、UD_CHILD1子表のリコンシリエーション・フィールド・マッピングでキー属性として定義されます。 |
有効 |
有効 |
|
定義済。 UD_CHILD1_ENT1などの属性はEntitlement=trueです。 注意: 権限属性には、リコンシリエーション・フィールド・マッピングで定義された一致キー属性がありません。 |
定義済。 UD_CHILD1_ENT2やUD_CHILD1_ENT3などの属性が1つ以上、リコンシリエーション・フィールド・マッピングでキー属性として定義されます。 |
無効 |
無効 |
効果的な検証を有効にするために、リコンシリエーション・フィールド・マッピングでは、子データの一致キー属性と権限属性の両方を構成することをお薦めします。
有効な構成が検出されると、表8-3に示すような操作に基づいて、重複が検証されます。
表8-3 操作に基づく重複検証
| 操作 | 重複検証の説明 |
|---|---|
|
権限の追加 |
Entitlement=trueプロパティが定義されている属性。 |
|
子データの追加 |
リコンシリエーション・フィールド・マッピングで、キー属性である属性。 |
|
注意: 権限または子データの重複の検証を効果的に行うために、リコンシリエーション・フィールド・マッピングでは、権限属性と子データのキー属性の両方を構成することをお薦めします。 |
権限データを使用するために次のスケジュール済タスクを構成します。
Entitlement List・スケジュール済タスクでは、子プロセス・フォーム表の権限属性が識別され、権限データがLKV表からENT_LIST表にコピーされます。ENT_LIST表に作成されたレコードは、特定のターゲット・システムで定義された権限に対応します。
ユーザーの操作環境において新規権限がターゲット・システムで定義される頻度に応じて、このタスクのスケジュールを設定する必要があります。また、新しいターゲット・システムがOracle Identity Managerに統合された場合、このスケジュール済タスクを実行する必要があります。つまり、新しい権限をマークするたびにこのタスクを実行する必要があります。コネクタのスケジュール済タスクで参照フィールドのデータがターゲット・システムからLKV表にフェッチされた後、権限リスト・スケジュール済タスクを実行して、その権限データをENT_LIST表にコピーできます。
このスケジュール済タスクでは、ターゲット・システムの権限に対する更新や削除も処理されます。たとえば、Senior Accounts Analystロールがターゲット・システムから削除された場合、コネクタのスケジュール済タスクではそのロールのエントリがLKV表から削除されます。権限リスト・スケジュール済タスクを実行すると、ENT_LIST表のロールを含む行が削除済行としてマークされます。
権限割当てスケジュール済タスクは、トリガーによる権限のUD表からENT_ASSIGNへの同期が失敗した場合に、割り当てられた権限に関するデータをENT_ASSIGN表にコピーするために使用されます。このタスクでは、子プロセス・フォーム表の権限属性が識別され、割り当てられた権限に関するデータが子プロセス・フォーム表からENT_ASSIGN表にコピーされます。ENT_ASSIGN表に作成されたレコードは、特定のターゲット・システムで特定のユーザーに割り当てられた権限に対応します。
また、権限データのコピー元となる子プロセス・フォーム表にINSERT、UPDATEおよびDELETEトリガーが作成されます。これらのトリガーの機能の詳細は、「割り当てられた権限に関するデータの取得」を参照してください。
このスケジュール済タスクのRECORDS_TO_PROCESS_IN_BATCH属性を使用して、各バッチのレコード数を指定できます。デフォルトのバッチ・サイズは5000です。
権限は、次のいずれかの方法で削除できます。
ターゲットで権限を削除してから、参照リコンシリエーションを使用してその権限を同期し、さらに権限リスト・スケジュール済ジョブを実行します。
APIを使用して、権限リストから直接権限を削除します。
対応するアプリケーション・インスタンス経由で削除します。
いずれの削除の方法でも、権限はソフト削除済としてマークされます。つまり、権限に付けられた有効なフラグが更新されて、ソフト削除済としてマークされるようになります。
どの方法で削除を行った場合でも、次の後処理を実行する必要があります。
権限が公開されている組織でその権限を非公開にする
権限リストで権限のModify_dateを現在の日付に更新する
子表の権限のインスタンスと権限の割当てをパージし、カタログ収集により取得された権限のうちソフト削除済としてマークされているものとすべてのリクエスト・プロファイルを削除する
|
注意:
|
プロビジョニング・コンポーネントにおける権限のソフト削除の後処理を行うには:
EntitlementPostDeleteProcessingスケジュール済ジョブを実行します。
このタスクでは、次の項目の入力が必要です。
アプリケーション・インスタンス名/すべて
モード: 失効/削除
このタスクでは、次の機能を実行します。
「失効」モード: スケジュール済タスクにより、Oracle Identity Managerにおいてその特定の権限が付与されているすべてのアカウントから、権限の付与が失効されます。
「削除」モード: スケジュール済タスクにより、UD_CHILD表内のOIMデータベースから権限が単にハード削除されます。
このいずれの場合でも、権限の付与エントリがENT_ASSIGNから削除されます。
ENT_LISTスキーマを変更し、列SVR_KEYおよび制約を追加します。EntitlementListLoadスケジュール済タスクを実行します。これは、権限フィールドを持つすべてのリソースにアクセスし、対応する参照定義を取得してENT_LISTにその参照定義の値を移入する既存のスケジュール・タスクで、これによってプロセスに正しいSVR_KEYが設定されます。
図8-9に、権限のソフト削除のフローとそれに伴って行われる変更を示します。
同じエンコード値のエントリが削除され、続けて参照コードに追加される際、次の手順を実行して、データを権限リストと同期する必要があります。
Oracle Identity System Administrationにログインします。
権限リストジョブを実行し、既存のエントリをソフト削除します。
EntitlementPostDeleteProcessingジョブを「削除」モードで実行し、ソフト削除された項目をクリーンアップします。
権限リストジョブを再度実行し、新しいエントリを追加します。
ENT_ASSIGN表の割り当てられた権限データの増分同期を手動で無効化できます。つまり、割り当てられた権限に対する変更の取得を無効化できます。これを行うには、子プロセス・フォーム表に作成された次のトリガーを削除するSQLスクリプトを作成し、実行します。
|
注意: これらのトリガーは、権限割当てスケジュール済タスクによって作成されます。 |
OIU表に作成されたOIU_UDPATEトリガー
UD_表に作成されたTABLE_NAME_ENT_TRGトリガー
スクリプトの実行後、割り当てられた権限に対する変更はステージング表にコピーされません。
次に、子プロセス・フォーム表のトリガーを削除するSQLスクリプトのサンプルを示します。
create or replace
TRIGGER UD_LDAP_GRP_ENT_TRG
AFTER INSERT
OR DELETE
OR UPDATE OF UD_LDAP_GRP_GROUP_NAME
ON UD_LDAP_GRP
FOR EACH ROW
BEGIN
CASE
WHEN INSERTING THEN
OIM_SP_MANAGEENTITLEMENT('UD_LDAP_GRP',:NEW.UD_LDAP_GRP_GROUP_NAME,NULL,
:NEW.UD_LDAP_GRP_KEY,:NEW.ORC_KEY,NULL,NULL,NULL,
NULL,NULL,'INSERT');
WHEN UPDATING THEN
IF :NEW.UD_LDAP_GRP_GROUP_NAME != :OLD.UD_LDAP_GRP_GROUP_NAME
THEN
OIM_SP_MANAGEENTITLEMENT('UD_LDAP_GRP',:NEW.UD_LDAP_GRP_GROUP_NAME,
:OLD.UD_LDAP_GRP_GROUP_NAME,:NEW.UD_LDAP_GRP_KEY,:NEW.ORC_KEY,NULL,
NULL,NULL,
NULL,NULL,'UPDATE');
END IF;
WHEN DELETING THEN
OIM_SP_MANAGEENTITLEMENT('UD_LDAP_GRP',:OLD.UD_LDAP_GRP_GROUP_NAME,
NULL,NULL,:OLD.ORC_KEY,NULL,NULL,NULL,
NULL,NULL,'DELETE');
END CASE;
END;
次の事前定義済レポートは、割り当てられた権限に関するデータを提供します。
|
注意: これらのレポートを表示するには、ADMINISTRATORSグループのメンバーである必要があります。 レポートでは、特定のユーザーに対する同じ権限の重複した割当ては抑制されます(ENT_表にコピーされないため)。たとえば、ターゲット・システムでユーザーJohn DoeにSales Superintendentロールが2回割り当てられた場合、レポートには、この権限のインスタンスが1つのみ示されます。 |
「権限アクセス・リスト」レポートには、レポートの生成時に指定した権限を現在割り当てられているユーザーが一覧表示されます。このレポートには、権限に関する基本情報、および権限が割り当てられているユーザーのリストが表示されます。
「権限アクセス・リスト履歴」レポートには、レポートの生成時に指定した権限を割り当てられていたユーザーが一覧表示されます。このレポートには、権限に関する基本情報、および権限が割り当てられていたユーザーのリストが表示されます。
「ユーザー・リソース権限」レポートには、レポートの生成時に指定したユーザーの現在の権限が一覧表示されます。このレポートには、基本的なユーザー情報および権限の詳細が表示されます。
「ユーザー・リソース権限履歴」レポートには、レポートの生成時に指定したユーザーに過去に割り当てられていた権限の詳細が一覧表示されます。このレポートには、基本的なユーザー情報および権限の詳細が表示されます。
