ヘッダーをスキップ
Oracle Identity Manager管理およびユーザー・コンソール・カスタマイズ・ガイド
リリース9.1.0
E05906-02
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

6 自己登録、ユーザー・プロファイル管理およびサービス・アカウントのカスタマイズ

この章では、管理およびユーザー・コンソールでユーザー・アカウントを作成する自己登録プロセスをカスタマイズする方法と、ユーザーが自分のアカウント・プロファイルを編集する方法について説明します。また、サービス・アカウント（複数のユーザーによって共有され、メンテナンス目的で使用される一般的な管理者アカウント）をカスタマイズする方法についても説明します。

自己登録プロセスでは、次の項目を決定する必要があります。

ユーザー起動によるユーザー・プロファイルの変更では、次の項目を決定する必要があります。

この章の内容は次のとおりです。

変更するファイル

自己登録、プロファイルの自己編集、およびサービス・アカウントをカスタマイズするには、次のファイルを編集します。

OIM_HOME\xellerate\config\FormMetaData.xml

また、Oracle Identity Manager Design Console内の関連レコードを編集する必要があります。

自己登録オプションのカスタマイズ

この項では、管理およびユーザー・コンソールの自己登録機能をカスタマイズする方法について説明します。

自己登録を許可するかどうかの指定

自己登録を許可するかどうかを指定するには、次の手順を実行します。

  1. Design Consoleにログインします。

  2. 「Administration」ディレクトリに移動して、「System Configuration」フォームにアクセスします。

  3. Is Self-Registration Allowed?プロパティを問い合せて検索します。

  4. ユーザーによる自己登録を許可する場合は、Is Self-Registration Allowed?プロパティにTRUEの値を設定します。ユーザーによる自己登録を禁止する場合は、このプロパティの値をFALSEに設定します。

  5. 変更を保存します。

ユーザー情報ページのカスタム・フィールドの定義

コンソールに含まれるユーザー自己登録ページおよびプロファイル・ページには、ユーザー情報用の定義済フィールドがいくつかあります。管理者は、ユーザーが自己登録やプロファイル編集を行うときに情報を入力するためのカスタム・フィールドを作成できます。


注意:

自己登録ページのデフォルト・システム・フィールドは、FormMetaData.xmlファイルの<!-- User Self Registration and User Profile Modification section -->セクションにリストされています。

ユーザー自己登録ページのカスタム・フィールドを作成するには、次の手順を実行します。

  1. Design Consoleにログインします。

  2. 「Administration」ディレクトリに移動して、「User Defined Field Definition」フォームにアクセスします。

  3. 「Users」フォームを問い合せて検索します。

  4. ユーザー定義フィールド（社会保障番号など）を作成します。


    関連項目:

    ユーザー定義フィールドの作成の詳細は、『Oracle Identity Managerデザイン・コンソール・ガイド』のOracle Identity Managerフォームへのユーザー定義フィールドの追加に関する項を参照してください。

  5. 「User Defined Fields」フォームを保存して閉じます。

  6. テキスト・エディタでOracle Identity ManagerのFormMetaData.xmlファイルを開き、<!-- User Self Registration and User Profile Modification section -->セクションを検索します。

  7. 属性を定義するため、次の書式で属性のエントリを追加します。

    <Attribute name="identifier" label="field_label" displayComponentType="datatype" map="database_column" />

    各値の意味は次のとおりです。

    • identifierは、ページを定義するときにこのフィールドを指定するための名前です。

    • field_labelは、管理およびユーザー・コンソールのフィールドの横に表示されるテキストです。

    • datatypeは、コンソールに表示されるフィールドのデータ型です。

    • database_columnは、Design Consoleを使用してフィールド定義を作成したときに指定したデータベース列名です。ユーザー定義フィールドにはUSR_UDF_という接頭辞が付けられます。このため、Design ConsoleでSSNと入力した場合、この値はUSR_UDF_SSNになります。たとえば、次のようになります。

      <Attribute name="USR_UDF_SSN" label="SSN" displayComponentType="TextField"                map="USR_UDF_SSN" />

      注意:

      これは、Design Consoleを使用してフィールド定義を作成するときに入力する情報と同じです。

  8. このファイルの変更を保存します。

カスタム・フィールドを作成および定義すると、そのフィールドをページ定義で使用できます。

ユーザー自己登録ページの定義

ユーザーが自己登録するときに表示するフィールドと、必須入力とするフィールドを指定できます。カスタム・フィールドを表示するには、自己登録ユーザー・ページに対応するFormMetaData.xmlファイルのセクションでそのフィールドを参照する必要があります。この手順は、「ユーザー情報ページのカスタム・フィールドの定義」に記載されています。

