| Oracle® Identity Manager Database User Managementコネクタ・ガイド リリース11.1.1 B72411-10 |
|
 前 |
ノート:
この項で説明する手順は、Oracle Identity Managerリリース11.1.1.xを使用している場合にのみ適用できます。
この項では、組織における固有の要件に合せてカスタム・リクエスト・ワークフローを構成する方法について説明します。カスタム・リクエスト・ワークフローを構成するには、次のステップを実行します。
次の項では、プラグイン・ポイントを使用してリクエスト管理操作を拡張する方法について説明します。
ここでは、次の各項でリクエスト・データセットについて説明します。
リクエスト・データセットは、リクエスト・ライフサイクルの様々なフェーズでどのデータを収集する必要があるかを指定する、XML定義ファイルです。リクエスト・データセットでは、リクエスタや承認者が送信する必要がある属性、属性が必須かどうか、およびUIでどのようにユーザーに対して属性をレンダリングするかを定義できます。データセットの一部として定義されたすべての属性は、属性の動作を定義する一連のプロパティに関連付けられます。また、リクエスト・データセットを使用すると、リクエストのコンテキストにのみ存在する追加属性を定義することもできます。
すべてのリクエストはリクエスト・テンプレートを使用して要求されます。各リクエスト・テンプレートはリクエスト・タイプに関連付けられています。各リクエスト・タイプはリクエスト・モデルに関連付けられています。リクエスト・モデルとリクエスト・タイプの間には、1対1の対応関係があります。リクエスト・モデルは、リクエスト・エンジンに特定のリクエスト・タイプに対して特定の方法で動作するように指示する仕様または構成です。リクエスト・モデルは、大まかに、ユーザー、リソースおよびロールの3つのタイプのエンティティに関連付けられます。すべてのリクエスト・モデルがOracle Identity Managerに付属しており、構成することはできません。
特定のリクエスト・タイプのリクエストが要求されると、リクエスト・モデルによって適切なリクエスト・データセットが関連付けられます。たとえば、汎用のリソースのプロビジョニング・リクエスト・モデルでは、リソース・オブジェクトのプロビジョニングのリクエストを処理します。リソースを定義するたびに、リクエストを介してそのリソースをプロビジョニングする必要がある場合は、リクエスト・ライフサイクルの間に収集する必要がある属性を使用して新しいデータセットを作成できます。非汎用エンティティであるユーザーに関連付けられたリクエスト・データセットには、事前定義済またはデフォルトのリクエスト・データセットがあります。
汎用エンティティに関連付けられたリクエスト・モデルには、デフォルトのリクエスト・データセットがありません。たとえば、リソースのプロビジョニング・リクエスト・モデルは、汎用エンティティであるリソースに関連付けられます。ユーザーなどの非汎用エンティティに関連付けられたリクエスト・モデルの場合、ユーザー・エンティティにデフォルト属性の固定セットがあるため、デフォルトのリクエスト・データセットを使用できます。
configuring-requests.htm#GUID-5DD0ECDB-940E-4DE3-B83D-827031171C0D__CIHCFIAEに、Oracle Identity Managerに付属のリクエスト・モデルおよび関連するデフォルトのリクエスト・データセット・ファイル名を示します。
表A-1 Oracle Identity Managerに付属のデフォルトのリクエスト・データセット
| リクエスト・モデル | デフォルトのデータセット・ファイル名 | エンティティ |
|---|---|---|
ユーザーの作成 |
CreateUserDataSet.xml |
User |
ユーザーの削除 |
DeleteUserDataset.xml |
User |
ユーザーの有効化 |
EnableUserDataset.xml |
User |
ユーザーの無効化 |
DisableUserDataset.xml |
User |
ユーザー・プロファイルの変更 |
ModifyUserDataset.xml |
User |
ユーザーの自己登録 |
SelfCreateUserDataset.xml |
User |
セルフ・プロファイルの変更 |
ModifyUserDataset.xml |
User |
ロールの作成 |
CreateRoleDataSet.xml |
ロール |
ロールの変更 |
ModifyRoleDataSet.xml |
ロール |
ロールの削除 |
DeleteRoleDataSet.xml |
ロール |
ロールの割当て |
AssignRolesDataset.xml |
ロール |
ロールの自己割当て |
AssignRolesDataset.xml |
ロール |
ロールの自己削除 |
RemoveRolesDataset.xml |
ロール |
ロールからの削除 |
RemoveRolesDataset.xml |
ロール |
リソースのプロビジョニング |
リクエスト・データセットなし |
リソース |
リソースの自己リクエスト |
リクエスト・データセットなし |
リソース |
プロビジョニング済リソースの有効化 |
リクエスト・データセットなし |
リソース |
プロビジョニング済リソースの変更 |
リクエスト・データセットなし |
リソース |
プロビジョニング済リソースの自己変更 |
リクエスト・データセットなし |
リソース |
プロビジョニング済リソースの無効化 |
リクエスト・データセットなし |
リソース |
リソースのプロビジョニング解除 |
リクエスト・データセットなし |
リソース |
リソースの自己プロビジョニング解除 |
リクエスト・データセットなし |
リソース |
ノート:
リクエスト・モデルごとにリクエスト・データセットを用意する必要はありません。たとえば、リソースのプロビジョニング解除リクエスト・モデルでは、リクエストの送信または承認の一部として収集する特定のデータはないため、リクエスト・データセットは必要ありません。ただし、リソースのプロビジョニング・リクエスト・モデルでは、リクエストの送信または承認の一部としてリソース固有のデータの収集が必要になる場合、収集するデータおよびその収集方法を指定するデータセットをそのモデルに対して定義する必要があります。
デフォルトのデータセットは、新しい属性を追加するなどしてカスタマイズまたは構成できます。次のメタデータには、デフォルトのリクエスト・タイプのリクエスト・モデルおよびデータセット定義が含まれています。
/metadata/iam-features-requestactions/model-data/AssignRolesDataset.xml/metadata/iam-features-requestactions/model-data/CreateRoleDataSet.xml/metadata/iam-features-requestactions/model-data/CreateUserDataSet.xml/metadata/iam-features-requestactions/model-data/DeleteRoleDataSet.xml/metadata/iam-features-requestactions/model-data/DeleteUserDataset.xml/metadata/iam-features-requestactions/model-data/DeleteUserRequest.xml/metadata/iam-features-requestactions/model-data/DisableUserDataset.xml/metadata/iam-features-requestactions/model-data/DisableUserRequest.xml/metadata/iam-features-requestactions/model-data/EnableUserDataset.xml/metadata/iam-features-requestactions/model-data/EnableUserRequest.xml/metadata/iam-features-requestactions/model-data/ModifyRoleDataSet.xml/metadata/iam-features-requestactions/model-data/ModifyUserDataset.xml/metadata/iam-features-requestactions/model-data/RemoveRolesDataset.xml/metadata/iam-features-requestactions/model-data/ResourceCommonDataset.xml/metadata/iam-features-requestactions/model-data/SelfCreateUserDataset.xml
リクエスト・データセットは、次の要素およびそれに関連付けられた属性を使用して定義します。
request-data-set要素は、リクエスト・データセットのルート要素であり、次の必須属性があります。
name: データセットの名前(CreateUserDataSetなど)
entity: データセットが関連付けられる、基礎となるエンティティ(ユーザーなど)
operation: データセットに関連付けられる操作(CREATEなど)
次の例は、request-data-set要素を示しています。
<request-data-set xmlns="http://www.oracle.com/schema/oim/request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.oracle.com/schema/oim/request" name="CreateUserDataSet" entity="User" operation="CREATE">
このルート要素には、子要素がありません。
リソース・エンティティのリクエスト・データセットを作成するには、各リクエスト・タイプのリクエスト・データセット名の書式および操作を示すconfiguring-requests.htm#GUID-60FCAF09-8573-494B-B881-7A66F3A6BE2F__CIHCFBDHを参照してください。
表A-2 リソース・エンティティのリクエスト・データセット
| リクエスト・タイプ | リクエスト・データセット名の書式 | 操作 |
|---|---|---|
リソースのプロビジョニング |
ProvisionResource${ENTITY-NAME} |
PROVISION |
リソースの自己リクエスト |
ProvisionResource${ENTITY-NAME} |
PROVISION |
プロビジョニング済リソースの変更 |
ModifyResource${ENTITY-NAME} |
MODIFYRESOURCE |
プロビジョニング済リソースの自己変更 |
ModifyResource${ENTITY-NAME} |
MODIFYRESOURCE |
E-Business ROリソースのProvision Resourceデータセットのサンプル・データセット・タグを次に示します。
<request-data-set xmlns="http://www.oracle.com/schema/oim/request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.oracle.com/schema/oim/request" name="ProvisionResourceE-Business RO" entity="E-Business RO" operation="PROVISION">
説明:
nameについては、configuring-requests.htm#GUID-60FCAF09-8573-494B-B881-7A66F3A6BE2F__CIHCFBDHで指定されているProvisionResource${ENTITY-NAME}の書式がリソース名E-Business ROに置き換わります。${ENTITY_NAME}をリソース名に置き換えます。
configuring-requests.htm#GUID-60FCAF09-8573-494B-B881-7A66F3A6BE2F__CIHCFBDHに示されているように、operationを指定します。
プロパティの値は次のとおりです。
name: ProvisionResourceE-Business RO
entity: E-Business RO
operation: PROVISION
DataSetValidator要素は、リクエスト・データセットのオプション要素です。request-data-set要素の子要素の1つであり、データセット属性値を検証するためのユーザー定義のプラグイン詳細を記述します。リクエスト・データを送信中に検証するために、リクエスト・エンジンによって、実装されているプラグインが実行されます。検証が正常に終了すると、リクエストが作成されます。それ以外の場合、リクエストは作成されません。プラグイン・ロジックを実装する必要があります。DataSetValidatorは、各データセットに1つのみ定義できます。属性は次のとおりです。
name: この属性では、DataSetValidatorプラグインの論理名を指定します。
classname: この属性では、実装されているプラグイン・クラスの完全修飾名を指定します。
次の例は、DataSetValidator要素を示しています。
<DataSetValidator name="CreateUserDataValidator" classname="oracle.iam.requestactions.plugins.datavalidator.CreateUserDataValidator"/>
configuring-requests.htm#GUID-5DD0ECDB-940E-4DE3-B83D-827031171C0D__CIHCFIAEに示されているデフォルトの各リクエスト・データセットでは、デフォルトのDataSetValidator要素が定義され、対応する実装がデフォルトで提供されています。これらのデフォルトのリクエスト・データセット内にあるDataSetValidatorのクラス名をカスタマイズされたクラスに変更して、カスタマイズされた検証を適用できます。
関連項目:
送信後のリクエスト・データのカスタム検証の詳細は、「リクエスト・データの検証」を参照してください。
この子要素は、リクエスト・データセットと基礎となるエンティティ属性またはプロセス・フォーム・フィールドの間のデータ・フローにおいて、リクエスト終了時にエンティティ属性を定義するために使用されます。AttributeReferenceに対応するすべてのデータは、構成に基づき、リクエスト・ライフ・サイクルの様々なステージにおいてリクエスト・データとして収集されます。
1つのデータセットには、属性ごとに1つずつ指定して、複数のAttributeReference要素を含めることができます。
このセクションには次のトピックが含まれます:
AttributeReferenceは、次の必須プロパティを使用して構成します。
name: 要素を識別する一意の名前。リクエストでは、この名前を使用してAttributeReferenceを参照します。値はString型です。
attr-ref: データセット値とプロセス・フォーム・フィールドまたは基礎となるエンティティ属性の間のマッピング・プロパティです。たとえば、Create Userデータセット内の定義<AttributeReference name="Organization" attr-ref="act_key">によって、新しく作成し、ユーザー・エンティティのact_keyデータ・フィールドに移入するユーザーに対応するデータを、リクエストがOrganizationとして収集することが指定されます。
同様に、AttributeReference name="Domain" attr-ref="domain"定義をProvision Emailリソース・データセットに関連付けて使用すると、リクエストは、プロビジョニングするリソースに対応するデータをDomainとして収集し、そのデータがプロセス・フォームのdomainフィールドに移入されます。したがって、リソースのプロビジョニング・モデルでは、attr-ref属性値をプロセス・フォームのフィールド・ラベル(SDC_LABEL)と同じにする必要があります。その他のモデルでは、attr-ref属性値を機能によって定義されている基礎となるエンティティのエンティティ属性にする必要があります。値はString型です。
リクエスト・データセット属性を基礎となるエンティティ属性にマップするには、データ・フローが必要です。たとえば、リソースのプロビジョニングなどの一部のリクエスト・モデルでは、リクエスト・データセットとプロセス・フォーム・データ・フィールドの間のデータ・フロー・マッピングを定義する必要があります。データ・フロー・マッピングは、データセットで次のように指定することによって設定できます。
<AttributeReference name="ATTRIBUTE_NAME" attr-ref="DATA_FIELD_NAME_IN_PROCESS_FORM" available-in-bulk="false" />
ユーザーベースおよびロールベースのリクエスト・データセットの場合、attr-ref値はユーザーおよびロール・エンティティ定義で指定されている属性名となります。リソースベースのリクエスト・モデルでは、attr-ref値をプロセス・フォーム属性のラベル名にする必要があります。ただし、子フォームについては、attr-ref値を子表名にする必要があります。
type: このプロパティでは、値のデータ型を指定します。たとえば、First Name属性のtype="String"によって、「ユーザーの作成」リクエストUIの「名」フィールドでString型の入力を受け入れることが指定されます。サポートされているデータ型は次のとおりです。
Byte
Double
Integer
String
Short
Long
Date
Boolean
ByteArray
Clob
ノート:
サポートされているすべてのデータ型の中で、Clobデータのみがリクエスト管理UIに表示されません。
Clob型の属性を承認者専用にしないでください。
widget: このプロパティは、データ収集時にデータ属性をUIに表示する方法を指定するために使用します。このプロパティの値はString型です。次のウィジェットがサポートされています。
text: ユーザーがテキストを1行で入力できるテキスト・ボックスを指定します。たとえば、First Name属性のwidget="text"によって、「ユーザーの作成」リクエストUIの「名」フィールドがテキスト・ボックスになることが指定されます。
date: 日時型のフィールドを指定します。たとえば、Start Date属性のwidget="date"によって、「ユーザーの作成」UIの「開始日」フィールドで日付を入力として受け入れることが指定されます。
entity: エンティティ・タイプのフィールドを指定します。widget="ENTITY"を指定した場合、entity-type="ORGANIZATION"などのentity-typeプロパティの値を指定する必要があります。このことは、「ユーザーの作成」リクエストUIの「組織」フィールドでOracle Identity Managerに存在する組織を検索および選択できる組織参照が可能であることを意味します。widget=ENTITYを指定した場合、entity-typeの値をUSER、ORGANIZATIONまたはROLEにする必要があります。
ノート:
ユーザー・エンティティ定義における組織の属性名であるattr-ref要素の値を指定する必要があります。たとえば、User.xmlのattr-ref="act_key"には、ユーザー・エンティティのエンティティ定義が含まれます。
textarea: 複数行のテキストを入力するための大きいテキスト・フィールドを指定します。
dropdown: 値リスト(LOV)を指定します。widget="dropdown"を指定した場合は、lookupValues encoded-value="End User" decoded-value="Identity Only"やlookupValues encoded-value="End-User Administrator" decoded-value="End-User Administrator"などのlookupValues encoded-value要素およびdecoded-value要素のリストの値を指定する必要があります。このことは、「ユーザーの作成」リクエストUIの「ユーザー・タイプ」フィールドがLOVとして表示され、そのフィールドからユーザー・タイプ「アイデンティティのみ」または「エンドユーザー管理者」を選択できることを意味します。ただし、この章で後述するlookup-codeプロパティが定義されている場合は、lookupValuesを指定する必要はありません。
値リストの内容は次のいずれかにできます。
- データセット自体で指定されているlookupValuesの静的リスト。次に例を示します:
lookupValues encoded-value="End User" decoded-value="Identity Only" and lookupValues encoded-value="End-User Administrator" decoded-value="End-User Administrator"
- この章で後述する定義済のlookup-codeプロパティに基づく参照値のリスト。
radio: ラジオ・ボタンを指定します。
checkbox: チェック・ボックス・フィールドを指定します。このウィジェットは、Boolean型の属性参照にのみ関連付けることができます。
lookup: 多数の値から値を選択できる参照フィールドを指定します。これを使用する場合、lookup-codeプロパティを指定する必要があります。
lookup-query: lookupQuery要素に関連付けられる検索および選択ウィジェットを指定します。
itresource-lookup: ITリソースに関連付けられ、利用可能なITリソース・インスタンスを表示する検索および選択ウィジェットを指定します。このウィジェットの詳細は、「子データ」に示されている例を参照してください。
length: この属性では、データ値の長さを指定します。たとえば、First Name属性のlength="80"によって、「ユーザーの作成」リクエストUIの「名」フィールドで最大80文字の入力を受け入れることが指定されます。値は正の整数です。
available-in-bulk: 値はBoolean型です。このプロパティは、バルク・リクエストの作成中に属性参照を表示するかどうかを示します。
リクエスト・データセット内の、シングル・ユーザーのコンテキストに関連する、名、ユーザーID、パスワードなどのフィールドは、バルク・リクエスト・シナリオでそれらのフィールドをavailable-in-bulk="false"としてマークすることによって、常に非表示にできます。これは、バルク・リクエストは複数のユーザーに適用でき、シングル・ユーザー・フィールドをリクエストUIに表示しても意味がないためです。プロビジョニング・リクエストでは、プロセス・フォームに直接入力する事前移入アダプタによってこれらのシングル・ユーザー・フィールドにデータを移入できます。available-in-bulk="false"として指定した属性は、必須にできません。事前移入アダプタを使用してリクエスト・データセットを作成した場合、名、ユーザーID、パスワードなど、これらのシングル・ユーザー・フィールドには、必須制約を割り当てることはできません。シングル・ユーザーがセルフ・サービスを使用してリソースを要求する場合に便利なように、必須制約をシングル・ユーザー・フィールドに割り当てる場合は、リクエスト・データセットで、ユーザー固有のデータを移入するためのPrePopulationAdapter要素を使用します。リクエスト・データセットでPrePopulationAdapter要素を使用する方法の詳細は、「PrePopulationAdapter要素」を参照してください。
AttributeReferenceを構成するには次のオプション属性を使用できます。
required: リクエストの送信時にデータ値を指定する必要があることを示すフラグ・プロパティ。値はBoolean型です。このプロパティが指定されていない場合、使用されるデフォルト値はfalseです。
基礎となるエンティティで対応するattr-refフィールドが必須である属性参照は、required="true"として指定する必要があります。たとえば、Organizationはユーザー・エンティティの必須属性です。したがって、SelfCreateUserDataset.xmlまたはCreateUserDataSet.xml内の対応する属性参照は、このフィールドが基礎となるエンティティでも必須であることを反映して、required="true"として指定します。
Masked: データ値をマスクするかどうかを指定するために使用するフラグ・プロパティ。値がmaskedに設定されている場合、リクエスト・エンジンは常に値をアスタリスクとして表示します。値はBoolean型です。このプロパティが指定されていない場合、使用されるデフォルト値はfalseです。
approver-only: 承認者がデータ値を指定して編集する必要があることを指定するために使用されるフラグ・プロパティ。このフラグを設定すると、リクエスタは対応するデータ値を指定できません。値はBoolean型です。このプロパティが指定されていない場合、使用されるデフォルト値はfalseです。
属性がrequired="true"およびapprover-only="true"として指定されている場合、承認者はリクエストを承認する前にこの属性の値を指定する必要があります。
承認プロセスでは子表のデータの追加がサポートされていないため、承認プロセス中に子表(複数値)フィールドに指定できる値は1つのみです。
entity-type: このプロパティは、サポートされているデータ値の導出元エンティティを関連付けるために使用し、導出されたデータ値はリクエストUIから選択できます。次に例を示します:
<AttributeReference name="Organization" attr-ref="act_key" available-in-bulk="false" type="Long" length="20" widget="ENTITY" required="true" entity-type="ORGANIZATION"/>
この定義を使用すると、UIに参照ウィジェットが表示され、ユーザーはOracle Identity Managerでそのウィジェットを使用して組織を検索および選択できます。
entity-typeプロパティを定義する場合は、ウィジェットをENTITYとして定義する必要があり、UIにはユーザーがエンティティの検索および選択に使用できる参照ウィジェットが表示されます。
lookup-code: このプロパティは、定義済のlookup-codeに基づいて使用可能なLKU/LKV値をサポートされているデータとして関連付けるために使用します。次に例を示します:
<AttributeReference name="Responsibility Name" attr-ref="Name" type="String" length="30" widget="lookup" required="false" available-in-bulk="true" lookup-code="Oracle.Responsibility.Name"/>
この定義では、lookup-code Oracle.Responsibility.Nameのすべてのエンコードまたはデコードされた値をレンダリングします。
lookup-codeプロパティを定義する場合は、ウィジェットをlookupとして定義でき、UIにはユーザーが参照値の検索および選択に使用できる参照ウィジェットが表示されます。
lookup-codeを定義する場合、ウィジェットをdropdownにすることもできます。次に例を示します:
<AttributeReference name="Role" attr-ref="Role" available-in-bulk="false" type="String" length="20" widget="dropdown" lookup-code="Lookup.Users.Role" required="true"/>
この場合、ユーザー・タイプがドロップダウンとして表示され、ユーザーはいずれかの値を選択できます。
参照コードが制限された数の値に関連付けられている場合にdropdownを使用できます。ただし、参照コードが多数の値に関連付けられている場合は、値の検索および選択が可能な参照ウィジェットを使用します。
itresource-type: このプロパティは、定義済のitresource-typeの使用可能なITリソース・インスタンスを関連付けるために使用します。次に例を示します:
<AttributeReference name="Server" attr-ref="Server Name" type="String" widget="itresource-lookup" required="true" itresource-type="EBIZServer" available-in-bulk="true" length="20"/>
この定義では、EBIZServer itresource-typeのすべてのITリソース・インスタンスをレンダリングします。
itresource-typeプロパティを定義する場合は、ウィジェットをitresource-lookupとして定義する必要があり、UIにはユーザーがITリソース・インスタンスの検索および選択に使用できる参照ウィジェットが表示されます。
primary: データセット属性に複数の値を指定できるようにするかどうかを指定するために使用するフラグ・プロパティ。このフラグは、子表のコンテキストでのみデータセット属性に対して設定できます。primaryプロパティの詳細は、「子データ」を参照してください。
mls: データセット属性をマルチ言語サポート(MLS)型にするかどうかを指定するために使用するフラグ・プロパティ。値はBoolean型です。このプロパティが指定されていない場合、使用されるデフォルト値はfalseです。
entitlement: データセット属性をentitlement型にするかどうかを指定するために使用するフラグ・プロパティ。値はBoolean型です。このプロパティが指定されていない場合、使用されるデフォルト値はfalseです。
hidden: データ値を承認者に対して非表示にするかどうかを指定するために使用するフラグ・プロパティ。このデータ値は、承認者に対してのみ非表示になりますが、リクエストの送信時または他の方法でリクエスタからデータを収集することはできます。値はBoolean型です。このプロパティが指定されていない場合、使用されるデフォルト値はfalseです。
この子要素は、関連付けられるOracle Identity Managerプラグイン・クラスを定義するために使用し、このプラグイン・クラスは対応する属性のデータ値の生成に役立ちます。AttributeReference定義で各属性に最大1つのPrePopulationAdapter要素を関連付けることができます。属性値は、事前移入アダプタ・プラグインによって返された値を使用して、UIからのリクエストの作成中に事前移入されます。属性は次のとおりです:
name: この属性は、アダプタの論理名を指定するために使用します。
classname: この属性は、プラグイン・クラスの完全修飾クラス名を指定するために使用します。
ノート:
リクエスト・データセット属性がPrePopulationAdapterを使用して構成されている場合でも、その値をリクエスト・テンプレートで制限できます。その結果、事前移入は行われず、テンプレートで制限された値がリクエスト作成UIに表示されます。
次の例は、AttributeReferenceのPrePopulateAdapterを関連付ける方法を示しています。
<AttributeReference name="Organization" attr-ref="act_key" available-in-bulk="false" type="Long" length="20" widget="ENTITY" required="true" entity-type="ORGANIZATION"/> <PrePopulationAdapter name="prepopulateOrg" classname="my.sample.package.SamplePrePopulateOrg" /> </AttributeReference>
Oracle Identity Managerにmy.sample.package.SamplePrePopulateOrgクラスをプラグインとして登録する必要があります。
次の例は、Active Directory (AD)リソースをプロビジョニングするためのサンプル・データセットを示しており、事前移入が使用されています:
<?xml version="1.0" encoding="UTF-8"?>
<request-data-set xmlns="http://www.oracle.com/schema/oim/request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.oracle.com/schema/oim/request" name="ProvisionResourceAD" entity="AD" operation="PROVISION">
<AttributeReference name="Domain" attr-ref="domain" available-in-bulk="true" type="String" length="20" widget="text">
<PrePopulationAdapter classname="oracle.iam.request.DomainPrepopulateAdapter"/>
</AttributeReference>
<AttributeReference name="Login" attr-ref="login" available-in-bulk="true" type="String" length="20" widget="text"/>
<AttributeReference name="Organization" attr-ref="organization" available-in-bulk="true" type="String" length="20" widget="text" required="true">
<PrePopulationAdapter name="org" classname="oracle.iam.request.OrgPrepopulateAdapter"/>
</AttributeReference>
<AttributeReference name="EmployeeType" attr-ref="EmployeeType" available-in-bulk="true" approver-only="true" type="String" length="20" widget="text"
required="true">
</AttributeReference>
<AttributeReference name="Role" attr-ref="role"available-in-bulk="true" type="String" length="20" widget="text"><AttributeReference name="RoleName" attr-ref="role"available-in-bulk="true" type="String" length="20" widget="text" entitlement="true">
</AttributeReference>
<AttributeReference name="Description" attr-ref="description" available-in-bulk="true" type="String" length="20" widget="text">
</AttributeReference>
</AttributeReference>
</request-data-set>
ここで、Roleは子属性RoleNameおよびDescriptionを持つ子フォームです。
ADリソースをプロビジョニングするためのデータセットは、Organization属性に事前移入アダプタが関連付けられていることを示しています。Organization属性値は、事前移入アダプタ・プラグインによって返された値を使用して、リクエストの作成中に事前移入されます。
プラグインのprepopulateメソッドから返される値は、リクエスト・データセットで構成されている型に対応する型である必要があります。たとえば、「子データ」に示されている例のOrganization属性の場合は、Organization属性の型がデータセットでStringとして構成されているため、OrgPrepopulateAdapterのprepopulateメソッドではjava.lang.String型の値を返します。
AttributeReferenceの子要素であるlookupValues要素は、AttributeReference定義に関連付けられるエンティティ定義の一連の許容データ値を定義するために使用します。この要素の属性は次のとおりです。
decoded-value: UIからのリクエストの作成中にリクエスタに表示されるデータ値。
encoded-value: リクエスト・データに格納される実際のデータ値であり、データ・フローに使用されます。リクエスト作成UIから選択されたデコード済の値に基づいて、対応するエンコーディング値がリクエスト・データに格納されます。
次のサンプル・コード・スニペットは、User Typeエンティティ属性にlookupValuesを使用するAttributeReferenceを示しています。
<AttributeReference name="User Type" attr-ref="Xellerate Type" available-in-bulk="false" type="String" length="30" widget="dropdown" required="true"> <lookupValues encoded-value="End-User Admin" decoded-value="End-User Administrator"/> <lookupValues encoded-value="Identity" decoded-value="Identity"/> <lookupValues encoded-value="End-User" decoded-value="End-User"/> </AttributeReference>
User Type属性には、3つの値End-User Admin、Identity Only、End-Userのいずれかを指定できます。ただし、データ収集時には、リクエスタに対して対応するデコード済の値(それぞれEnd-User Administrator、IdentityおよびEnd-User)がドロップダウン・リストに表示されます。エンコード済の値は、データ・フローの一部としてマップされたエンティティ属性フィールドに移入されます。
AttributeReferenceのこの子要素は、SQLに基づいて一連のデータ値を動的に導出するために使用します。リクエストUIでは、定義済のlookupQueryに基づいてすべての値が参照ウィジェットに表示されます。
<AttributeReference name="adminlogin" attr-ref="adminlogin" type="String" length="20" widget="lookup-query" available-in-bulk="true">
<lookupQuery lookup-query="SELECT USR_KEY as UKEY, USR_LOGIN as ULOGIN FROM TEMP_USR where USR_TYPE='$Form Data.admintype'" display-field="ULOGIN" save-field="UKEY"/>
</AttributeReference>
この例では、SQL問合せに基づき、ユーザー・キーおよびユーザー・ログインが表temp_usrから問い合されます。この要素のプロパティは次のとおりです。
lookup-query: このプロパティの値は、Oracle Identity Managerデータベースでサポートされている汎用のSQL問合せとなります。この問合せは、同じデータセットの別の属性参照に依存できます。この例では、'$Form Data.admintype'への参照があります。このことは、属性参照adminloginが属性参照admintypeに依存していることを意味します。リクエスタが属性admintypeに指定する値は、参照で属性adminloginの値をフェッチするために使用されます。
display-field: このプロパティ値は、ユーザーが参照ウィジェットから値を選択した後、そのUI属性においてエンドユーザーに表示する必要がある、選択した列のいずれかの別名です。
save-field: このプロパティ値は、ユーザーが参照ウィジェットから値を選択した後、システムに内部的に保存する必要がある、選択した列のいずれかの別名です。
UI属性のdisplay-fieldとsave-fieldは同じにできます。
ノート:
参照問合せでは、save-fieldおよびdisplay-fieldとして使用する列の別名が必要となります。
リクエスト作成の一環として、基礎となるエンティティを参照しないデータの収集が必要になる場合があります。このことを行うために、Attribute要素を使用できます。リクエスト・データセット内に定義されるAttributeには、基礎となるエンティティへのマッピングは必要ありません。これらの属性はマッピングを必要としないため、次の方法で定義できます。
<Attribute name="ATTRIBUTE_NAME" length="10" type="integer" widget="text" available-in-bulk="false"/>
属性はリクエストの詳細に表示されます。これらは承認者が参照して承認の意思決定に使用できます。
Attribute要素はAttributeReference要素に似ていますが、相違点があります。Attribute要素のデータ値は、リクエストのコンテキストでのみ使用でき、データ・フローに関与できません。AttributeReferenceで使用できる他のすべてのプロパティは、attr-ref属性以外の属性でも使用できます。
リクエストによって収集する必要があるデータは、リクエスト・データセットのXMLファイルで定義します。次に、Create UserデータセットのサンプルXMLコードを示します:
<?xml version="1.0" encoding="UTF-8"?>
<request-data-set xmlns="http://www.oracle.com/schema/oim/request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.oracle.com/schema/oim/request" name="CreateUserDataSet" entity="User" operation="CREATE">
<DataSetValidator name="CreateUserDataValidator" classname="oracle.iam.requestactions.plugins.datavalidator.CreateUserDataValidator"/>
<AttributeReference name="First Name" attr-ref="First Name" available-in-bulk="false" type="String" length="80"
widget="text" required="false" mls="false"/>
<AttributeReference name="Middle Name" attr-ref="Middle Name" available-in-bulk="false" type="String" length="80"
widget="text" required="false" mls="false"/>
<AttributeReference name="Last Name" attr-ref="Last Name" available-in-bulk="false" type="String" length="80"
widget="text" required="true" mls="false"/>
<AttributeReference name="User Login" attr-ref="User Login" available-in-bulk="false" type="String" length="256"
widget="text" required="false"/>
<AttributeReference name="Password" attr-ref="usr_password" available-in-bulk="false" type="String" length="128"
widget="text" required="false" masked="true"/>
<AttributeReference name="Password Generated" attr-ref="Password Generated" available-in-bulk="false" type="Clob" length="1"
widget="text" required="false"/>
<AttributeReference name="Organization" attr-ref="act_key" available-in-bulk="false" type="Long" length="256"
widget="ENTITY" required="true" entity-type="ORGANIZATION"/>
<AttributeReference name="User Type" attr-ref="Xellerate Type" available-in-bulk="false" type="Boolean" length="30"
widget="checkbox" required="false"/>
<AttributeReference name="Role" attr-ref="Role" available-in-bulk="false" type="String" length="255"
widget="dropdown" lookup-code="Lookup.Users.Role" required="true"/>
<AttributeReference name="User Manager" attr-ref="usr_manager_key" available-in-bulk="false" type="Long" length="382"
widget="ENTITY" required="false" entity-type="USER"/>
<AttributeReference name="Country" attr-ref="Country" available-in-bulk="false" type="String" length="100"
widget="text" required="false"/>
<AttributeReference name="Common Name" attr-ref="Common Name" available-in-bulk="false" type="String" length="240"
widget="text" required="false" mls="false"/>
<AttributeReference name="Display Name" attr-ref="Display Name" available-in-bulk="false" type="String" length="382"
widget="text" required="false" mls="true"/>
<AttributeReference name="Department Number" attr-ref="Department Number" available-in-bulk="false" type="String" length="80"
widget="text" required="false"/>
<AttributeReference name="Description" attr-ref="Description" available-in-bulk="false" type="String" length="2000"
widget="text" required="false"/>
<AttributeReference name="Employee Number" attr-ref="Employee Number" available-in-bulk="false" type="String" length="80"
widget="text" required="false"/>
<AttributeReference name="Fax" attr-ref="Fax" available-in-bulk="false" type="String" length="20"
widget="text" required="false"/>
<AttributeReference name="Generation Qualifier" attr-ref="Generation Qualifier" available-in-bulk="false" type="String" length="20"
widget="text" required="false" mls="false"/>
<AttributeReference name="Home Phone" attr-ref="Home Phone" available-in-bulk="false" type="String" length="20"
widget="text" required="false"/>
<AttributeReference name="Hire Date" attr-ref="Hire Date" available-in-bulk="false" type="Date" length="50"
widget="date" required="false"/>
<AttributeReference name="Home Postal Address" attr-ref="Home Postal Address" available-in-bulk="false" type="String" length="256"
widget="text" required="false"/>
<AttributeReference name="Locality Name" attr-ref="Locality Name" available-in-bulk="false" type="String" length="80"
widget="text" required="false"/>
<AttributeReference name="Email" attr-ref="Email" available-in-bulk="false" type="String" length="256"
widget="text" required="false"/>
<AttributeReference name="Mobile" attr-ref="Mobile" available-in-bulk="false" type="String" length="20"
widget="text" required="false"/>
<AttributeReference name="Pager" attr-ref="Pager" available-in-bulk="false" type="String" length="20"
widget="text" required="false"/>
<AttributeReference name="Postal Address" attr-ref="Postal Address" available-in-bulk="false" type="String" length="256"
widget="text" required="false" mls="false"/>
<AttributeReference name="PO Box" attr-ref="PO Box" available-in-bulk="false" type="String" length="20"
widget="text" required="false"/>
<AttributeReference name="Postal Code" attr-ref="Postal Code" available-in-bulk="false" type="String" length="30"
widget="text" required="false"/>
<AttributeReference name="usr_locale" attr-ref="usr_locale" available-in-bulk="false" type="String" length="80"
widget="text" required="false"/>
<AttributeReference name="State" attr-ref="State" available-in-bulk="false" type="String" length="80"
widget="text" required="false" mls="false"/>
<AttributeReference name="Street" attr-ref="Street" available-in-bulk="false" type="String" length="80"
widget="text" required="false"/>
<AttributeReference name="Telephone Number" attr-ref="Telephone Number" available-in-bulk="false" type="String" length="20"
widget="text" required="false"/>
<AttributeReference name="Title" attr-ref="Title" available-in-bulk="false" type="String" length="80"
widget="text" required="false" mls="false"/>
<AttributeReference name="Initials" attr-ref="Initials" available-in-bulk="false" type="String" length="10"
widget="text" required="false"/>
<AttributeReference name="Start Date" attr-ref="Start Date" available-in-bulk="false" type="Date" length="50"
widget="date" required="false"/>
<AttributeReference name="End Date" attr-ref="End Date" available-in-bulk="false" type="Date" length="50"
widget="date" required="false"/>
<AttributeReference name="LDAP Organization Unit" attr-ref="LDAP Organization Unit" available-in-bulk="false" type="String" length="80"
widget="text" required="false" mls="false"/>
<AttributeReference name="LDAP Organization" attr-ref="LDAP Organization" available-in-bulk="false" type="String" length="80"
widget="text" required="false" mls="false"/>
<AttributeReference name="usr_timezone" attr-ref="usr_timezone" available-in-bulk="false" type="String" length="100"
widget="text" required="false" mls="false"/>
<AttributeReference name="Number Format" attr-ref="Number Format" available-in-bulk="false" type="String" length="30"
widget="dropdown" lookup-code="Lookup.Users.NumberFormat" required="false" mls="false"/>
<AttributeReference name="Currency" attr-ref="Currency" available-in-bulk="false" type="String" length="20"
widget="dropdown" lookup-code="Lookup.Users.Currency" required="false" mls="false"/>
<AttributeReference name="Date Format" attr-ref="Date Format" available-in-bulk="false" type="String" length="20"
widget="dropdown" lookup-code="Lookup.Users.DateFormat" required="false" mls="false"/>
<AttributeReference name="Time Format" attr-ref="Time Format" available-in-bulk="false" type="String" length="20"
widget="dropdown" lookup-code="Lookup.Users.TimeFormat" required="false" mls="false"/>
<AttributeReference name="Embedded Help" attr-ref="Embedded Help" available-in-bulk="false" type="String" length="10"
widget="dropdown" lookup-code="Lookup.Users.EmbeddedHelp" required="false" mls="false"/>
<AttributeReference name="Font Size" attr-ref="Font Size" available-in-bulk="false" type="String" length="10"
widget="dropdown" lookup-code="Lookup.Users.FontSize" required="false" mls="false"/>
<AttributeReference name="Color Contrast" attr-ref="Color Contrast" available-in-bulk="false" type="String" length="10"
widget="dropdown" lookup-code="Lookup.Users.ColorContrast" required="false" mls="false"/>
<AttributeReference name="Accessibility Mode" attr-ref="Accessibility Mode" available-in-bulk="false" type="String" length="20"
widget="dropdown" lookup-code="Lookup.Users.AccessibilityMode" required="false" mls="false"/>
<AttributeReference name="FA Language" attr-ref="FA Language" available-in-bulk="false" type="String" length="100"
widget="text" required="false"/>
<AttributeReference name="FA Territory" attr-ref="FA Territory" available-in-bulk="false" type="String" length="100"
widget="text" required="false"/>
<AttributeReference name="User Name Preferred Language" attr-ref="User Name Preferred Language" available-in-bulk="true" type="String" length="20" widget="lookup-query" required="false">
<lookupQuery lookup-query="select mls_locale_code as USR_NAME_PREFERRED_LANG from mls_locale where ( locale_flag=0 OR locale_flag=1 ) order by mls_locale_code asc" display-field="USR_NAME_PREFERRED_LANG" save-field="USR_NAME_PREFERRED_LANG"/>
</AttributeReference>
<Attribute name="Roles " available-in-bulk="false" type="Clob" length="2048" widget="text" required="false"/>
<Attribute name="Policy Name" available-in-bulk="false" type="Clob" length="1024" widget="text" required="false"/>
<Attribute name="RequestorID" available-in-bulk="false" type="Clob" length="1024" widget="text" required="false"/>
<Attribute name="FAOpData" available-in-bulk="false" type="Clob" length="4096" widget="text" required="false" />
</request-data-set>
他の属性で構成される複数の値または属性を格納するための属性が必要になる場合があります。そのために1つ以上の子属性を構成できます。たとえば、エンティティ・タイプUserのEmail ID属性は複数の値を格納する必要があります。このため、リクエスト・データセットで次のように構成できます。
<Attribute name="Email">
<Attribute name="ID" length="20" type="string" widget="text" />
</Attribute>
1つの属性が複数の属性で構成されるようにすることが必要になる場合もあります。たとえば、Oracle Apps User Responsibilities属性は、3つの属性(Responsibility Start Date、Responsibility End DateおよびResponsibility Name)で構成する必要があります。この属性は、リクエスト・データセットで次のように構成できます。
<AttributeReference name="Oracle Apps User Responsibilities" attr-ref="UD_RESPONS" type="String" length="20" widget="text" available-in-bulk="true">
<AttributeReference name="Responsibility Start Date" attr-ref="Responsibility Start Date" type="Date" widget="date" required="false" available-in-bulk="true" length="100" />
<AttributeReference name="Responsibility End Date" attr-ref="Responsibility End Date" type="Date" widget="date" required="false" available-in-bulk="true" length="100" />
<AttributeReference name="Responsibility Name" attr-ref="Responsibility Name" type="String" length="30" widget="lookup" required="false" available-in-bulk="true" lookup-code="Oracle.Responsibility.Name" primary="true"/>.
</AttributeReference>
ここで、Responsibility Start Date、Responsibility End DateおよびResponsibility Nameの関連付けは保持され、3つの属性でOracle Apps User Responsibilities子属性の値が構成されます。
ノート:
Oracle Identity Managerでは、1つのレベルの子属性のみがサポートされます。したがって、この例では、Responsibility Start Date、Responsibility End DateまたはResponsibility Name属性を他の属性で構成することはできません。同様に、属性参照に子属性を設定することはできません。
子表の属性では、AttributeReferenceのnameおよびattr-refを同じにする必要があります。たとえば、この項のOracle Apps User Responsibilities属性の例では、AttributeReferenceのnameおよびattr-refの両方の値がResponsibility Start Dateです。
リクエストの作成中、子データは表に表示され、ポップアップ・ウィンドウから子データを追加できます。このシナリオでは、リクエスタは開始日と終了日が同じである複数の職責を追加する必要があります。Responsibility Nameをprimaryとして指定すると、リクエスタは開始日と終了日が同じである複数の職責を選択できるようになります。
primaryプロパティを使用すると、リクエスタは、子行を追加するときに表示されるウィンドウでResponsibility Name属性に対して複数の値を選択できるようになります。Responsibility Start Date属性およびResponsibility End Date属性については、単一値のみを指定できます。これにより、開始日と終了日の値が同じである選択された職責名ごとに1行ずつ、複数の行が子表に追加されます。
次の例は、E-Businessリソースをプロビジョニングするためのリクエスト・データセットのサンプルXMLコードを示しています:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<request-data-set
xmlns = "http://www.oracle.com/schema/oim/request"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
operation = "PROVISION"
entity = "eBusiness Suite User"
name = "ProvisionResourceeBusiness Suite User"
xsi:schemaLocation = "http://www.oracle.com/schema/oim/request">
<AttributeReference
itresource-type = "eBusiness Suite UM"
available-in-bulk = "true"
required = "true"
length = "20"
widget = "itresource-lookup"
type = "Long"
attr-ref = "EBS Server"
name = "EBS Server"/>
<AttributeReference
available-in-bulk = "true"
length = "240"
widget = "text"
type = "String"
attr-ref = "Description"
name = "Description"/>
<AttributeReference
available-in-bulk = "false"
length = "240"
widget = "text"
type = "String"
attr-ref = "Email"
name = "Email"/>
<AttributeReference
available-in-bulk = "true"
length = "80"
widget = "text"
type = "String"
attr-ref = "Fax"
name = "Fax"/>
<AttributeReference
available-in-bulk = "false"
length = "256"
widget = "text"
type = "String"
attr-ref = "SSO User ID"
name = "SSO User ID"/>
<AttributeReference
available-in-bulk = "false"
length = "30"
widget = "text"
type = "String"
attr-ref = "Person ID"
name = "Person ID"/>
<AttributeReference
available-in-bulk = "true"
length = "10"
widget = "text"
type = "String"
attr-ref = "UD_EBS_RESP"
name = "eBusiness Suite Responsibilities">
<AttributeReference
name = "Application Name"
attr-ref = "Application Name"
type = "String"
length = "256"
widget = "lookup-query"
available-in-bulk = "true"
required = "true">
<lookupQuery
lookup-query = "select lkv_encoded as Value,lkv_decoded as Description from lkv lkv, lku lku where lkv.lku_key=lku.lku_key and lku_type_string_key='Lookup.EBS.Application' and instr(lkv_encoded,concat('$Form data.EBS Server', '~'))>0"
display-field = "Description"
save-field = "Value"/>
</AttributeReference>
<AttributeReference
name = "Responsibility Name"
attr-ref = "Responsibility Name"
type = "String"
length = "256"
widget = "lookup-query"
available-in-bulk = "true"
required = "true"
primary = "true">
<lookupQuery
lookup-query = "select lkv_encoded as Value,lkv_decoded as Description from lkv lkv,lku lku where lkv.lku_key=lku.lku_key and lku_type_string_key='Lookup.EBS.Responsibility' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0"
display-field = "Description"
save-field = "Value"/>
</AttributeReference>
<AttributeReference
available-in-bulk = "true"
length = "20"
widget = "date"
type = "Date"
attr-ref = "Effective Start Date"
name = "Effective Start Date"/>
</AttributeReference>
<AttributeReference
available-in-bulk = "true"
length = "10"
widget = "text"
type = "String"
attr-ref = "UD_EBS_RLS"
name = "eBusiness Suite User Role Grants">
<AttributeReference
name = "Application Name"
attr-ref = "Application Name"
type = "String"
length = "256"
widget = "lookup-query"
available-in-bulk = "true"
required = "true">
<lookupQuery
lookup-query = "select lkv_encoded as Value,lkv_decoded as Description from lkv lkv, lku lku where lkv.lku_key=lku.lku_key and lku_type_string_key='Lookup.EBS.Application' and instr(lkv_encoded,concat('$Form data.EBS Server', '~'))>0"
display-field = "Description"
save-field = "Value"/>
</AttributeReference>
<AttributeReference
name = "Role Name"
attr-ref = "Role Name"
type = "String"
length = "256"
widget = "lookup-query"
available-in-bulk = "true"
required = "true"
primary = "true">
<lookupQuery
lookup-query = "select lkv_encoded as Value,lkv_decoded as Description from lkv lkv,lku lku where lkv.lku_key=lku.lku_key and lku_type_string_key='Lookup.EBS.UMX.Roles' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0"
display-field = "Description"
save-field = "Value"/>
</AttributeReference>
<AttributeReference
available-in-bulk = "true"
length = "20"
widget = "date"
type = "Date"
attr-ref = "Start Date"
name = "Start Date"/>
</AttributeReference>
</request-data-set>
E-Businessリソース・データセットをプロビジョニングするためのサンプルXMLコードの説明は次のとおりです。
Oracle Apps User Responsibilities属性がResponsibility Start Date、Responsibility End DateおよびResponsibility Name子属性の親として定義されています。ユーザーはOracle Apps User Responsibilitiesに1つ以上の値を指定できます。リクエスト作成UIでは、これは「職責開始日」、「職責終了日」および「職責名」列を含む「Oracle Appsユーザーの職責」という見出しの表として表示されます。
親属性については、attr-refの値をプロセス・フォームの子表の名前にする必要があります。この例では、UD_RESPONSです。
Responsibility Start Date、Responsibility End DateおよびResponsibility Name属性は子表UD_RESPONSの列になります。
子属性については、attr-refの値をプロセス・フォームの子表のフィールド・ラベル値にする必要があります。
Oracle Identity Managerでは、子プロセス・フォームを定義し、それをリソースの親プロセス・フォームに関連付けることができます。親フォームの属性は、リクエスト・データセットの属性参照としてモデル化されます。子フォームの属性は、子データの属性参照としてモデル化されます。
E-Businessリソースのリソースのプロビジョニング・リクエスト・モデルに基づくリクエストの例について考えます。次の表は、親プロセス・フォームの定義の詳細および子プロセス・フォームの詳細を示しています。
| 子フォーム | 属性名 |
|---|---|
UD_RESPONS |
Responsibility Start Date |
Responsibility End Date |
|
Responsibility Name |
E-Businessリソース・データセットのプロビジョニングは、前述の例を参照してください。
AttributeReference name="Server"では、widgetの値がitresource-lookupとして指定されています。これは、「サーバー」フィールドで、ユーザーが使用可能なITリソース・パラメータを使用した参照を使用できることを示しています。widget="itresource-lookup"の場合、itresource-type要素の値を指定する必要があります。たとえば、itreource-type="EBIZServer"は、「サーバー」参照フィールドで、EBIZServer ITリソース・タイプのすべてのITリソース・パラメータを選択できることを示します。ユーザーは、この参照を使用してITリソース・インスタンスを検索および選択できます。
ノート:
ITリソース・タイプは、コネクタに関連付けられたすべてのITリソース定義のテンプレートです。ITリソース・タイプは、その特定のITリソース・タイプのすべてのITリソース・インスタンス(サーバー、コンピュータなど)に共通するパラメータを指定します。ITリソースおよびITリソース・タイプの詳細は、「コネクタ・ライフサイクルの管理」を参照してください。
関連項目:
リクエスト・テンプレートの作成ウィザードで属性を表示する方法の詳細は、「ステップ6: リクエスト・テンプレートの作成」を参照してください
Oracle Identity Managerには、すべてのリソースに共通のデフォルト・データセットがあります。共通リクエスト・データセットでは、すべてのリソースに共通の属性を定義します。
ResourceCommonDatasetは、すべてのリソースに共通のデフォルトの共通データセットです。すべてのリソースに共通のService Account属性を定義します。
その結果、選択したリソースにデータセットがない場合でも、共通データセットの属性がリクエストの作成中のリクエスト・データの収集時に表示されます。リクエスト・データの収集時には、共通データセットおよびリソース固有のデータセットの両方の属性が表示されます。つまり、リクエスト収集データは、共通データセットおよびエンティティに関連付けられているデータセットを結合したものです。
ノート:
共通リクエスト・データセットは、Oracle Identity Managerに付属しており、カスタマイズできません。
すべてのデフォルトのリクエスト・データセットには、データセット属性の翻訳があります。ただし、作成したカスタム・リクエスト・データセットについては、そのデータセット属性のローカライゼーションをカスタム・リソース・バンドルに追加する必要があります。
ここでは、次の各項でリクエスト・データセットおよびデータセット属性のローカライズされた値の構成について説明します。
この項では、データセット属性のローカライゼーション・サポートを有効にするための規則について説明します。たとえば、CreateUserDataSet.xmlでは、role属性が次のように定義されています。
<AttributeReference name="Role" attr-ref="Role" available-in-bulk="false" type="String" length="20" widget="dropdown" lookup-code="Lookup.Users.Role" required="true"/>
この属性の翻訳は次のように構成されています。
request.dataset.User.Role=USER_TYPE
ここで、request.dataset.User.Roleは翻訳キー、USER_TYPEは実際の翻訳または翻訳値です。翻訳キーをフレーム化すると実際の翻訳が決定されます。リクエスト・データセット属性に関連する翻訳キーは、request.datasetで始まる必要があります。この後に、属性のエンティティ・タイプ、エンティティ・サブタイプ(存在する場合)、親属性名(存在する場合)、属性名、事前定義された値などのオブジェクト名が続きます。翻訳キーのタイプは、次のように分類されます。
非汎用リクエスト・モデルのリクエスト・データセットの翻訳キーには、エンティティ・サブタイプがデータセットに存在しないため、エンティティ・サブタイプを含めないでください。たとえば、CreateUserDataSet.xml内のRole属性は、次のように定義されています。
<AttributeReference name="Role" attr-ref="Role" available-in-bulk="false" type="String" length="20" widget="dropdown" lookup-code="Lookup.Users.Role" required="true"/>
翻訳キーは次のとおりです。
request.dataset.User.Role
説明:
request.datasetは、データセット属性の先頭に必要な固定文字列です。
Userはエンティティ・タイプに対応します。これは、CreateUserRequestModel.xmlファイル内のrequest-model要素のentity-typeプロパティと同じである必要があります。リクエスト・モデルに応じてResourceまたはRoleにできます。
Roleは、翻訳が追加される実際の属性に対応します。データセット内のRole属性参照のnameプロパティに対応します。
汎用リクエスト・モデルのリクエスト・データセットの翻訳キーには、エンティティ・サブタイプを含める必要があります。たとえば、ProvisionResourceeBusiness Suite User.xml内のEBS Server属性については、次のように定義する必要があります。
<AttributeReference name="EBS Server" attr-ref="EBS Server" type="Long" widget="itresource-lookup" required="true" available-in-bulk="true" itresource-type="eBusiness Suite UM" length="40"/>
翻訳キーは次のとおりです。
request.dataset.Resource.eBusiness\ Suite\ User.EBS\ Server=EBS Server
説明:
request.datasetは、データセット属性の先頭に必要な固定文字列です。
Resourceは、ProvisionResourceRequest.xmlファイル内のエンティティ・タイプに対応します。
eBusiness\ Suite\ Userはエンティティ・サブタイプであり、ProvisionResourceeBusiness Suite User.xml内のrequest-data-set要素のentityプロパティと同じです。これはオプションであり、この例ではリソースのプロビジョニング・リクエスト・モデルが汎用タイプであるために含まれています。
EBS\ Serverは、翻訳が追加される実際の属性に対応します。データセット内のEBS Server属性参照のnameプロパティに対応します。
子属性については、翻訳キーにさらに親属性名が含まれ、これは属性を一意に識別するために必要です。たとえば、ProvisionResourceeBusiness Suite User.xml内のApplication Name属性は次のとおりです。
<AttributeReference available-in-bulk="true" length="10" widget="text" type="String" attr-ref="UD_EBS_RESP" name="EBS_RSO">
<AttributeReference name="Application Name" attr-ref="APPLICATION_NAME" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="true">
<lookupQuery lookup-query="select lkv_encoded,lkv_decoded from lkv lkv, lku lku where lkv.lku_key=lku.lku_key and lku_type_string_key='Lookup.EBS.Application' and instr(lkv_encoded,concat('$Form data.EBS Server', '~'))>0" display-field="lkv_decoded" save-field="lkv_encoded"/>
</AttributeReference>
</AttributeReference>
APPLICATION_NAMEはEBS_RSO属性の子属性です。APPLICATION_NAMEの翻訳キーの構成は次のとおりです。
request.dataset.Resource.eBusiness\ Suite\ User.EBS_RSO.Application\ Name = APPLICATION_NAME
request.datasetは、データセット属性の先頭に必要な固定文字列です。
Resourceは、ProvisionResourceRequest.xmlファイル内のエンティティ・タイプに対応します。
eBusiness\ Suite\ Userは、ProvisionResourceeBusiness Suite User.xml内のrequest-data-set要素のentityプロパティです。これはエンティティ・サブタイプとも呼ばれます。これはオプションであり、この例ではリソースのプロビジョニング・リクエスト・モデルが汎用タイプであるために含まれています。
EBS_RSOはEffective Start Date属性の親属性であり、これにより一意に識別されます。EBS_RSO属性参照のnameプロパティに対応します。
Application\ Nameは、翻訳が追加される実際の属性に対応します。APPLICATION_NAME属性参照のnameプロパティに対応します。
参照値やlookup-code値などの一連の事前定義された値を持つ属性を設定できます。これらの値はユーザー・インタフェースに表示されるため、これらの値についても翻訳を追加できます。このタイプの値の翻訳キーは、子属性の翻訳キーに似ています。たとえば、CreateUserDataSet.xmlリクエスト・データセット内のRole属性には、Employee、Full-Time Employee、Part-Time Employeeなどの事前定義された値があります。これらの値は、ユーザー作成のリクエストのUIにドロップダウンとして表示されます。コードLookup.Users.Roleを使用して参照定義を構成することによって事前定義されています。次の例に示すように、Role AttributeReferenceでlookup-code="Lookup.Users.Role"として指定されています。
<AttributeReference name="Role" attr-ref="Role" available-in-bulk="false" type="String" length="20" widget="dropdown" lookup-code="Lookup.Users.Role" required="true"/>
Role属性のEmployee値の翻訳は次のとおりです。
request.dataset.User.Role.LOV.Employee=Employee
説明:
request.datasetは、すべてのデータセット属性に接頭辞として付加する必要がある固定部分です。
Userはエンティティ・タイプに対応します。
Roleは、Employeeが事前定義された値である実際の属性に対応します。データセット内のRole AttributeReferenceのnameプロパティに対応します。
LOVは、LOVに続く文字列がRoleの事前定義された値であることを示すために追加されています。
Employeeは、翻訳が追加される事前定義された値です。これは、参照定義のDecode列の値にする必要があります。
ノート:
参照定義には、Code Key列およびDecode列があります。たとえば、Code Key = EMP、Decode=Employeeのように指定します。
デフォルトのリクエスト・データセット内の属性はすでに存在します。ただし、新しい属性をデータセットに追加する場合は、この項で説明した方法と同じ方法でこれらの属性の翻訳を分類に応じて追加することもできます。
リクエスト・データセットには、lookup-queryタイプの属性が存在する場合があります。次に例を示します:
<AttributeReference name="Application Name" attr-ref="APPLICATION_NAME" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="true"> <lookupQuery lookup-query="select lkv_encoded as Application Key,lkv_decoded as Application Name from lkv lkv, lku lku where lkv.lku_key=lku.lku_key and lku_type_string_key='Lookup.EBS.Application'" display-field="APPLICATION_NAME" save-field="APPLICATION_KEY"/> </AttributeReference>
問合せで指定された列は、リクエストの作成中のデータ収集ステップでUIに表示されます。列の別名をリソース・バンドルのキーとして追加することで、列名lkv_encodedおよびlkv_decodedをローカライズできます。たとえば、この問合せでは、Application KeyおよびApplication Nameがそれぞれlkv_encoded列およびlkv_decoded列の別名です。次のように、カスタム・リソース・バンドルに翻訳を追加してローカライズできます。
Application\ Key=APPLICATION_KEY
Application\ Name=APPLICATION_NAME
リクエスト・データセットのXMLファイルの作成後、そのファイルをMDSにアップロードする必要があり、そのためにはOracle Identity ManagerのMDSインポートおよびエクスポート・ユーティリティ・ツールを使用します。アップロードが完了すると、リクエストの作成中にリクエスト・エンジンによってデータセットがロードされ、属性参照および属性がデータ収集ステップに表示されます。同様に、同じツールを使用して、MDSリポジトリからデータセット・ファイルを削除またはエクスポートできます。
リクエスト・データセットをMDSにアップロードするには:
ノート:
リソース要件の変更に応じてデータセットを更新する必要があります。
既存のデータセットを更新するには、そのデータセットを使用する保留中のリクエストがないことを確認します。
weblogic.propertiesファイルのmetadata_from_locプロパティで、XMLファイルのインポート元の最上位ディレクトリを指定します。リクエスト・データセットを格納するためのサブディレクトリを作成し、データセットをこのディレクトリにコピーします。/custom/RESOURCE_NAMEなどのサブディレクトリ構造を作成することをお薦めします。たとえば、metadata_from_locプロパティを/scratch/datasets/uploadに設定し、EBSリソースのデータセットを作成した場合、データセットは/scratch/datasets/upload/custom/EBS/ディレクトリに配置されます。
ノート:
このディレクトリに必要なデータセットのみが格納され、他のファイルがないことを確認します。
OIM_HOME/binディレクトリに移動し、weblogicImportMetadata.shまたはweblogicImportMetadata.batスクリプトを実行します。これを実行するために、MDSユーティリティの環境を次のようにセットアップします。
OIM_ORACLE_HOME環境変数をMiddlewareホーム・ディレクトリ内のOracle Identity ManagementのOracleホーム・ディレクトリに設定します。たとえば、Microsoft Windowsの場合は、OIM_ORACLE_HOME環境変数をC:\Oracle\Middleware\Oracle_IDM1\ディレクトリに設定します。
ユーティリティと同じフォルダにあるweblogic.propertiesファイルで必要なプロパティを設定します。
表A-3 プロパティ・ファイルのパラメータ
| プロパティ名 | 説明 | ノート |
|---|---|---|
wls_servername |
Oracle Identity ManagerがデプロイされているOracle WebLogic Serverの名前。 |
|
application_name |
アプリケーション名 |
値は次のとおりです:
カスタム・データをインポートまたはエクスポートする場合は、application_nameを |
metadata_from_loc |
XMLファイルのインポート元となるディレクトリの場所。このプロパティは、weblogicImportMetadata.shスクリプトで使用されます。 |
Microsoft Windowsのパスには、ファイルまたはディレクトリのセパレータとして//が含まれます。 |
metadata_to_loc |
XMLファイルのエクスポート先となるディレクトリの場所。このプロパティは、weblogicExportMetadata.shスクリプトで使用されます。 |
Microsoft Windowsのパスには、ファイルまたはディレクトリのセパレータとして//が含まれます。 |
metadata_files |
XMLファイルのフルパスと名前。このプロパティは、weblogicExportMetadata.shスクリプトおよびweblogicDeleteMetadata.shスクリプトで使用されます。 |
たとえば、/file/User.xmlを指定して、ユーザー・エンティティ定義をエクスポートします。複数のxmlファイルをカンマ区切りの値として指定できます。 |
インポート・ユーティリティの使用方法: weblogicImportMetadata.shユーティリティを実行すると、metadata_from_locに指定されているすべてのファイルがインポートされます。
たとえば、/scratch/johnny/temp/oim/file/User.xmlのUser.xmlをインポートするとします。この場合、metadata_from_loc を/scratch/johnny/temp/oimとして定義する必要があります。
警告:
metadata_from_locで指定したディレクトリまたはそのサブディレクトリにその他のファイルが存在しないことを確認してください。インポート・ユーティリティでは、そのディレクトリの下のすべてのファイルを再帰的にインポートすることを試みます。
すべてのインポート・ユーティリティ、エクスポート・ユーティリティおよび削除ユーティリティは、OIM_ORACLE_HOME/server/bin/ディレクトリに配置されています。
エクスポート・ユーティリティの使用方法: weblogicExportMetadata.shユーティリティを実行すると、metadata_filesに指定されているファイルがmetadata_to_locによって指定されているフォルダにエクスポートされます。
ノート:
ファイル名にスペースが含まれている場合は、引用符などのエスケープ文字を使用しないでファイル名をそのまま指定する必要があります。たとえば、ProvisionResourceeBusiness Suite User.xmlという名前のファイルをエクスポートする場合(パスは/db/ProvisionResourceeBusiness Suite User.xml)、メタデータ・ファイル・プロパティを次のように指定する必要があります。
metadata_files=/db/ProvisionResourceeBusiness Suite User.xml
削除ユーティリティの使用方法: weblogicDeleteMetadata.shユーティリティを実行すると、metadata_filesに指定されているファイルがMDSから削除されます。
ノート:
ファイル名にスペースが含まれている場合は、引用符などのエスケープ文字を使用しないでファイル名をそのまま指定する必要があります。たとえば、ProvisionResourceeBusiness Suite User.xmlという名前のファイルを削除する場合(パスは/db/ProvisionResourceeBusiness Suite User.xml)、メタデータ・ファイル・プロパティを次のように指定する必要があります。
metadata_files=/db/ProvisionResourceeBusiness Suite User.xml
プロビジョニング・システムの主な目的は、ユーザーによって送信されたリクエストを管理し、ユーザーに対してリソースをプロビジョニングすることです。リクエストの実行には、関連する承認プロセスの実行も含まれます。承認プロセスは、SOAサーバーで実行されるサービス指向アーキテクチャ(SOA)コンポジットとしてデプロイされます。リクエスト・サービスによって、このような承認プロセスが実行され、管理されます。
このセクションには次のトピックが含まれます:
Oracle Identity ManagerとSOAサーバーの間の相互作用について、次のステップで説明します。
ユーザーは、Oracle Identity Managerセルフ・サービスを使用してリクエストを作成します。Oracle Identity Managerでサポートされているすべてのリクエスト・タイプのうち、任意のタイプのリクエストを作成できます。
リクエスト・サービスによって承認ポリシーが評価され、インスタンス化されるSOAコンポジットが選択されます。
ノート:
このコンポジットは、リクエストの送信時に開始されるようにOracle Identity Managerに登録されている必要があります。Oracle Identity Managerでのワークフローの登録の詳細は、「ステップ4: Oracle Identity ManagerへのSOAコンポジットの登録」を参照してください。
リクエスト・サービスがSOAサーバーに接続して、選択されたSOAコンポジットをインスタンス化します。SOAサーバーで選択されているコンポジット・インスタンスをインスタンス化します。
SOAコンポジットの実行が開始され、ヒューマン承認タスクが承認用に割り当てられます。
承認者がOracle Identity Managerセルフ・サービス・コンソールの「タスク・リスト」にログインして、リクエストを承認します。
承認後にコンポジット・インスタンスの実行が完了し、リクエスト・サービスに通知されます。
リクエスト・サービスによってリクエストが次のステージに移動します。
Oracle Identity Managerには、いくつかの事前定義されたSOAコンポジットが用意されています。ただし、独自のコンポジットを定義し、それをリクエスト承認で使用できます。
SOAコンポジットを承認プロセスとして使用するには、SOAコンポジットが特定の基準に準拠している必要があります。このような基準によって、リクエスト・サービスはコンポジットを適切にインスタンス化し、管理できます。基準は次のとおりです:
次の属性はBPELプロセスに必須です。
タイプが文字列のRequestID
タイプが文字列のRequestModel
タイプが文字列のRequestTarget
タイプが文字列のURL
XML要素のRequesterDetails
XML要素のBeneficiaryDetails
XML要素のObjectDetails
XML要素のOtherDetails
RequestID、RequestModel、RequestTargetおよびURL属性には、常に、すべてのタイプのリクエストの有効な値が設定されます。
RequesterDetailsはXML要素です。この要素には、認証を必要とするすべてのリクエストの有効な値が入力されます。タイプが自己登録ユーザーのリクエストは、リクエスタが匿名ユーザーのため、リクエスタの詳細が空です。
BeneficiaryDetailsはXML要素です。この要素には、「リソースのプロビジョニング」、「ロールの割当て」など、受益者があるすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1人の受益者に関連している場合にのみ入力されます。リクエストが複数の受益者に関連している場合、BeneficiaryDetailsは空になります。BeneficiaryDetails要素には、常に、受益者がある単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1人の受益者にのみ関連付けられているためです。
ObjectDetailsはXML要素です。この要素には、リソース・エンティティに関連付けられているすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1つのリソースに関連している場合にのみ入力されます。リクエストが複数のリソースに関連している場合、ObjectDetailsは空になります。ObjectDetails要素には、常に、リソースに関連付けられている単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1つのリソースにのみ関連付けられているためです。
BPELプロセスに必須のすべての属性は、RequestDetails.xsdおよびApprovalProcess.xsdから参照されます。これらのファイルは、変更または削除できないテンプレートSOAコンポジットにあります。
Oracle Identity Managerでは、カスタムSOAコンポジットを作成するヘルパー・ユーティリティが提供されます。このユーティリティでは、必要な基準のすべてに準拠したテンプレートSOAプロジェクトが作成されます。このユーティリティは、OIM_HOME/workflows/new-workflowディレクトリに配置されています。
ノート:
JAVA_HOME環境変数を設定してから、このユーティリティを実行する必要があります。
このユーティリティには、Apache Antバージョン1.7以上が必要です。
ヘルパー・ユーティリティを実行してカスタムSOAコンポジットを作成するには:
OIM_HOME/workflows/new-workflow/process-template/ディレクトリに新規アプリケーションが作成されます。新規アプリケーションは、JDeveloperで開いて変更できます。
テンプレートSOAコンポジットのヒューマン・タスクは、ヒューマン・タスクの割当て先に通知を送信するよう構成されています。作成されたカスタム・コンポジットでは、要件に応じて通知メッセージを変更できます。承認者に送信されるすべての通知は、SOAコンポジットで構成する必要があります。通知を送信するためのOracle SOAサーバーの構成は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のSOAおよびUser Messaging Serviceのインストールおよび構成に関する項を参照してください。
テンプレートSOAコンポジットのヒューマン・タスクは、SYSTEM ADMINISTRATORSロールに割り当てられるよう構成されています。
ノート:
Oracle Identity Managerとの通信でSSLモードを使用している場合、SSLモードを介したOracle Identity Managerとの通信のための次の前提条件を実行する必要があります。
TRUSTSTORE_LOCATION環境変数を設定します(TRUSTSTORE_LOCATIONは信頼できるキー・ストア・ファイルの場所です)。
t3プロトコルではなくt3sプロトコルを使用します。たとえば、Oracle Identity ManagerのURLは次のようになります。
t3s://HOST_NAME:PORT
SOAコンポジットはOracle Identity Managerに登録してから、承認プロセスとして使用する必要があります。SOAコンポジットをOracle Identity Managerに登録するには:
リクエストは、実行されるまでに複数の承認を通過します。リクエストの送信後、様々なレベルで承認を得る必要があります。承認は、一連の承認ポリシーによって制御および構成されます。
承認者はリクエスト・データを表示できます。リクエスタによって提供されたデータを変更することはできません。リクエスト・データセットでapprover-only="true"として設定された属性のデータのみを指定できます。
この節では、以下のトピックについて説明します。
リクエストの送信後、承認を開始する必要がある場合は、リクエスト・サービスによってバックエンド・ワークフロー・エンジンでワークフロー・プロセスが開始されます。Oracle SOAがリクエスト・サービスによってワークフロー・エンジンとして使用されます。
SOAサーバーはSOAコンポジットおよびヒューマン・ワークフローをホストします。リクエスト・サービスとSOAの統合については、configuring-requests.htm#GUID-638F3446-E4BF-4EC7-B2AD-B3F5F8F6DD03__CIHJICEIが参考になります。
次のプロセスでは、承認ワークフローを選択するためにOracle SOAがリクエスト・サービスとどのように連携するかについて説明します。
リクエスト管理UI(Oracle Identity Managerセルフ・サービスまたは拡張管理)を使用して、リクエストを作成します。
リクエストを送信すると、Oracle SOAにデプロイされるSOAコンポジットがリクエスト・エンジンによって呼び出されます。
ノート:
Oracle SOAはOracle identity Managerとは無関係です。バックエンドのBusiness Process Execution Language(BPEL)サービスによって承認ワークフローが開始されます。Oracle Identity Managerに付属のデフォルトのBPELワークフロー以外に、要件に合わせてBPELに独自のワークフローを定義できます。BPELワークフローのカスタマイズの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のOracle BPEL Process Managerのスタート・ガイドに関する項を参照してください。
Oracle SOAでは、Java Platform Security(JPS)を使用してSOAコンポジット・ロジックでリクエストを割り当てるユーザーを決定します。Oracle Identity Managerと同じユーザーおよびロールのセットが使用されます。これは、Oracle Identity Managerデータ・プロバイダによって有効化されます。
Oracle SOAでは、DBプロバイダによって提供された情報に基づいてタスクを割当て先に割り当てます。
ログイン・ユーザーおよびロールに割り当てられたタスクのリストがTaskList UIに表示されます。
承認者は、TaskListを使用してリクエストを承認または拒否します。
承認結果がSOA経由でリクエスト・エンジンに返送されます。
リクエストが承認された場合、次のアクションはリクエスト・タイプ、受益者または関連リソースに基づいて決定されます。リクエストが拒否された場合は、リクエストの処理が終了します。
タスクが割り当てられると、ユーザーはOracle Identity Managerセルフ・サービスでTaskList UIにログインして、ヒューマン・タスクおよびOracle Identity Managerリクエストの統合されたビューを表示できます。
TaskListでは、Oracle SOAとの通信にタスク問合せサービスAPIが使用されます。これらのAPIはOracle SOAサーバーによって提供されます。Oracle Identity Managerは、構成に基づいてSOAPまたはRMIプロトコルを使用してOracle SOAと通信します。RMIがデフォルトのプロトコルです。
各要求は3つのレベル(テンプレート・レベル、リクエスト・レベルおよび操作レベル)の承認を経由する必要がある場合があります。SOAコンポジットをOracle Identity Managerで承認プロセスとして使用するには、これらをOracle Identity Managerに登録する必要があります。登録すると、Oracle Identity Managerはデプロイして実行時に使用できる承認プロセスを把握できます。
承認レベルについては、以降の各項で説明します。
これらは、リクエスト・テンプレートに定義される承認です。各テンプレートでは、承認ポリシー構成で定義されている承認の上位に、追加の承認を定義できます。このレベルでは、リクエスト全体が承認または拒否されます。バルク・リクエストの場合、部分的に承認または拒否されることはありません。各テンプレートについて、テンプレート・レベルで開始する必要があるオプションの承認プロセスを定義できます。テンプレートに承認プロセスが定義されていない場合は、テンプレート・レベルが自動承認されます。
ノート:
リクエスト・レベルおよび操作レベルの承認は、承認ポリシーに関連付けられます。テンプレート・レベルの承認には、承認ポリシーは関連付けられません。承認プロセスはテンプレートで定義され、承認ポリシーとの関連付けなしに直接実行されます。
たとえば、すべての契約社員のユーザーを作成するときに、社員のマネージャおよびIT管理者による承認に加えて、人事担当による承認が必要となる場合などに、テンプレート・レベルの承認を使用します。人事担当によるこの追加の承認は、テンプレートの作成中に承認プロセスとして構成できます。テンプレートを使用してリクエストを作成および送信できます。
ノート:
このレベルの承認は、子リクエストには必要ありません。
これらはリクエスト全体に対する承認です。承認ポリシー構成に基づきます。
たとえば、ユーザーに対してラップトップをプロビジョニングするためのリクエストが生成されたときに、リクエスタのマネージャによる承認が必要となる場合などに、リクエスト・レベルの承認を使用します。
リクエストに対するリクエスト・レベルの承認に、どの承認プロセスを使用する必要があるかは、リクエスト・レベルで定義される承認ポリシーによって決定されます。指定されたタイプのリクエストに対してリクエスト・レベルの承認ポリシーが定義されていない場合は、デフォルトのリクエスト承認プロセスが使用されます。デフォルトでは、すべてのリクエスト・レベルの承認が管理者に割り当てられます。このため、デフォルトの構成は安全です。複数の承認ポリシーが存在する場合は、承認ポリシー優先度の順に承認ポリシー・ルールが評価され、適切な承認ポリシーが特定されます。承認ポリシー・ルールでは、リクエスト・エンジンに対し、特定の承認についてどの承認プロセスを選択するかを示します。リクエスト・エンジンは、承認ポリシー・ルールの評価に基づいて選択された承認ポリシーに定義されている、承認プロセスを選択します。
たとえば、ユーザーを作成するためのリクエストが送信されると、承認ポリシーの選択方法を使用して、優先度順に、ユーザーの作成リクエスト・モデルについて存在する承認ポリシーの数が確認されます。承認ポリシー優先度が最も高い承認ポリシー・ルールが評価されます。承認ポリシー・ルールの例として、マネージャの名および姓がそれぞれJohnおよびDoeである必要があるというルールがあります。優先度が最も高い承認ポリシー・ルールが一致しない場合は、承認ポリシー優先度が次に高い承認ポリシー・ルールが評価されます。最初の承認ポリシー・ルールが承認ポリシーで指定されている基準に一致する場合は、その承認ポリシーの対応する承認プロセスがリクエスト・レベルでそのリクエストに対して選択されます。すべての承認ポリシー・ルールが一致しない場合は、リクエスト・レベルのデフォルトの承認プロセスが選択されます。
ノート:
バルク・リクエストがリクエスト・レベルで正常に承認された後、バルク・リクエストが子リクエストに分割されるため、子リクエストにはリクエスト・レベルの承認は必要ありません。
「ユーザーの自己登録」リクエスト・テンプレートには、approver-only属性としてorganizationがあります。したがって、属性は必須で承認者が指定する必要があるため、このテンプレートに関連付けられている承認ポリシーにはリクエスト・レベルで自動承認を設定しないでください。
これらは、このリクエスト・タイプによって実行される操作に対する承認です。このレベルでは、承認選択方法の名前およびパラメータを方法に渡す必要があります。方法によってこの操作に使用する承認ワークフローが提示されます。リクエスト・タイプおよびスコープでも、承認プロセスの決定に必要な方法固有のパラメータを定義できます。configuring-requests.htm#GUID-3002B685-579E-4FD3-95EE-623765003E56__CIHCFBCIに示すように、スコープはリクエスト・タイプのタイプに関連付けられたキーです。
表A-4 リクエスト・タイプおよび関連付けられているキー
| リクエスト・タイプ | スコープ |
|---|---|
ユーザー・エンティティに関連するすべてのリクエスト・タイプ:
|
organization |
リソースに関連するすべてのリクエスト・モデル:
|
resource |
ロール・エンティティに関連するすべてのリクエスト・タイプ:
|
role |
ノート:
ロールの作成、ロールの変更およびロールの削除タイプでは、操作レベルの承認が自動承認されます。
たとえば、リソースのプロビジョニング・タイプのリクエストでは、スコープに基づき、承認ポリシーを作成するときに、承認ポリシーを操作レベルで関連付けるリソースを選択する必要があります。同様に、承認ポリシーを作成するとき、ユーザーの作成リクエスト・タイプでは組織を、ロールの割当てリクエスト・タイプではロールを操作レベルで選択する必要があります。
作成した承認ポリシー、承認ポリシー優先度、承認ポリシー・ルールおよびスコープによって、操作レベルでリクエストに対して選択する承認プロセスが決定されます。
たとえば、ユーザーに対してラップトップをプロビジョニングするためのリクエスト・レベルの承認が取得された後、ユーザーに対してラップトップを発行するIT管理者による承認が必要となる場合などに、操作レベルの承認を使用します。
バルク・リクエストの場合、個々の子リクエストに対して操作レベルの承認が必要です。個々の子リクエストは個別に承認または拒否できます。たとえば、ユーザーへのリソースのプロビジョニング・リクエストの場合、複数の受益者、複数のリソースまたは両方が存在する可能性があります。したがって、操作レベルでは、各ユーザーに対する各リソースのプロビジョニングによって子リクエストが生成され、その子リクエストを個別に承認または拒否できます。
承認に適切なSOAコンポジットを選択するには、必要な承認ポリシーを作成します。承認に関連する概念は、「ステップ5: リクエスト承認の定義」を参照してください。
承認ポリシーを作成するには:
このセクションには次のトピックが含まれます:
リクエスト・テンプレートを使用すると、目的に合わせてリクエストをカスタマイズできます。つまり、UIの様々な機能を制御することで、リクエストの属性を制御できます。たとえば、全契約社員に対してユーザー作成のリクエストを作成し、特定の値が設定された属性を指定する場合は、「ユーザーの作成」リクエスト・タイプをカスタマイズして、リクエストのカスタマイズが可能なリクエスト・テンプレートを作成できます。リクエスト・テンプレートを作成することで、全従業員に「XYZ Inc.」という組織を適用したり、契約社員すべてのユーザー・タイプが「パート従業員」となるように指定できます。
リクエスト作成用テンプレートに対するアクセス権は、テンプレートに定義されたロール割当てに基づきます。リクエスト・テンプレートの作成後、そのテンプレートを使用できるのは、テンプレートに割り当てられているロールを持つユーザーのみです。
デフォルトのテンプレートは、各リクエスト・タイプにあらかじめ定義されています。これらの事前定義テンプレートを削除したり、名前を変更することはできません。これらの事前定義テンプレートには、対応するモデルと同じ名前が指定されています。
リクエスト・テンプレートは、次の目的に使用できます。
テンプレート・レベル承認の追加: テンプレートの作成時に、リクエスト・レベルおよび操作レベルとは別に、その他の承認レベルを追加できます。
制限の追加: 次のことができます。
エンティティ制限の追加: リクエスト・テンプレートを使用して選択できるエンティティ・タイプの制限を指定できます。たとえば、「リソースのプロビジョニング」というリクエスト・タイプのテンプレートでは、このテンプレートを使用して選択できる有効なリソースの数を指定できるとします。これにより、汎用リクエストの場合に、テンプレートの使用を特定のタイプのエンティティに制限します。たとえば、プロビジョニング・リクエスト・タイプについて定義されたテンプレートでは、このテンプレートをActive Directory、ExchangeおよびUNIXのリソースにのみ使用するように指定できます。
ノート:
テンプレートでエンティティ・タイプが制限されていない場合は、このテンプレートを使用してリクエストを作成する際、使用可能なすべてのエンティティ・タイプがリクエスタに表示されます。
一方、リクエスト・ライフサイクルの様々なフェーズで収集されるデータは、リクエスト・データセットによって制御されます。
属性のデータ値の制限: 属性に単一の値を指定すると、属性のそのデフォルト値が設定され、その属性はUIに表示されません。複数の値を指定すると、値は値リスト(LOV)としてユーザーに表示され、ユーザーはこのリストから値を選択できます。
属性の制限は、次のタイプになります。
リクエスト・テンプレートで、属性に単一のデフォルト値を指定します。このテンプレートを使用してリクエストを作成している間、この属性はリクエスタに表示されません。この属性および対応する値は、リクエスト・データに自動的に設定されます。
リクエスト・テンプレートで、複数の値を使用して属性を制限します。このような複数の値を指定すると、値は値リスト(LOV)として表示され、このテンプレートを使用してリクエストを作成するときに、リクエスタはこのリストから値を選択できます。
「ユーザーがこの属性の値を入力できないようにします」オプションを選択することで、リクエスト・テンプレートで、値を使用せずに属性を制限します。このタイプの制限は、必須以外の属性に対してのみ使用できます。この制限では、このテンプレートを使用してリクエストを作成している間、この属性はリクエスタに表示されません。この属性は、リクエスト・データの要素ではなくなります。
その他のデータ収集属性の追加: これらの属性はエンティティには関連付けられません。このメカニズムを使用して収集されたデータは、リクエストの実行時には使用できません。ただし、レポート目的、リクエストの検証、および送信後データ・アクション・ハンドラに使用できます。
その他のデータ収集ステップで、リクエスト作成時にリクエスタに表示されるリクエスト・テンプレートに新しい属性を定義できます。これらの属性は、このテンプレートに固有で、エンティティには関連付けられません。
エンド・ユーザーの使用を制限するためのテンプレートへのロールの割当て: テンプレートに対して適切なロールが割り当てられているメンバーのみが、そのテンプレートを使用してリクエストを作成できます。
要約すると、リクエスト・テンプレートを使用して、次のことができます。
制限されたエンティティ・タイプを指定できます。
エンティティに対するリクエストの一部としての収集が不要な制限された属性を指定できます。
属性を単一の値または値リストに制限できます。単一の値のみを指定すると、リクエストの送信時に、その属性はリクエスタには表示されません。値リストを指定した場合は、リクエスタが値リストから単一の値を選択する必要があります。
その他のデータ収集属性を指定できます。
エンド・ユーザーによる使用を制限するために、ロールをテンプレートに割り当てることができます。
テンプレート管理サービスでは、誰がどのような操作を実行できるかを判断するために、Oracle Entitlements Server (OES)を内部的に使用します。リクエスト・テンプレート認可のOESポリシーにより、リクエスト・テンプレート管理者ロールを持つユーザーにのみ、リクエスト・テンプレートの作成またはクローン、検索、変更および削除を認可するように指定されます。
リクエスト・テンプレート管理者ロールに属しているユーザーは、リクエスト管理のUIでリクエスト・テンプレートの作成ウィザードを使用してリクエスト・テンプレートを作成できます。ウィザードの各ステップは、第1ステップでのリクエスト・タイプの選択と、リソース・ベースのリクエスト・タイプに対するリソースの選択に基づいて動的に生成されます。
リクエスト・テンプレートの作成について、次のシナリオを使用して説明します。
「ユーザーの作成」リクエスト・タイプに基づいてリクエスト・テンプレートを作成するには:
リクエスト・テンプレートを作成する権限のある資格証明を使用して、Oracle Identity Manager管理およびユーザー・コンソールにログインします。
ノート:
リクエスト・テンプレート管理者ロールのメンバーであるユーザーは、リクエスト・テンプレートを作成できます。適切なロールがユーザーに割り当てられていない場合、ユーザーはリクエスト・テンプレートを作成するために必要なUIオプションを使用できません。
「拡張」をクリックして、Oracle Identity Manager拡張管理を開きます。
「構成」タブをクリックし、次に「リクエスト・テンプレート」をクリックします。または、「ようこそ」ページの「構成」の下にある「リクエスト・テンプレートの検索」リンクをクリックします。
左ペインの「アクション」メニューから、「作成」を選択します。または、ツールバーにある「リクエスト・テンプレートの作成」アイコンをクリックします。リクエスト・テンプレートの作成ウィザードの「リクエスト・テンプレートの詳細の設定」ページが表示されます。
次のフィールドに値を入力し、「次」をクリックします。
リクエスト・テンプレート名: 作成するテンプレートの名前を入力します(たとえば、契約者の作成)。
リクエスト・タイプ: リクエスト・テンプレートを作成するリクエストのタイプを選択します(たとえば、ユーザーの作成)。
説明: 作成しているリクエスト・テンプレートの説明を入力します。
テンプレート・レベルの承認プロセス: 「ユーザーの作成」リクエストに承認プロセスを指定する場合は、承認ワークフロー名を指定します。これは、リクエスト・レベルの承認と操作レベルの承認に加え、テンプレート・レベルの承認です。契約社員のユーザーを作成する場合は、すべての契約社員の採用について責任を負う人事担当者が、ユーザーの作成を承認する必要があることを指定できます。
configuring-requests.htm#GUID-FA3DC8DD-F39A-472B-AB23-15B19460C535__BABCGDGAに、リクエスト・テンプレートの作成ウィザードの「リクエスト・テンプレートの詳細の設定」ページを示します:
「制限する属性の選択」ページで、ユーザーが値を入力できるようにする「ユーザーの作成」タイプの属性を選択します。リクエスト・テンプレートによって制限された属性は、ユーザーに表示されないか、事前定義のLOVでのみ選択できます。ユーザーは値を入力できません。configuring-requests.htm#GUID-FA3DC8DD-F39A-472B-AB23-15B19460C535__BABFFIBCに、「制限する属性の選択」ページを示します:
このページには、「ユーザーの作成」リクエスト・タイプのデータセットに基づいて属性が表示されます。「ユーザーの作成」リクエスト・テンプレートを使用してリクエストが作成される場合は、これらのデフォルトの属性すべてに値を指定できます。これらの属性の一部を制限する場合や、いくつかの属性の値をリクエスタが入力するようにする場合は、このページでその属性を選択できます。たとえば、「ミドル・ネーム」属性に値を指定する必要がある場合は、この属性を選択できます。この例では、「ミドル・ネーム」、「組織」、「ユーザー・タイプ」、「ユーザー・マネージャ」および「国」属性を選択できます。
ノート:
データセット属性がPrePopulationAdapterで構成される場合も、リクエスト・テンプレートで属性を制限できます。この場合、事前移入は発生せず、テンプレートで制限されている値は「リクエスト作成」のUIに表示されます。したがって、属性に事前移入が必要な場合は、テンプレートで制限しないようにする必要があります。
この項で前述したように、ウィザードの各ステップは、リクエスト・タイプと、リソース・ベースのリクエスト・タイプに対するリソースの選択に基づいて動的に生成されます。ステップは、タブの上部に表示されます。
「属性制限の設定」ページで、「制限する属性の選択」ページで選択した属性に対する制限を指定します。制限を指定するには:
ノート:
このステップは、対応するリクエスト・データセットに属性が指定されている場合にのみ生成されます。
「ユーザー・ログイン」属性に、次のいずれかを選択します。
- ユーザーがこの属性の値を入力できないようにします: ユーザーが属性に値を入力できないようにする場合は、このオプションを選択します。このオプションを選択すると、ユーザーを作成するときに属性はUIに表示されません。必須属性には値を指定する必要があるため、このオプションは必須属性に対しては表示されません。
- この属性を次の値に制限します: 属性に1つ以上の値を指定する場合は、このオプションを選択します。たとえば、「部門番号」属性に「ソフトウェア・エンジニアリング」などの値を指定すると、属性のデフォルト値は「ソフトウェア・エンジニアリング」に設定され、このテンプレートを使用してリクエストを作成する場合に、属性はUIに表示されません。また、「+」(プラス)アイコンを使用することで、属性に複数の値を指定できます。複数の値を指定すると、このテンプレートを使用してリクエストを作成するときに、値がLOVとしてユーザーに表示され、ユーザーはLOVから値を選択できます。
ヒント:
「部門番号」属性は、リクエスト・データセットにテキスト・ボックスとして指定されているため、これらのオプションはこの属性には表示されません。
「組織」属性に1つ以上の値を指定します。これを行うには、「組織」フィールドの横にある検索アイコンをクリックし、「使用可能な組織」リストから組織名を1つ以上選択して、「移動」ボタンをクリックします。
ヒント:
「組織」属性は、リクエスト・データセットにエンティティとして指定されているため、既存の組織名を検索して値を選択する必要があるフィールドとして表示されます。組織はOracle Identity Managerで作成されるため、これは動的LOVです。
「ユーザー・タイプ」属性の値を指定します。これを行うには、使用可能なユーザー・タイプ・リストから値を1つ以上選択し、「移動」ボタンをクリックします。
ヒント:
「ユーザー・タイプ」属性は、リクエスト・データセットに静的LOVとして指定されているため、静的LOVとして表示されます。ユーザーは使用可能なユーザー・タイプから選択する必要があり、新規ユーザー・タイプを作成できないため、これは静的LOVです。
「ユーザー・マネージャ」属性と「国」属性の値を指定し、「次」をクリックします。
configuring-requests.htm#GUID-FA3DC8DD-F39A-472B-AB23-15B19460C535__BABGAACFに、「属性制限の設定」ページを示します:
ノート:
ステップ5、6および7は、すべてのリクエスト・テンプレートの作成に共通です。
「追加属性の設定」ページで、属性に関する追加の情報を指定できます。これらの情報は、作成しているテンプレートに基づいて収集する必要がありますが、エンティティ・マッピングには使用されません。
ノート:
追加の属性データはリクエスト実行時には使用されません。このデータは承認者にも表示されません。
この例では、追加の属性名として生年月日を指定しています。「データ型」に「数値」、「表示タイプ」に「テキスト・フィールド」を選択し、「追加」をクリックします。複数の属性を指定するには、「追加」ボタンをクリックします。終了したら、「次へ」をクリックします。
関連項目:
基になるOracle Identity Managerエンティティにマッピングされない追加の属性の詳細は、「ステップ1: リソースのリクエスト・データセットの作成」を参照してください
configuring-requests.htm#GUID-FA3DC8DD-F39A-472B-AB23-15B19460C535__BABDDIIEに、「追加属性の設定」ページを示します:
「テンプレート・ユーザー・ロールの設定」ページで、1つ以上のロール(たとえば、AD管理者)を選択できます。そのロールのメンバーは、作成されたテンプレートを使用してリクエストを作成できます。この例では、「使用可能なロール」リストから、契約者管理者などのロールを選択します。「移動」をクリックして、選択したロールを「選択したロール」リストに移動し、「次」をクリックします。
各リクエスト・テンプレートをロールのセットと関連付けることができます。これらのいずれかのロールを持つユーザーのみが、このテンプレートを使用してリクエストを作成できます。新しいリクエスト・テンプレートが関連ロールのリストとともに作成されると、新しい認可ポリシーが内部的に作成されます。さらに、既存のリクエスト・テンプレートとのロール関連が変更(新しいロールの追加または既存ロールの削除)されると、このテンプレートに対する既存の認可ポリシーが変更されます。
リクエスト・テンプレートを使用したリクエスト作成に対するデフォルト認可ポリシーは、リクエスト・テンプレート管理者ロールを持つユーザーが、リクエスト・テンプレートに関連するすべての操作にアクセスできるようにします。ポリシーの詳細は次のとおりです。
ポリシー名: リクエスト・テンプレート管理ポリシー
割当て先: リクエスト・テンプレート管理者ロール
機能セキュリティ: 権限は次のとおりです。
作成
削除
変更
検索
これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。
データ・セキュリティ: なし
説明: リクエスト・テンプレート管理者またはシステム管理者ロールを持つユーザーが、すべてのリクエスト・テンプレート・アクションにアクセスできるようにします。
configuring-requests.htm#GUID-FA3DC8DD-F39A-472B-AB23-15B19460C535__BABJAAGAに、「テンプレート・ユーザー・ロールの設定」ページを示します:
「リクエスト・テンプレート・サマリーの確認」ページ(configuring-requests.htm#GUID-FA3DC8DD-F39A-472B-AB23-15B19460C535__BABGFJHCを参照)で、「リクエスト・テンプレート名」、「リクエスト・タイプ」、「説明」、「テンプレート・レベルの承認プロセス」に入力したデータを確認し、「終了」をクリックします。
「OK」をクリックして、テンプレートの作成を確認します。
リクエスト・テンプレートの作成ウィザードの次の各ステップは、選択したリクエスト・タイプや定義したリクエスト・データセットに関係なく共通です。
「リクエスト・テンプレートの詳細の設定」ページでのリクエスト詳細の指定。「リクエスト・テンプレートの作成」のステップ5を参照してください。
「追加属性の設定」ページでの追加属性の設定。ステップ8を参照してください。
「テンプレート・ユーザー・ロールの設定」ページでのテンプレートに対するロールの設定。ステップ9を参照してください。
「リクエスト・テンプレート・サマリーの確認」ページにあるリクエスト・テンプレート情報。ステップ10を参照してください。
「リソースのプロビジョニング」リクエスト・タイプに基づいている「リソースのプロビジョニング」デフォルト・リクエスト・テンプレートを使用して、リソースをユーザーにプロビジョニングできます。しかし、リクエストの作成をカスタマイズしてユーザーに固有のリソースをプロビジョニングする必要がある場合は、「リソースのプロビジョニング」リクエスト・タイプに基づいたリクエスト・テンプレートを作成できます。
「リソースのプロビジョニング」リクエスト・タイプに基づいてリクエスト・テンプレートを作成するには:
リクエスト・テンプレートの作成時に、リクエスト・データセットが定義されていないリソースを選択すると、ユーザーに対して収集対象属性を制限できなくなります。これは、選択されたリソースについてユーザーから収集するデータの情報が指定されていないためです。その結果、制限されるデータがない場合、これらのステップの属性はリクエスト・データセットによって定義されるため、リクエスト・テンプレートの作成ウィザードの「ステップ3: 属性」および「ステップ4: 制限」は適用されません。ただし、リクエスト・データセットがないリソースを選択した場合、「サービス・アカウント」属性は共通のリクエスト・データセットによって定義されるため、この属性が「ステップ3: 属性」に表示されます。共通リクエスト・データセットの詳細は、「共通リクエスト・データセット」を参照してください。
リクエスト管理操作の特定の側面をカスタマイズして、柔軟性を向上させたり、追加機能のカスタマイズされたロジックを実装できます。これを行うには、リクエスト管理プラグインを使用できます。カスタマイズの実装に使用できるプラグイン・ポイントがあります。
ここでは、プラグイン・ポイントについて次の各項で説明します。
Oracle Identity Managerでは、リクエストのライフサイクルの各ステージでステータスが変更されます。リクエスト・エンジンによって、リクエスト・ステータスの変更時にカスタム・コードを実行できるプラグイン・ポイントが公開されます。このプラグイン・ポイントを拡張するカスタム・コードを含むプラグインを実装し、コードを実行するために登録できます。プラグイン・ポイントは、public void followUpActions(String reqId)メソッドを含むoracle.iam.request.plugins.StatusChangeEventインタフェースです。このメソッドはリクエストIDパラメータで構成され、これとリクエスト管理APIを使用してリクエスト詳細を取得できます。
ステータス変更時に実行するコードは、oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するプラグイン・クラスのfollowUpActions()メソッドで実装する必要があります。plugin.xmlファイルでこのプラグインをどのリクエスト・ステータス変更時に実行するかを指定する必要があります。
たとえば、Oracle Identity Managerでリクエストが「リクエストに失敗しました」ステータスに移行した場合、管理者に通知を送信するカスタム・コードを実行できます。これを行うには:
oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するRequestFailedChangeEventという名前の新しいプラグイン・クラスを作成します。このクラスには、followUpActions(String reqId)メソッドで管理者に通知を送信するロジックが必要です。
プラグイン・フレームワークで指定されている次の標準形式でplugin.xmlを定義します。
<oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<plugins pluginpoint="oracle.iam.request.plugins.StatusChangeEvent">
<plugin pluginclass="com.mycompany.RequestFailedChangeEvent" version="1.0" name="RequestFailedChangeEvent">
<metadata name="status">
<value>Request Failed</value>
</metadata>
</plugin>
</oimplugins>
このXML定義では、プラグインを実行する必要があるステージをメタデータ部分で指定しています。メタデータ値をRequest Failedとして指定し、これはリクエストが「リクエストに失敗しました」ステータスに移行したときにcom.mycompany.RequestFailedChangeEventプラグインが実行されることを意味します。
次のいずれかの方法を使用して、プラグインをOracle Identity Managerに登録します。
登録関連のタスクにPlatformService.registerPlugin APIおよびPlatformService.unRegisterPlugin APIを使用。
例:
ClientPlatform platform = OIMClient.getInstance();
platform.login("username", "password");
PlatformService service = platform.getService(PlatformService.class);
File zipFile = new File(fileName);
FileInputStream fis = new FileInputStream(zipFile);
int size = (int) zipFile.length();
byte[] b = new byte[size];
int bytesRead = fis.read(b, 0, size);
while (bytesRead < size) {
bytesRead += fis.read(b, bytesRead, size - bytesRead);
}
fis.close();
service.registerPlugin(b);
service.unRegisterPlugin(pluginID, version);
プログラム登録ユーティリティを使用。ユーティリティは、pluginregistration.xmlおよびant.propertiesファイルを使用します。これらのファイルは、OIM_HOME/plugin_utility/ディレクトリにあります。
ノート:
プラグイン登録ユーティリティには、Apache Antバージョン1.7以上が必要です。
ユーティリティを使用してプラグインを登録するには、次のステップを実行します。
ant.propertiesのWLS_HOMEおよびOIM_HOMEの値を設定します。次に例を示します:
WLS_HOME =.../middleware/wlserver_10.3 OIM_HOME =..../middleware/Oracle_IDM1/server
ディレクトリをWLS_HOME/server/libに変更して、次のコマンドを実行し、wlfullclient.jarをOracle WebLogicサーバーに作成します。
java -jar ../../../modules/com.bea.core.jarbuilder_1.3.0.0.jar
ノート:
JARファイルの正確なバージョンは、WLSによって異なる場合があります。WLS_HOME/../modules/ディレクトリにあるcom.bea.core.jarbuilderという名前の対応するファイルを使用します。
antターゲットの登録を実行します。
ant -f pluginregistration.xml register
これにより、Oracle Identity Managerのユーザー名およびパスワードとサーバー情報およびプラグインzipファイルの場所が要求されます。
zipファイルの場所の完全なパスを入力します。
RequestDataValidatorプラグインを使用して、送信後にリクエスト・データのカスタム検証を追加できます。このプラグインのプラグイン・ポイントは、public void validate(RequestData requesterData)メソッドを含むoracle.iam.request.plugins.RequestDataValidatorインタフェースです。DataSetValidator要素の詳細は、「DataSetValidator要素」を参照してください。
事前移入プラグインは、リクエスト・データセットの属性参照または属性に関連付けられます。これを使用すると、リクエストの作成時にカスタム・コードを実行して、属性値を事前移入できます。リクエスタは、必要に応じて事前移入する値を変更できます。
このプラグインのプラグイン・ポイントは、public Serializable prepopulate(RequestData requestData)メソッドを含むoracle.iam.request.plugins.PrePopulationAdapterインタフェースです。このプラグインは、次のリクエスト・タイプにのみ使用します。
リソースのプロビジョニング、リソースの自己リクエスト、ユーザーの作成、ユーザーの自己登録
詳細は、「PrePopulationAdapter要素」を参照してください。
