9 アプリケーション・インスタンスの管理
この章の構成は、次のとおりです。
9.1 アプリケーション・インスタンスについて
アプリケーション・インスタンスは、ITリソース・インスタンス(ターゲット接続とコネクタ構成)と、リソース・オブジェクト(プロビジョニング・メカニズム)を組み合せた抽象化です。
以前のリリースでは、リクエストの作成はリソースの名前に基づいて管理者中心で行われ、テクノロジについての詳しい知識が必要でした。ただし、Oracle Identity Managerのこのリリースでは、ユーザーのアカウントと権限は、ITリソース・インスタンスやリソース・オブジェクトではなく、アプリケーション・インスタンスに関連付けられるようになりました。これにより、エンド・ユーザーはより簡単に操作できるようになります。
アプリケーション・インスタンスは組織に公開され、その組織のユーザーがリクエストできます。Microsoft Active Directory (AD)が、全世界の様々な組織または部門に属するユーザーにプロビジョニングされるとすると、次のもので構成されるアプリケーション・インスタンスを定義できます。
-
AD (リソース・オブジェクト)
-
URLおよびパスワードなどの接続情報を含む各ADサーバー・インスタンス(IT リソース)
リソース・オブジェクトは全ユーザーに対して同じですが、ポート番号などの接続情報は、異なる組織に属するユーザーでは異なる場合があるため、このような構成になります。これにより、ユーザーが接続情報を知らなくても、ADリソース・オブジェクトをアプリケーション・インスタンスとしてプロビジョニングできます。
アプリケーション・インスタンスは、プロビジョニング可能なエンティティです。特定のターゲット内にあるアカウントを取得するには、エンド・ユーザーがアプリケーション・インスタンスをリクエストする必要があります。エンド・ユーザーは、リソースをリクエストし、それとは別にITリソース・インスタンスを構成するかわりに、アプリケーション・インスタンスをリクエストできます。リクエストは、承認者による承認が必要です。リクエストが承認されると、ユーザーにリソースがプロビジョニングされ、ターゲット・システムにアカウントが作成されます。
ノート:
認可者からのリクエストには承認が不要の場合がありますが、エンド・ユーザーからのリクエストには承認者による承認が必要です。
9.2 アプリケーション・インスタンスの概念
アプリケーション・インスタンスごとの複数アカウント、権限、接続なしアプリケーション・インスタンス、アプリケーション・インスタンスのセキュリティなど、アプリケーション・インスタンスに関連する概念を理解します。
アプリケーション・インスタンスの概念については、次の各項で説明します。
9.2.1 1つのアプリケーション・インスタンスの複数アカウント
企業内のユーザーは、1つのアプリケーション・インスタンスに対して複数のアカウントを持つことができます。
これは、HR管理者が、管理アカウントを使用して組織の他の従業員のための様々なタスクを実行するようなシナリオで必要です。同じHR管理者が、自身のための特定のタスクを実行する場合には、別のユーザー・アカウントを使用してログインします。この例では、同じユーザーに、システムにログインして異なる種類の操作を行うための2つの異なるアカウントが必要です。
さらに、潜在的なセキュリティ上の脅威を防ぐためにも、ユーザーが複数アカウントを使用できるようにする必要があります。たとえば、あるユーザーが同じアカウントを使用して環境にログインし、管理タスク、自分自身と他のユーザーの標準ビジネス・タスクおよびITインフラストラクチャ関連タスクを実行するとします。システムに侵入されアカウントがハッキングされた場合、ハッカーはインフラストラクチャのデータおよびその他の機密情報にアクセスできます。ユーザーがタスクの種類ごとに異なる複数のアカウントを持っており、標準アカウントがハッキングされた場合は、ITインフラストラクチャに関する機密情報およびその他の重要なリソースはハッカーから守られます。
Oracle Identity Managerでは、1つのアプリケーション・インスタンスで複数のアカウントをサポートしています。作成される最初のアカウントはプライマリ・アカウントとしてタグが付けられ、ユーザーにとって唯一のプライマリ・アカウントになります。同じアプリケーション・インスタンス上に作成された後続アカウントは「その他」のタグが付与されます。
ユーザーがアプリケーション・インスタンスに対してプロビジョニングされると、Oracle Identity Managerにより、それがそのアプリケーション・インスタンスでそのユーザーに対してプロビジョニングされる最初のアカウントであるかどうかがチェックされます。最初のアカウントである場合、そのアカウントは「プライマリ」とマークされます。既存のユーザー・アカウントがアプリケーション・インスタンスからリコンサイルされている場合、リコンサイルされた最初のアカウントがプライマリとしてマークされます。「プライマリ」とマークされたアカウントが実際のプライマリ・アカウントではない場合、手動でそのアカウントの「プライマリ」タグを変更して、別のアカウントを「プライマリ」とマークできます。
9.2.2 権限
ターゲット・システムのアカウントに付与される権限により、アカウント所有者(ユーザー)は特定のタスクや機能を実行できます。
権限は、ロール、職責またはグループ・メンバーシップの場合があります。たとえば、ユーザーRichardがターゲット・システムでInventory Analystロールを付与されている場合、Richardはその権限を使用してターゲット・システムの在庫関連レポートにアクセスし、生成できます。
Oracle Identity Managerでは、Oracle Identity Managerユーザーにプロビジョニングされるアカウント(リソース)ごとに1つのプロセス・フォームがあります。権限データは、子プロセス・フォームに格納されます。前述の例では、ターゲット・システムのRichardのアカウントのプロセス・フォームには、Inventory Managerロール・データを保持する子プロセス・フォームがあります。
ノート:
ターゲット・システムで作成された権限をOracle Identity Managerにリコンシリエーションするには、最初に参照フィールド同期のスケジュール済ジョブを実行してから、権限リスト・スケジュール済ジョブを実行する必要があります。
子プロセス・フォームに格納される権限データを構成する属性は、ターゲット・システムによって異なる可能性があります。また、ロールと職責などの異なるタイプの権限は、異なる属性を持つ場合があります。
権限は、最初にユーザー・アカウント対するリソースの変更をリクエストすることなく、直接リクエストできます。権限は、子フォームにより個別に処理されるため、アカウント・データには含まれません。ユーザーは、権限のプロビジョニング、変更または取消しを実行できます。リクエストした権限について、ユーザーは承認プロセス中に承認者の助けになる可能性のある追加情報を提供できます。
権限のすべてのタイプが、リクエスト・カタログでのリクエストに使用可能です。管理権限のリクエストが承認されると、プライマリ・アカウントに管理権限が関連付けられます。また、リクエスタはターゲット・アカウントを選択でき、承認者はターゲット・アカウントを変更することもできます。
Oracle Identity System Administrationの「アプリケーション・インスタンス」セクションを使用して、権限を編集できます。
権限の詳細は、「権限の開発」を参照してください。
9.2.3 接続なしアプリケーション・インスタンス
アプリケーション・インスタンスが接続なしタイプの場合は、ターゲット・アプリケーション・インスタンスで手動でプロビジョニングを実行できます。
Oracle Identity Managerにおけるセルフ・サービス、委任管理、リクエスト管理およびロールベースのプロビジョニング機能はデプロイできますが、プロビジョニングを自動化するためのプロビジョニングおよびリコンシリエーション・コネクタはデプロイできません。委任管理操作、リクエストの承認またはロールベースのプロビジョニングが完了すると、手動のプロビジョニング・タスクが管理者に割り当てられます。続けて管理者は、ターゲットのアプリケーション・インスタンスで、プロビジョニングを手動で実行します。この例には、物理アクセス・カードのプロビジョニングがあります。Oracle Identity Managerでは物理アクセス・カードをプロビジョニングできないため、接続なしリソースのアプリケーション・インスタンスがプロビジョニングされます。
接続なしリソースのプロビジョニングを行うために、接続なしタイプのアプリケーション・インスタンスを作成できます。手動プロビジョニング管理者は、Oracle Identity Self Serviceの「受信箱」セクションを使用して、リクエストの全フィールドを更新できます。手動プロビジョニング管理者が手動プロビジョニング・ワークリスト項目を送信すると、手動プロビジョニング管理者の応答に基づいて、プロビジョニング・インフラストラクチャにより基礎となるプロビジョニング・タスクに「完了」のマークが付けられます。管理者がそのタスクが手動で完了されたことを示すと、ステータスがプロビジョニング済に変更されます。
9.3 アプリケーション・インスタンスの管理
Oracle Identity System Administrationを使用してアプリケーション・インスタンスを管理します。これには、アプリケーション・インスタンスの作成、変更および削除と、アプリケーション・インスタンスに関連付けられたフォームの作成と変更が含まれます。
この項では、次の項目について説明します。
関連項目:
接続なしアプリケーション・インスタンスから接続アプリケーション・インスタンスへの変換の詳細は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズの接続なしアプリケーション・インスタンスから接続アプリケーション・インスタンスへの変換に関する項を参照してください
9.3.1 アプリケーション・インスタンスの作成
アイデンティティ・システム管理の「アプリケーション・インスタンス」ページを使用して、アプリケーション・インスタンスの名前と表示名、接続があるかどうか、リソース・オブジェクト、ITリソース・インスタンス、フォーム、親アプリケーション・インスタンスなどの属性を指定し、アプリケーション・インスタンスを作成します。
アプリケーション・インスタンスを作成するには:
9.3.2 アプリケーション・インスタンスの検索
アプリケーション・インスタンスは、様々な検索条件に含めることができるアプリケーション・インスタンス属性に基づいて検索できます。
アプリケーション・インスタンスを検索するには:
ヒント:
例による問合せ機能を使用すると、特定の値に基づいて検索を絞り込めます。詳細は、Oracle Identity Governanceでのセルフ・サービス・タスクの実行の例による問合せの使用に関する項を参照してください。
9.3.3 アプリケーション・インスタンスの変更
アプリケーション・インスタンスを開いて、属性の変更、アプリケーション・インスタンスを使用できる組織の割当てと失効、アプリケーション・インスタンスに関連付けられた権限の編集を行うことができます。
これらのタスクについては、次の各項で説明します。
9.3.3.1 アプリケーション・インスタンス属性の変更
アプリケーション・インスタンス属性を変更するには、アプリケーション・インスタンスの詳細を開いてから、スケジュール済ジョブであるカタログ同期ジョブを実行します。
アプリケーション・インスタンスの属性を変更するには:
ノート:
カタログ同期化ジョブを「増分」モードで実行することをお薦めします(これによって、ベース・エンティティのアプリケーション・インスタンスと権限で追加、更新、削除などの変更内容がカタログDBと同期されます)。
9.3.3.2 アプリケーション・インスタンスに関連付けられた組織の管理
アプリケーション・インスタンスを組織に公開して、アプリケーション・インスタンスのリクエストとそれに続くユーザーへのプロビジョニングを可能にする必要があります。アプリケーション・インスタンスに関連付けられた組織の管理では、アプリケーション・インスタンスを組織に公開したり、組織を失効させたりします。
この項では、アプリケーション・インスタンスに関連付けられた組織の管理について説明します。内容は次のとおりです。
9.3.3.2.1 アプリケーション・インスタンスに関連付けられた組織について
アプリケーション・インスタンスを組織に公開して、アプリケーション・インスタンスのリクエストとそれに続くユーザーへのプロビジョニングを可能にする必要があります。その組織に属するユーザー、その組織でユーザー・ビューア・ロールを持っているユーザーまたはその組織でアプリケーション・インスタンス・ビューア・ロールとユーザー・ビューア・ロールを持っているユーザーが、アプリケーション・インスタンスをリクエストできます。
「アプリケーション・インスタンスの詳細」ページの「組織」タブでは、組織へのアプリケーション・インスタンスの公開とアプリケーション・インスタンスからの組織の失効を行うことができます。
また、アプリケーション・インスタンスを組織とその下位組織に公開して、下位組織のユーザーもアプリケーション・インスタンスをリクエストできるようにすることもできます。権限を持つ組織にアプリケーション・インスタンスを公開して、その組織のユーザーが、権限が関連付けられたアプリケーション・インスタンスをリクエストできるようにすることもできます。
ノート:
管理者ユーザーは、管理者が表示できるすべての組織にエンティティを公開できます。たとえば、権限管理者は、自身が表示権限を持つすべての組織に対し、管理権限付きの権限を公開できます。
9.3.3.2.3 アプリケーション・インスタンスからの組織の失効
アプリケーション・インスタンスから組織を失効させるには:
- 「組織」タブで、開いているアプリケーション・インスタンスから失効させる組織を選択します。
- 「アクション」メニューから「失効」を選択します。または、ツールバーにある「失効」をクリックします。選択した組織を示す確認ボックスが表示されます。
- 「はい」をクリックして確認します。アプリケーション・インスタンスから組織が失効されます。
ヒント:
アプリケーション・インスタンスの公開先の組織の下位組織から失効するには、対応する「下位組織を含める」オプションの選択を解除し「適用」をクリックします。
9.3.3.3 アプリケーション・インスタンスに関連付けられた権限の管理
アプリケーション・インスタンスに関連付けられた権限を変更することにより、権限属性値を変更したり、組織の権限を公開または失効します。
この項では、次の項目について説明します。
9.3.3.3.1 権限属性の変更
アプリケーション・インスタンスに関連付けられた権限の属性を変更するには:
- 「アプリケーション・インスタンスの詳細」ページで、「権限」タブをクリックします。開いているアプリケーション・インスタンスに関連付けられている権限のリストが表示されます。
- 変更する権限を選択します。
- 「アクション」メニューの「編集」を選択します。または、ツールバーにある「編集」をクリックします。選択した権限の詳細がページに表示されます。
- 属性の値(表示名や説明など)を変更し、「保存」をクリックします。権限の変更が保存されます。
- カタログ同期化ジョブ・スケジュール済ジョブを実行します。
9.3.3.3.3 組織の権限の失効
アプリケーション・インスタンスに関連付けられた組織の権限を失効するには:
- 「アプリケーション・インスタンスの詳細」ページで、「権限」タブをクリックします。開いているアプリケーション・インスタンスに関連付けられている権限のリストが表示されます。
- 失効する権限を選択します。ページの最下部に権限の詳細が表示されます。
- 組織の下位組織の権限を失効する場合、「下位組織を含める」を選択したままにします。
- 「アクション」メニューから「失効」を選択します。または、ツールバーにある「失効」をクリックします。確認を求める警告が表示されます。
- 「はい」をクリックします。
- カタログ同期化ジョブ・スケジュール済ジョブを実行します。
9.3.4 アプリケーション・インスタンスの削除の理解
「アプリケーション・インスタンス」ページでアプリケーション・インスタンスを削除できます。その後、スケジュール済ジョブとして、アプリケーション・インスタンス削除後処理ジョブを実行します。
この項では、アプリケーション・インスタンスを削除する方法について説明します。次の項で、これについて説明します。
9.3.4.1 アプリケーション・インスタンスの削除について
アプリケーション・インスタンスは、次のいずれかの方法で削除できます。
-
Oracle Identity System Administrationの「アプリケーション・インスタンス」セクションからアプリケーション・インスタンスを削除します。
-
アプリケーション・インスタンスの構成要素であるITリソースを削除します。
これらのいずれかの方法でアプリケーション・インスタンスを削除した場合、アプリケーション・インスタンスはOracle Identity Managerからハード削除されるわけではありません。アプリケーション・インスタンスはソフト削除されます。これは、そのアプリケーション・インスタンスの結果としてプロビジョニングされたアカウントが、ターゲット・システム内に存在する場合があるためです。そのため、アプリケーション・インスタンスを削除した後で、次の操作を行うためのスケジュール済ジョブを実行する必要があります。
-
エンティティ・パブリケーションからアプリケーション・インスタンスを非公開にします。
-
エンティティ・パブリケーションから関連付けられた権限を非公開にします。
-
アプリケーション・インスタンスのすべてのアカウントを失効させるか、ハード削除するか、削除済としてマークします。
9.3.5 アプリケーション・インスタンスに関連付けられたフォームの作成および変更
アイデンティティ・システム管理の「アプリケーション・インスタンス」ページで、リソース・オブジェクトに関連付けられ、続けてアプリケーション・インスタンスに関連付けられているフォームを作成および変更できます。
関連項目:
-
サンドボックスの詳細は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズのサンドボックスの管理に関する項を参照してください。
-
フォームの作成の詳細は、「フォームの管理」を参照してください。
-
カスタム属性の構成の詳細は、「カスタム属性の構成」を参照してください。
この節では、以下のトピックについて説明します。
9.3.5.1 アプリケーション・インスタンスに関連付けられたフォームの作成
アプリケーション・インスタンスに関連付けられたフォームを作成するには:
ノート:
フォームを直接作成することはできません。フォームを作成する前に、サンドボックスを作成してアクティブ化する必要があります。サンドボックスの作成およびアクティブ化の詳細は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズのサンドボックスの管理に関する項を参照してください。
-
Oracle Identity System Administrationにログインします。
-
サンドボックスを作成してアクティブ化します。サンドボックスがアクティブ化されていない場合、警告メッセージが表示されます。サンドボックスの作成およびアクティブ化の詳細な手順は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズのサンドボックスの管理に関する項を参照してください
-
左ペインの「プロビジョニング構成」で、「フォーム・デザイナ」をクリックします。「フォーム・デザイナ」ページが表示されます。
-
「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」をクリックします。「フォームの作成」ページが表示されます。
-
「リソース・タイプ」フィールドで、フォームを関連付けるリソース・オブジェクトを指定します。そのように行うには:
-
「名前」フィールドの横にある参照アイコンをクリックします。「検索と選択: 名前」ダイアログ・ボックスが表示されます。
-
「名前」フィールドで、検索するリソース・オブジェクトの名前を入力します。リソース・オブジェクトすべてを表示する場合、このフィールドは空白のままでもかまいません。
-
「検索」をクリックします。検索条件と一致するリソース・オブジェクトが表示されます。
-
フォームに関連付けるリソース・オブジェクトを選択して、「OK」 をクリックします。リソース・オブジェクト名が、「フォームの作成」ページの「名前」フィールドに表示されます。
-
-
「フォーム名」フィールドにフォーム名を入力します。
-
(オプション)「フォーム・タイプ」で、使用可能ないずれかのオプションを選択します。
-
親フォーム + 子表(マスター/詳細)
-
親フォーム(マスター)
-
親フォーム + 子表(権限なし) (マスター/詳細)
-
-
(オプション)新しいフォームを権限に関連付ける場合は、「権限フォームの生成」オプションを選択します。このフォームを使用すると、ユーザーは承認プロセス中に承認者の助けになる可能性のある追加情報を提供できます。
-
「使用可能なフォーム・フィールド」セクションに、フォーム・フィールド名と説明のリストおよび表示名が表示されます。これらのフィールドは、作成するフォームで使用できます。使用可能なフォーム・フィールドごとに、「バルク更新」オプションを選択できます。このオプションを選択すると、エンティティのバルク更新にこのフォーム・フィールドを使用できます。
-
「アプリケーション・インスタンスの作成」ページまたは「アプリケーション・インスタンスの詳細」ページの「属性」タブで、「フォーム」フィールドの隣にある「リフレッシュ」をクリックします。
-
新しく作成したフォームを「フォーム」リストから選択して、「適用」をクリックします。
9.3.5.2 アプリケーション・インスタンスに関連付けられたフォームの変更
ノート:
フォームを直接変更することはできません。フォームを作成する前に、サンドボックスを作成してアクティブ化する必要があります。サンドボックスの変更およびアクティブ化の詳細は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズのサンドボックスの管理に関する項を参照してください。
アプリケーション・インスタンスに関連付けられたフォームを変更するには:
- 「フォーム」フィールドの右側にある「編集」をクリックします。図9-1に示すようなフォームの管理ページが表示されます。
カスタム・フィールドの作成および編集の詳細は、「カスタム属性の構成」を参照してください。
9.3.5.3 アプリケーション・インスタンス・フォームのローカライズ
アプリケーション・インスタンス・フォームをローカライズするには:
-
コネクタのアプリケーション・インスタンスを作成し、そこにフォームをアタッチします。
-
Oracle Enterprise Managerにログインします。
-
「アプリケーションのデプロイ」→「oracle.iam.console.identity.sysadmin.ear」→「MDS構成」に移動します。
-
「エクスポート」をクリックして、アーカイブをホストに保存します。
-
アーカイブを解凍し、SAVE_LOCATION\xliffBundles\oracle\iam\ui\runtime\BizEditorBundle.xlfファイルをテキスト・エディタで開きます。
ノート:
このファイルはMDSに存在しない場合があります。存在しない場合、新規作成しますが、パスは同じにする必要があります。
-
次のようにして、BizEditorBundle.xlfファイルを編集します。
-
次のコードを検索します。
<file source-language="en" original="/xliffBundles/oracle/iam/ui/runtime/BizEditorBundle.xlf" datatype="x-oracle-adf">
これを、日本語用に次のコードに置換します。
<file source-language="en" target-language="ja" original="/xliffBundles/oracle/iam/ui/runtime/BizEditorBundle.xlf" datatype="x-oracle-adf">
-
アプリケーション・インスタンスのコードを検索します。この手順は、JDEアプリケーション・インスタンスのサンプル編集を示しています。元のコードは次のとおりです。
<trans-unit id="${adfBundle['oracle.adf.businesseditor.model.util.BaseRuntimeResourceBundle']['persdef.sessiondef.oracle.iam.ui.runtime.form.model.user.entity.userEO.UD_JDE_LANGUAGE__c_description']}"> <source>Language</source> </target> </trans-unit> <trans-unit id="sessiondef.oracle.iam.ui.runtime.form.model.JDEArj.entity.JDEArjEO.UD_JDE_LANGUAGE__c_LABEL"> <source>Language</source> </target> </trans-unit> -
コネクタ・パッケージに入っているリソース・ファイル(たとえば、JDEdwards_ja.properties)を開き、そのファイルの属性の値(たとえば、global.udf.UD_JDE_LANGUAGE=\u8A00\u8A9E)を取得します。
-
ステップ6bに示されている元のコードを、次のものに置き換えます。
<trans-unit id="${adfBundle['oracle.adf.businesseditor.model.util.BaseRuntimeResourceBundle']['persdef.sessiondef.oracle.iam.ui.runtime.form.model.user.entity.userEO.UD_JDE_LANGUAGE__c_description']}"> <source>Language</source> <target>\u8A00\u8A9E</target> </trans-unit> <trans-unit id="sessiondef.oracle.iam.ui.runtime.form.model.JDEArj.entity.JDEArjEO.UD_JDE_LANGUAGE__c_LABEL"> <source>Language</source> <target>\u8A00\u8A9E</target> </trans-unit> -
プロセス・フォームのすべての属性に対し、ステップ6aから6dを繰り返します。
-
ファイルをBizEditorBundle_ja.xlfという名前で保存します。
-
-
ZIPファイルを再パッケージしてMDSにインポートします。
関連項目:
メタデータ・ファイルのエクスポートおよびインポートの詳細は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズの「カスタマイズのデプロイおよびデプロイ解除」を参照してください。
-
Oracle Identity Managerからログアウトして再度ログインします。
9.4 アプリケーション・インスタンスの構成
アプリケーション・インスタンスを作成した後で、アプリケーション・インスタンスを構成する必要があります。これには、アプリケーション・インスタンスのリソース・オブジェクト、ITリソースおよびパスワード・ポリシーの構成が含まれます。
この項では、次の項目について説明します。
9.4.1 リソース・オブジェクトの構成
Design Consoleを使用してリソース・オブジェクトを構成します。
リソース・オブジェクトの構成の詳細は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のリソース・オブジェクトのフォームに関する項を参照してください。
9.4.2 ITリソースの構成
アプリケーション・インスタンスは、1つのITリソースに対してのみ構成できます。アカウントをプロビジョニングするために、複数のITリソースの値をプロセス・フォームが必要とする場合は、UIから直接構成することはできません。
アカウントをプロビジョニングするために、複数のITリソースを構成するには:
ノート:
ITリソースの構成の詳細は、「ITリソースの管理」を参照してください。
-
アカウントの主要なITリソースを特定し、それによってアプリケーション・インスタンスを構成します。
-
エンティティ・アダプタを使用して、他に必要なITリソースに値を移入します。たとえば、Microsoft Exchangeコネクタ9.1.1.7では、Exchangeアカウントをプロビジョニングするために、ADのITリソースおよびExchangeのITリソースのITリソース値が必要です。ステップ3と4を実行するとR2で動作するようになります。
-
ExchangeのITリソースを使用してアプリケーション・インスタンスを作成し、親アプリケーションとしてADのアプリケーション・インスタンスを選択します。これがExchangeの依存リソースであるためです。
-
ADのITリソースの値をプロセス・フォームに渡すようにエンティティ・アダプタを構成します。そのように行うには:
-
依存ITリソース名(例、Exchange)、および独立ITリソース名(例、AD)を記録します。これはコードにすることも、参照に外部化してコードに初期化することもできます。
-
long形式のパラメータとしてエンティティ・アダプタを作成します。これは、移入される親ITリソース・キーです。
-
アダプタ・コードの中で、親ITリソース名を見つけ、ステップiで述べたマップを使用して、子ITリソース名を逆参照します。
-
子ITリソース名から、long形式の子ITリソース・キーを取得して返します。エンティティ・アダプタの戻り値が、プロセス・フォームの子ITリソース・フィールドに設定されます。
-
9.4.3 アプリケーション・インスタンスのパスワード・ポリシーの構成
アプリケーション・インスタンスのパスワード・ポリシーを作成できます。これにはDesign Consoleでパスワードの新しいルールを設定します。
アプリケーション・インスタンスのパスワード・ポリシーを構成するには、次のステップを実行します:
-
Oracle Identity Self Serviceにログインします。
-
パスワードの新しいルールを設定することにより、アプリケーション・インスタンスのパスワード・ポリシーを作成します。パスワード・ポリシーの作成および管理の詳細は、Oracle Identity Governanceでのセルフ・サービス・タスクの実行のパスワード・ポリシーの管理に関する項に関する項を参照してください。
-
アプリケーション・インスタンスのパスワード・ポリシーの設定が完了したら、新しいポリシーを接続(ADユーザー)アプリケーション・インスタンスにアタッチする必要があります。そのように行うには:
-
Design Consoleにアクセスします。
-
「リソース管理」で、「リソース・オブジェクト」をクリックします。
-
パスワード・ポリシー・ルール・タブをクリックします。
-
作成した新しいパスワード・ポリシー(AD pwdpolicy)を選択して、接続アプリケーション・インスタンスにアタッチします。
-
「追加」をクリックします。
図9-2に、「リソース・オブジェクト」フォームの「パスワード・ポリシー・ルール」タブを示します。
-
9.5 権限の開発
権限の開発に関連する概念には、権限データ取得プロセス、子プロセス・フォームでの権限属性のマーク、権限の重複検証、権限データを使用するためのスケジュール済タスクの構成、権限の削除、新規エントリの権限リスト削除後のリフレッシュ、割り当てられた権限に対する変更の取得の無効化、および権限関連レポートの生成があります。
この項では権限の開発について説明します。内容は次のとおりです。
9.5.1 権限について
ターゲット・システムのアカウントに付与される権限により、アカウント所有者(ユーザー)は特定のタスクや機能を実行できます。
権限は、ロール、職責またはグループ・メンバーシップの場合があります。たとえば、ユーザーRichardがターゲット・システムでInventory Analystロールを付与されている場合、Richardはその権限を使用してターゲット・システムの在庫関連レポートにアクセスし、生成できます。
Oracle Identity Managerでは、Oracle Identity Managerユーザーにプロビジョニングされるアカウント(リソース)ごとに1つのプロセス・フォームがあります。権限データは、プロセス・フォームの子プロセス・フォームに格納されます。前述の例では、ターゲット・システムのRichardのアカウントのプロセス・フォームには、Inventory Managerロール・データを保持する子プロセス・フォームがあります。
権限は、最初にユーザー・アカウント対するリソースの変更をリクエストすることなく、直接リクエストできます。権限は、子フォームにより個別に処理されるため、アカウント・データには含まれません。ユーザーは、権限のプロビジョニング、変更または取消しを実行できます。リクエストした権限について、ユーザーは承認プロセス中に承認者の助けになる可能性のある追加情報を提供できます。
子プロセス・フォームに格納される権限データを構成する属性は、ターゲット・システムによって異なる可能性があります。また、ロールと職責などの異なるタイプの権限は、異なる属性を持つ場合があります。たとえば、ターゲット・システムAに、次のロール・データの属性が含まれます。
-
ロール名
-
ロールの説明
-
開始日
-
終了日
同じターゲット・システムに、職責データの異なる属性のセットが含まれる場合があります。
-
職責ID
-
割当て日
-
プロキシ・ユーザー
-
エスカレーション・ユーザー
ターゲット・システムの権限を一意に識別する属性をマークまたは強調表示できます。前述のサンプル・ロールおよび職責データの属性で、「ロール名」属性と「職責ID」属性は、ターゲット・システムAのロール権限および職責権限を一意に識別します。権限を一意に識別する属性をマークすることにより、他のアイデンティティ管理ソリューションで使用可能であり、レポートでも表示される権限データの取得を有効にします。
ノート:
このリリースのOracle Identity ManagerでSAP User Managementコネクタのリリース9.xを使用する場合、「ロール」と「プロファイル」の権限が適切に動作するように次のステップを実行してください。
-
ロール子フォームで、ロール・システム名フィールドから「権限」と「必須」のプロパティを削除します。
-
プロファイル子フォームで、プロファイル・システム名フィールドから「権限」と「必須」のプロパティを削除します。
9.5.2 使用可能権限および割り当てられた権限
ターゲット・システムによって、割り当てられた権限リストと一緒に使用できる、事前定義済権限のリストが用意されます。これらの権限を使用して、ターゲット・システムのユーザーに割り当てることができます。
ターゲット・システムには、定義済で、ターゲット・システムのアカウント(ユーザー)に割り当てる準備ができた一連の権限を含めることができます。このターゲット・システムをOracle Identity Managerと統合すると、ターゲット・システムからOracle Identity ManagerのLKV表に権限データをインポート(同期)できます。
ノート:
事前定義済コネクタを使用してターゲット・システムを統合する場合は、スケジュール済タスクを使用してこの表に権限データをフェッチすることができます。
権限リスト・スケジュール済ジョブは、権限をリクエスト・カタログに同期するために実行されます。権限は、リクエスト・カタログに表示されるようになった時点で使用できます。カタログ同期化の構成の詳細は、「進行中の同期」を参照してください。
プロビジョニング操作中に、カタログを使用して権限をリクエストします。アプリケーション・インスタンスのリクエストの送信時に、権限データと親データをともにリクエスト・データセットとして移入することもできます。このマニュアルでは、アカウントに割り当てられる権限を割り当てられた権限と呼びます。割り当てられた権限に関するデータは、子プロセス・フォーム表に格納されます。
9.5.3 権限データ取得プロセス
各子プロセス・フォームで権限属性にマークを付けると、使用可能権限に関するデータの取得が行われます。
次のステップでは、使用可能権限に関するデータの取得方法について説明します。
ノート:
-
これらのステップで説明するプロセスを有効にするには、各子プロセス・フォームの権限属性をマークする必要があります。その方法については、この章で後述します。
-
親フォームに最新バージョンの子フォームが含まれていることを確認してください。子の親を作成、編集およびアクティブ化した場合、同じ操作を親フォームにも行わないかぎり、自動的に親フォームに最新バージョンの子フォームが含まれることはありません。フォーム・デザイナから親/子フォームのアクティブ化を処理する「権限」フィールドにマークを付けることができます。
- ターゲット・システムとの同期により、使用可能権限に関するデータがLKV表に格納されます。
- 権限リスト・スケジュール済タスクをスケジュールし、実行します。
- スケジュール・タスクにより、プロセス・フォームの権限プロパティから権限が判別されます。
- スケジュール済タスクで、使用可能権限に関するデータがLKV表からENT_LIST表にコピーされます。
9.5.4 子プロセス・フォームでの権限属性のマーク
権限データを取得するリソースの子プロセス・フォームUD_表の権限属性をマークする必要があります。
ユーザーの操作環境に、15のターゲット・システムがあるとします。15個のリソースのうち12個のリソースの権限データを取得する場合は、それらの12個のリソースの権限属性をマークする必要があります。
この項で説明する手順を実行する際には、次のガイドラインに従います。
-
子プロセス・フォームで、権限データを保持する1つの属性のみをマークできます。
-
マークする属性は、LookupFieldタイプであり、そのプロパティは次のどちらかである必要があります。
-
参照コード
-
参照問合せ
「参照問合せ」は次の条件を満たす必要があります。
-
問合せでLKU表およびLKV表が使用される
-
問合せの「参照コード」はLKU表のものである
-
LKV_ENCODED列値が保存に使用される
-
LKV_DECODED列値が表示目的で使用される
-
-
子プロセス・フォームのフィールドを権限としてマークするには:
- Identity System Administrationにログインします。
- フォーム・デザイナを使用して、「カスタムの子フォーム属性の作成」で説明しているように、子フォーム属性を作成します。権限の属性の作成時には、「権限」および「検索可能」オプションが選択されていることを確認します。
9.5.5 権限または子データの重複検証
重複した権限または子データは、「キー」属性または「権限」属性(いずれか設定されている属性)に基づいて検証されます。
子データで重複を検証する前に、前述の属性の構成がチェックされます。表9-2に、有効な構成と無効な構成に関する概要を示します、
表9-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つ以上、リコンシリエーション・フィールド・マッピングでキー属性として定義されます。 |
無効 |
無効 |
効果的な検証を有効にするために、リコンシリエーション・フィールド・マッピングでは、子データの一致キー属性と権限属性の両方を構成することをお薦めします。
有効な構成が検出されると、表9-3に示すような操作に基づいて、重複が検証されます。
表9-3 操作に基づく重複検証
| 操作 | 重複検証の説明 |
|---|---|
|
権限の追加 |
Entitlement=trueプロパティが定義されている属性。 |
|
子データの追加 |
リコンシリエーション・フィールド・マッピングで、キー属性である属性。 |
ノート:
効率的な重複権限または子データ検証を有効にするように、リコンシリエーション・フィールド・マッピングの子データの権限属性およびキー属性の両方を構成することをお薦めします。
9.5.6 権限データを使用するためのスケジュール済タスクの構成
9.5.6.1 権限リスト
権限リスト・スケジュール済タスクでは、子プロセス・フォーム表の権限属性が識別され、権限データがLKV表からENT_LIST表にコピーされます。ENT_LIST表に作成されたレコードは、特定のターゲット・システムで定義された権限に対応します。
ユーザーの操作環境において新規権限がターゲット・システムで定義される頻度に応じて、このタスクのスケジュールを設定する必要があります。また、新しいターゲット・システムがOracle Identity Managerに統合された場合、このスケジュール済タスクを実行する必要があります。つまり、新しい権限をマークするたびにこのタスクを実行する必要があります。コネクタのスケジュール済タスクで参照フィールドのデータがターゲット・システムからLKV表にフェッチされた後、権限リスト・スケジュール済タスクを実行して、その権限データをENT_LIST表にコピーできます。
このスケジュール済タスクでは、ターゲット・システムの権限に対する更新や削除も処理されます。たとえば、Senior Accounts Analystロールがターゲット・システムから削除された場合、コネクタのスケジュール済タスクではそのロールのエントリがLKV表から削除されます。権限リスト・スケジュール済タスクを実行すると、ENT_LIST表のロールを含む行が削除済行としてマークされます。
9.5.6.2 権限割当て
権限割当てスケジュール済タスクは、トリガーによる権限のUD表からENT_ASSIGNへの同期が失敗した場合に、割り当てられた権限に関するデータをENT_ASSIGN表にコピーするために使用されます。このタスクでは、子プロセス・フォーム表の権限属性が識別され、割り当てられた権限に関するデータが子プロセス・フォーム表からENT_ASSIGN表にコピーされます。ENT_ASSIGN表に作成されたレコードは、特定のターゲット・システムで特定のユーザーに割り当てられた権限に対応します。
このスケジュール済タスクのRECORDS_TO_PROCESS_IN_BATCH属性を使用して、各バッチのレコード数を指定できます。デフォルトのバッチ・サイズは5000です。
また、権限データのコピー元となる子プロセス・フォーム表にINSERT、UPDATEおよびDELETEトリガーが作成されます。
9.5.7 権限の削除
権限を削除すると、ソフト削除済としてマークされます。権限を永続的に削除するには、削除タスク後のプロセスを実行する必要があります。
この項では、権限を削除する方法について説明します。内容は次のとおりです。
9.5.7.1 権限の削除について
権限は、次のいずれかの方法で削除できます。
-
ターゲットで権限を削除してから、参照リコンシリエーションを使用してその権限を同期し、さらに権限リスト・スケジュール済ジョブを実行します。
-
APIを使用して、権限リストから直接権限を削除します。
-
対応するアプリケーション・インスタンス経由で削除します。
いずれの削除の方法でも、権限はソフト削除済としてマークされます。つまり、権限に付けられた有効なフラグが更新されて、ソフト削除済としてマークされるようになります。
どの方法で削除を行った場合でも、次の後処理を実行する必要があります。
-
権限が公開されている組織でその権限を非公開にする
-
権限リストで権限のModify_dateを現在の日付に更新する
-
子表の権限と権限割当てのインスタンスをパージする
-
カタログ収集によって選択された権限、ソフト削除済としてマークされた権限およびすべてのリクエスト・プロファイルを削除する
ノート:
-
ソフト削除された権限への参照を持つ進行中のリクエストは失敗します。
-
削除された権限を持つアクセス・ポリシーは、手動で更新して同じ権限を削除する必要があります。
9.5.7.2 権限の削除の後処理
プロビジョニング・コンポーネントにおける権限のソフト削除の後処理を行うには:
-
権限削除後の処理ジョブ・スケジュール済ジョブを実行します。
このタスクでは、次の項目の入力が必要です。
-
アプリケーション・インスタンス名/すべて
-
モード: 失効/削除
-
-
このタスクでは、次の機能を実行します。
-
「失効」モード: スケジュール済タスクにより、Oracle Identity Managerにおいてその特定の権限が付与されているすべてのアカウントから、権限の付与が失効されます。
-
「削除」モード: スケジュール済タスクにより、UD_CHILD表内のOracle Identity Managerデータベースから権限が単にハード削除されます。
-
このいずれの場合でも、権限の付与エントリがENT_ASSIGNから削除されます。
ノート:
権限の削除後の補正が必要な場合は、モードフラグを「失効」ではなく「削除」に設定する必要があります。Design Consoleを使用してバックエンドから削除される権限を要求詳細からも削除する必要があり、GrandタスクおよびRevokeタスクがユーザーの受信ボックスに表示されないようにする必要がある場合は、権限削除後の処理ジョブ・スケジュール済ジョブを、モードフラグを「削除」に設定して実行する必要があります。 -
-
権限リストというスケジュール済タスクを実行します。これは、権限フィールドを持つすべてのリソースにアクセスし、対応する参照定義を取得してENT_LISTにその参照定義の値を移入する既存のスケジュール・タスクで、これによってプロセスに正しいSVR_KEYが設定されます。
9.5.8 新規エントリの権限リスト削除後のリフレッシュ
データを権限リストと同期化するには、スケジュール済ジョブの権限リストと権限の削除後処理ジョブを実行します。
同じエンコード値のエントリが削除され、続けて参照コードに追加される際、次のステップを実行して、データを権限リストと同期する必要があります。
- Oracle Identity System Administrationにログインします。
- 「権限リスト」ジョブを実行し、既存のエントリをソフト削除します。
- 権限削除後の処理ジョブ・スケジュール済ジョブを「削除」モードで実行し、ソフト削除済項目をクリーンアップします。
- 「権限リスト」ジョブを再度実行し、新しいエントリを追加します。
9.5.9 割り当てられた権限に対する変更の取得の無効化
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;
9.5.10 権限関連レポート
割り当てられた権限のデータを提供する事前定義済レポートは、「権限アクセス・リスト」、「権限アクセス・リスト履歴」、「ユーザー・リソース権限」および「ユーザー・リソース権限履歴」です。
次の事前定義済レポートは、割り当てられた権限に関するデータを提供します。
ノート:
これらのレポートを表示するには、ADMINISTRATORSグループのメンバーである必要があります。
レポートでは、特定のユーザーに対する同じ権限の重複した割当ては抑制されます(ENT_表にコピーされないため)。たとえば、ターゲット・システムでユーザーJohn DoeにSales Superintendentロールが2回割り当てられた場合、レポートには、この権限のインスタンスが1つのみ示されます。
9.5.10.1 権限アクセス・リスト
「権限アクセス・リスト」レポートには、レポートの生成時に指定した権限を現在割り当てられているユーザーが一覧表示されます。このレポートには、権限に関する基本情報、および権限が割り当てられているユーザーのリストが表示されます。
9.5.10.2 権限アクセス・リスト履歴
「権限アクセス・リスト履歴」レポートには、レポートの生成時に指定した権限を割り当てられていたユーザーが一覧表示されます。このレポートには、権限に関する基本情報、および権限が割り当てられていたユーザーのリストが表示されます。
9.5.10.3 ユーザー・リソース権限
「ユーザー・リソース権限」レポートには、レポートの生成時に指定したユーザーの現在の権限が一覧表示されます。このレポートには、基本的なユーザー情報および権限の詳細が表示されます。
9.6 接続なしリソースの管理
接続なしリソースの管理には、接続なしリソースの理解、接続なしアプリケーション・インスタンスの管理、接続なしアプリケーション・インスタンスでの操作のプロビジョニング、権限付与の構成、手動プロセス・タスク・アクションでのステータスの変更の理解、プロビジョニングSOAコンポジットのカスタマイズ、接続なしリソースのトラブルシューティングが含まれます。
この項では、接続なしリソースについて説明します。内容は次のとおりです。
9.6.1 接続なしリソースについて
接続なしリソースとは、コネクタが存在しないターゲットのことです。したがって、接続なしリソースのプロビジョニングは自動的に処理されないため、手動で実行する必要があります。
以前のリリースのOracle Identity Managerでは、接続なしのプロビジョニングは第一のユースケースとしてはサポートされておらず、プロビジョニング・プロセスで手動タスクを使用することによりサポートされています。この方法には多くの制限があり、接続なしリソースのモデルではこのような制限に対処しています。したがって、接続なしリソースは手動プロビジョニングの拡張構成であり、SOA統合を使用して、手動プロビジョニング・ワークフローの柔軟性と構成可能性を高めるものです。
接続なしリソースの例には、バッジ、ラップトップ、ページャなど、処理が手動で行われるアイテムがあります。
9.6.2 接続なしリソースのアーキテクチャ
接続なしリソース機能では、既存のOracle Identity Managerプロビジョニング・エンジン・アーティファクト(プロビジョニング・プロセス、プロセス・タスク、アダプタなど)を使用しますが、その際に、シームレスかつ構成可能な方法でBPEL統合を提供します。
UIを使用して接続なしアプリケーション・インスタンスが作成されると、リソース・オブジェクト(「切断」タイプ)、基本的なプロビジョニング操作のタスクを含むプロビジョニング・プロセス、ITリソース、最小限のフィールド(さらにカスタマイズ可能)を含むプロセス・フォームなどの多くのバックエンド構成アーティファクトが、自動的にシードされます。
図9-3に、接続なしリソースのプロビジョニング・プロセス・アーキテクチャを示します。
接続なしアプリケーション・インスタンスが(リクエストまたはその他の方法によって)ユーザーにプロビジョニングされると、プロビジョニング・プロセスで特定のワークフローがトリガーされます。これにより、対応するプロセス・タスクが起動されて手動のプロビジョニング・アダプタが実行され、即時利用可能な接続なしSOAコンポジット・プロビジョニングが実行されます。SOA手動タスクが、システム管理者にデフォルトで割り当てられます。割当て先が手動タスクに対応すると、provisioningcallback Webサービスが割当て先指定のレスポンスで起動され、その後、プロビジョニング操作が完了または中断されて、アカウントが適切に更新されます。
表9-4に、コンポジットで使用可能な手動のSOAコンポジット・プロビジョニングのペイロードの属性を示します。
表9-4 手動のSOAコンポジット・プロビジョニングのペイロードの属性
| 属性 | 説明 |
|---|---|
|
アカウントID |
考慮対象アカウントのアカウントID (oiu_key) |
|
アプリケーション・インスタンス名 |
接続なしアプリケーション・インスタンスの表示名 |
|
リソース・オブジェクト名 |
接続なしリソース・オブジェクト名 |
|
ITリソース名 |
接続なしITリソース名 |
|
受益者ログイン |
アカウント受益者のログイン |
|
エンティティ・キー |
アカウントのプロビジョニング、失効、無効化および有効化の各操作におけるアプリケーション・インスタンス・キー。 |
|
エンティティ・タイプ |
アカウントのプロビジョニング、失効、無効化および有効化の各操作において、タイプはApplicationInstanceに設定されます。 |
|
受益者の名 |
アカウント受益者の名 |
|
受益者の姓 |
アカウント受益者の姓 |
|
記述フィールド |
考慮対象アカウントのアカウント記述フィールド |
|
URL |
Oracle Identity ManagerのWebサービスのコールバックURL |
|
リクエスト・キー |
リクエストを介した操作の場合のリクエスト・キー |
|
リクエスタ・ログイン |
リクエストを介した操作の場合のリクエスタのログイン |
9.6.3 接続なしアプリケーション・インスタンスの管理
接続なしアプリケーション・インスタンスの管理には、接続なしアプリケーション・インスタンスの作成と、既存の接続なしリソースのための接続なしアプリケーション・インスタンスの作成が含まれます。
接続なしアプリケーション・インスタンスの管理には、次のタスクが含まれます。
9.6.3.1 接続なしアプリケーション・インスタンスの作成
ノート:
アプリケーション・インスタンスの作成前に、新しいサンドボックスを作成する必要があります。アプリケーション・インスタンスの作成後に、サンドボックスを公開する必要があります。サンドボックスの作成および公開の詳細は、Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズのサンドボックスの管理に関する項を参照してください。
接続なしアプリケーション・インスタンスを作成するには:
- それぞれの属性フィールドに、次の表に示すように値を入力します。
属性 値 名前
アプリケーション・インスタンスの名前を入力します。これは必須フィールドです。
表示名
アプリケーション・インスタンスの表示名を入力します。これは必須フィールドです。
説明
アプリケーション・インスタンスの説明を指定します。
切断
チェック・ボックスを選択します。これは、アプリケーション・インスタンスが接続されていないかどうかを示すフラグです。
ノート: これはUI専用のフラグであり、バックエンドでは維持されません。「リソース・オブジェクト」および「ITリソース・インスタンス」の各フィールドはバックエンドで自動的に作成されるため、このフラグをチェックすると、これらのフィールドが無効化されます。
図9-4に、「アプリケーション・インスタンスの作成」ページの属性を示します。
9.6.3.2 既存の接続なしリソースに対する接続なしアプリケーション・インスタンスの作成
既存の接続なしリソースに対して接続なしアプリケーション・インスタンスを作成するには、「アプリケーション・インスタンスの作成」を参照してください。
ノート:
「切断」オプションは、選択するとリソース・オブジェクトやITリソースなどのアーティファクトがバックエンドで作成されるため、選択を解除しておく必要があります。
9.6.4 接続なしアプリケーション・インスタンスでのプロビジョニング操作
「有効化」、「無効化」、「失効」または「プロビジョニング」の各操作に対してプロビジョニング・プロセスがトリガーされると、対応するプロセス・タスクが挿入され、手動プロビジョニング・アダプタが実行されます。このアダプタにより、即時利用可能なSOAコンポジット・プロビジョニングが実行されます。SOAヒューマン・タスクが、システム管理者にデフォルトで割り当てられます。
システム管理者はOracle Identity Self Serviceの受信箱から次のことを実行できます。
-
タスクの詳細を確認します。
-
アカウントの詳細を確認します。
-
データを変更して「履行」ボタンをクリックすることにより、Oracle Identity Managerのプロセス・フォーム・データを変更します。
-
ターゲットで操作の手動により実行します。
-
「完了」または「却下」をクリックすることにより、保留タスクを実行します。
割当て先が保留中の手動タスクに対応すると、コールバック・プロビジョニングのWebサービスが起動され、これにより、Oracle Identity Manager操作が継続されてアカウントが適切に更新されます。割当て先アクションに基づいたアカウント・ステータスの変更の詳細は、「手動のプロセス・タスク・アクションでのステータス変更」を参照してください。
Oracle Identity Managerは、接続なしアプリケーション・インスタンスでの次のプロビジョニング操作はサポートしていません。
-
パスワード操作
-
プロビジョニング・プロセスのカスタマイズ操作
接続なしリソースのプロセス・フォーム・フィールドが更新されると、「<FORM_NAME>が更新されました」プロセス・タスクが、プロビジョニング・プロセスに挿入されます。これにより、割当て先によって対応するターゲットにおける変更を手動で更新できるよう、手動のSOAヒューマン・タスクが生成されます。
ノート:
「<FORM_NAME>が更新されました」タスクは、単一または複数のどちらのプロセス・フォーム・フィールドに対する更新であるかに関係なく挿入されます。この動作は接続リソースの動作とは異なります。また、接続なしリソースに対して、個々のプロセス・フォーム・フィールド更新タスクを構成する必要はないことに注意してください。
9.6.5 権限付与の構成
接続なしリソースの権限付与の構成には、子フォームの作成と権限の参照定義の構成が含まれます。
権限の付与を構成するには:
ノート:
子フォームを作成する前に、サンドボックスを作成してアクティブ化します。
-
Oracle Identity System Administrationにアクセスします。「構成」で、「フォーム・デザイナ」をクリックし、次のステップを実行します。
-
「リソース・タイプ」をクリックし、接続なしリソースを検索します。
-
検索結果から、接続なしアプリケーション・インスタンス・フォーム名をクリックします。
-
-
「子オブジェクト」タブに移動し、「追加」をクリックして子フォームを追加します。
-
「名前」フィールドで子表に名前を指定し、「OK」をクリックします。
-
編集のために名前リンクをクリックして開きます。
-
「作成」をクリックします。「フィールド・タイプの選択」ダイアログ・ボックスで、「参照」を選択し、「OK」をクリックします。
-
権限フィールドに、次の値を指定します。
-
表示ラベル・フィールドに、表示名を入力します。
-
「名前」フィールドに、参照の名前を入力します。
-
-
次のチェック・ボックスを選択します。
-
検索可能
-
権限
-
「検索可能」ピックリスト
ノート:
「検索可能」、「権限」および「「検索可能」ピックリスト」の各チェック・ボックスを選択して、権限フィールドを子フォーム上で作成することは必須です。
-
-
参照タイプの新規カスタム・フィールドを作成し、「OK」をクリックします。
-
「値リスト」セクションで、新しい参照タイプ作成のアイコンをクリックして、「意味」(Lookup.Laptop.appsなど)、「コード」(Lookup.Laptop.appsなど)および説明の値を次のように指定します。
-
「新規」をクリックして権限値を追加し、参照コードを追加します。「コード」および「意味」の各列の値は、次の形式である必要があります。
コード 意味 <ENTITTLEMENT_NAME>
<ENTITLEMENT_DESCRIPTION>
-
「保存」をクリックします。「参照タイプの作成」ダイアログ・ボックスが閉じます。
-
「保存して閉じる」をクリックします。
-
-
「親オブジェクトに戻る」をクリックして親フォームに戻ります。
-
「ビューの再生成」をクリックしてUIアーティファクトおよびデータセットを再生成し、「OK」をクリックして確認します。
「ビューの再生成」ポップアップ・ウィンドウで使用できるオプションの詳細は、「フォーム・デザイナを使用したフォームの変更」を参照してください。
-
サンドボックスを公開します。
-
Oracle Identity System Administrationの「システム管理」→「スケジューラ」に戻ります。
-
権限リスト・スケジュール済ジョブを検索して実行します。
-
スケジュール済ジョブの実行が完了した後、カタログ同期化ジョブと呼ばれる別のスケジュール済ジョブを検索して実行します。
ノート:
プロビジョニング・プロセスのカスタマイズはサポートされていませんが、コンポジットの接続なしプロビジョニングはカスタマイズできます。
9.6.6 手動のプロセス・タスク・アクションでのステータス変更
プロビジョニング・アクションのステータスは、プロビジョニング操作に対する各手動タスクアクションに応じて変わります。
表9-5に、手動タスク・アクションに基づいたステータス変更の詳細を示します。
表9-5 手動のプロセス・タスク・アクションのステータス
| プロビジョニング操作 | 手動タスク・アクション | プロビジョニング・アクション |
|---|---|---|
|
プロビジョニング |
完了 |
アカウント・ステータスは「プロビジョニング済」に設定されます。 |
|
プロビジョニング |
却下 |
アカウント・ステータスは更新されません。 |
|
無効化 |
完了 |
アカウント・ステータスは「無効」に設定されます。 |
|
無効化 |
却下 |
アカウント・ステータスは更新されません。 |
|
有効化 |
完了 |
アカウント・ステータスは「有効」に設定されます。 |
|
有効化 |
却下 |
アカウント・ステータスは更新されません。 |
|
失効 |
完了 |
アカウント・ステータスは「失効」に設定されます。 |
|
失効 |
却下 |
アカウント・ステータスは更新されません。 |
|
更新 |
完了 |
操作は行われません。 |
|
更新 |
却下 |
操作は行われません。 |
|
権限の付与 |
完了 |
子表のトリガー挿入プロセス・タスクが完了すると権限ステータスが「プロビジョニング済」に設定されます。 |
|
権限の付与 |
却下 |
子表のトリガー挿入プロセス・タスクが取り消されると、子表のエントリが削除されます。 |
|
権限の失効 |
完了 |
Oracle Identity Managerから子表のエントリが削除されます。 |
|
権限の失効 |
却下 |
操作は行われません。 |
9.6.7 SOAコンポジット・プロビジョニングのカスタマイズ
プロビジョニングSOAコンポジットをカスタマイズするには、ヒューマン・タスク割当てをSOAコンポーザでカスタマイズし、事前定義済のコンポジットを変更します。
SOAコンポジット・プロビジョニングには、次のカスタマイズが含まれます。
9.6.7.1 SOAコンポーザによるヒューマン・タスク割当てのカスタマイズ
手動の接続なしSOAコンポジット・プロビジョニングにはデフォルト・ルール(ManualProvisioningRule)があり、このルールによってヒューマン・タスクがシステム管理者に割り当てられます。
ペイロード(アプリケーション・インスタンス名など)に応じて、より優先度が高いカスタム・ルールをSOAコンポーザUIから作成でき、このルールに従って、手動タスク割当てをカスタマイズできます。
カスタム・ルールを追加するには:
9.6.8 接続なしリソースのトラブルシューティング
接続なしリソースに対するプロビジョニングやその他のタスクを実行したとき発生する可能性がある一般的な問題には、手動タスクが割当て先に割り当てられないことや、アカウント・ステータスが変更されないことがあります。
表9-6に、接続なしリソースに対するプロビジョニングやその他のタスクを実行したとき発生する可能性がある一般的な問題を示します。
表9-6 接続なしリソースのトラブルシューティング
| 問題 | 解決策 |
|---|---|
|
接続なしアプリケーション・インスタンスをプロビジョニングするときに、手動タスクが割当て先に割り当てられない。 |
次のステップを実行します。
|
|
手動タスクの完了時に、アカウント・ステータスが変更されない。 |
次のステップを実行します。
|