ユーザー自己登録ページを定義するには、次の手順を実行します。

  1. FormMetaData.xmlファイルを開きます。

  2. <Form name="SelfRegistrationUserForm">というセクションを検索します。このセクションには、「ユーザー自己登録」ページの定義が含まれます。ページにフィールドを追加するには、そのフィールドに対する参照を新規の行として次の書式で追加します。

    <AttributeReference optional=true/false>identifier</AttributeReference>

    各値の意味は次のとおりです。

    • identifierは、このファイルの定義セクションで指定した名前です。

    • optionalは、フィールドが必須かオプションかを指定します。optionalをfalseに設定するとフィールドは必須となり、trueに設定するとオプションになります。

    たとえば、USR_UDF_SSNという識別子を持つ新規の必須フィールドを追加するには、次の行を追加します。

    <AttributeReference optional="false">USR_UDF_SSN</AttributeReference>

    注意:

    デフォルト値はtrueであるため、必須フィールドの場合はこの属性を省略できます。

  3. このファイルの変更を保存して閉じます。


    注意:

    管理およびユーザー・コンソールの自己登録ページからフィールドを削除するには、そのフィールドを表す<Form name="SelfRegistrationUserForm">セクションから行を削除します。

自己登録に承認を必要とするかどうかの指定

自己登録に承認を必要とするように指定するには、ユーザー登録の承認プロセスに、条件付きではない手動タスクが1つ以上含まれていることを確認してください。

自己登録に承認を必要としない場合は、次の手順を実行します。

  1. ユーザー登録の承認プロセスに、条件付きではないタスクが含まれていないことを確認します。

  2. 登録関連の承認ページのフィールドが、必須として設定されておらず、「ユーザー自己登録」ページにも表示されないことを確認します。


関連項目:

FormMetaData.xmlファイルで編集するセクションを検索する方法の詳細は、「ユーザー情報ページのカスタム・フィールドの定義」を参照してください。


注意:

Oracle Identity Managerのデフォルトでは、ユーザーの自己登録時に「組織」フィールドと「ロール」フィールドは表示されません。ユーザーを登録するには、これらのフィールドの値が必要です。したがって、管理者または承認者は、リクエスト時にこれらのフィールドの値を「ユーザー情報」ブランチで設定する必要があります。

ユーザー起動のプロファイル管理オプションのカスタマイズ

デフォルトでは、登録の完了したすべてのユーザーは、自分のプロファイル情報を編集できます。プロファイル内のフィールドのうち、どのフィールドにユーザーの編集を許可するか、それらの編集に承認を必要とするかどうかを制御することができます。また、承認を必要とする場合、承認者が更新可能なフィールドも制御できます。

プロファイル内でユーザーに編集を許可するフィールドの指定

ユーザーに編集を許可するプロファイル内のフィールドを指定するには、次の手順を実行します。

  1. FormMetaData.xmlファイルを開きます。

  2. ProfileModificationUserFormセクションを検索します。

  3. ユーザーに編集を許可する各フィールドで、editableパラメータをTRUEに設定します。

  4. ファイルを保存して閉じます。

ユーザー起動のプロファイル変更に承認を必要とするかどうかの指定

ユーザー起動のプロファイル変更に承認を必要とするよう指定するには、ユーザー・プロファイル編集の承認プロセスに、条件付きではない手動タスクが1つ以上含まれていることを確認してください。

ユーザー起動のプロファイル変更に承認を必要としない場合は、次の手順を実行します。

  1. ユーザー・プロファイル編集の承認プロセスに、条件付きではないタスクが含まれていないことを確認します。

  2. プロファイル更新関連の承認ページのフィールドが、必須として設定されておらず、「アカウント・プロファイルの変更」ページにも表示されないことを確認します。


関連項目:

FormMetaData.xmlファイルで編集するセクションの詳細は、「ユーザー情報ページのカスタム・フィールドの定義」を参照してください。

承認者に編集または上書きを許可するフィールドの指定

承認者に編集または上書きを許可するフィールドを指定するには、次の手順を実行します。

  1. FormMetaData.xmlファイルを開きます。

  2. ProfileModificationApprovalFormというセクションを検索します。

  3. ユーザーに編集を許可する各フィールドで、editableパラメータをTRUEに設定します。

  4. ファイルを保存して閉じます。

サービス・アカウントのカスタマイズ

サービス・アカウントは、メンテナンス目的で使用されるadmin1やadmin2などの一般的な管理者アカウントです。これらのアカウントは、通常、一連のユーザーによって共有されます。一般的に、これらのアカウントにより、（ユーザーではなく）システムが別のシステムと対話できます。サービス・アカウントを管理およびプロビジョニングするモデルは、通常のプロビジョニングとは多少異なります。


注意:

Oracle Identity Managerでは、サービス・アカウントのバックエンド・サポートのみ提供されます。サービス・アカウントは、APIを通じてのみ管理できます。

サービス・アカウントの動作

サービス・アカウントの動作の特徴は、次のとおりです。

  • サービス・アカウントのリクエスト、プロビジョニングおよび管理は、通常のアカウントと同じ方法で行われます。サービス・アカウントは、通常のアカウントと似ています。通常のアカウントと同じリソース・オブジェクト、プロビジョニング・プロセスおよびプロセス・フォーム（オブジェクト・フォーム）が使用されます。サービス・アカウントと通常のアカウントが異なる点は、フラグです。このフラグは、リソースをリクエストするユーザーか、またはリソースを直接プロビジョニングする管理者により設定されます。

  • ライフサイクル中に、サービス・アカウントを通常のアカウントに変更できます。また、通常のアカウントをサービス・アカウントに変更できます。いずれかの変更が発生すると、サービス・アカウント変更のタスク機能がトリガーされます。

  • ユーザーが削除されても、リソースは失効しません。つまり、サービス・アカウントのプロビジョニング・プロセスは取り消されず、取消しタスクがトリガーされます。かわりに、Oracle Identity Managerが無効化または有効化アクションを処理する場合と同様に、プロビジョニング・プロセスにタスクが挿入されます。このため、ユーザーが削除されると、サービス・アカウント・アラートのタスク機能がトリガーされます。

  • ユーザーが無効化されても、リソースは無効化されません。つまり、無効化の効果を持つタスクは、サービス・アカウント・インスタンスのプロビジョニング・プロセスに挿入されません。かわりに、サービス・アカウント・アラートのタスク機能がトリガーされ、タスクがプロビジョニング・プロセスに挿入されます。

  • サービス・アカウント・インスタンスを直接的に、またはリクエストを通じて明示的に、無効化、有効化または失効する場合、それらの操作は通常のアカウントと同じ方法で管理されます。

  • Oracle Identity Manager APIを使用して、プロビジョニングされたサービス・アカウント・リソース（プロビジョニング・プロセスやプロセス・フォーム・エントリなど）をあるユーザーから別のユーザーに転送できます。この処理が発生すると、サービス・アカウント移動のタスク機能がトリガーされます。

アカウントの変換

通常のアカウントをサービス・アカウントに、またはサービス・アカウントを通常のアカウントに変更できます。どちらの場合も、プロビジョニング・プロセスにサービス・アカウント変更のタスクが挿入されます。このタスクは、「プロセス定義」の「タスク」タブでアクティブになります。このプロビジョニング・プロセスに関連付けられているすべてのアダプタが実行されます。アダプタがない場合は、事前定義されたレスポンス・コードが追加されます。

この機能に関連するAPIは、次のとおりです。

  • tcUserOperations.changeFromServiceAccount

  • tcUserOperations.changeToServiceAccount

サービス・アカウント・アラート

サービス・アカウントにリンクしているユーザーに対してライフサイクル・イベントが発生すると、そのサービス・アカウント・インスタンスのプロビジョニング・プロセスにサービス・アカウント・アラートのタスクが挿入されます。このタスクを使用して、ユーザーに対して発生した無効化イベントに対応する適切なアクションを開始できます。

アラート・タスクは、ユーザーが無効化または削除されるときに挿入されます。この場合、アラート・タスクの挿入は、サービス・アカウント・インスタンスで発生する唯一のアクションです。

アラート・タスクは、サービス・アカウントに対して直接的なイベントが発生する場合には挿入されません（サービス・アカウントが明示的に無効化される場合など）。

サービス・アカウントの移動

サービス・アカウントの所有権は、あるユーザーから別のユーザーに移動できます。これを実行すると、プロビジョニング・インスタンスは、新規所有者のリソース・プロファイルに表示され、以前のユーザーのリソース・プロファイルには表示されません。アカウントの移動後に、リソース・インスタンスのプロビジョニング・プロセスにサービス・アカウントの移動タスクが挿入されます。このプロビジョニング・プロセスに関連付けられているすべてのアダプタが実行されます。アダプタがない場合は、事前定義されたレスポンス・コードが追加されます。

サービス・アカウントを移動するAPIメソッドは、tcUserOperationsIntf.moveServiceAccountです。

サービス・アカウント・フラグAPI

次のAPIメソッドで、サービス・アカウントに関連するフラグを設定します。

  • tcRequestOperations.addRequestObject

  • tcRequestOperations.setRequestObjectAsServiceAccountFlag

  • tcUserOperations.changeFromServiceAccount

  • tcUserOperations.changeToServiceAccount

  • tcUserOperations.provisionObject

  • tcUserOperations.moveServiceAccount

  • tcObjectOperations.getServiceAccountList

フラグ名は、各フラグの機能を示しています。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引