|
| |
| Sun™ Identity Manager 8.0 配備に関する技術概要 | |
第 3 章
データ読み込みと同期この章では、アカウント情報をリソースから Identity Manager に読み込んで同期するために使用できる方法の概要を説明します。
アイデンティティーシステム ユーザーとリソースアカウントの違いを明確に区別することが重要です。次の定義は、このトピックを理解するのに役立ちます。
- ユーザー: Identity Manager が管理する仮想アイデンティティーです。Identity Managerユーザーは複数のアカウントを参照する場合があります。
- アカウント: リソース (正確には、Identity Manager 内でリソースオブジェクトとして表現される外部システムまたはアプリケーション) で管理される実際のアイデンティティーです。たとえば、UNIX システムの /etc/passwd にあるエントリ、Windows システムの SAM データベースにあるエントリ、RACF のあらゆる表現アカウントにある UserProfile などです。
- 管理者: Identity Manager システムの設定および保守の責任を負っている人です。
Identity Manager は、既知のリソースアカウントとユーザーの情報をアカウントインデックスに格納します。アカウントインデックスの各エントリには、最小限でもアカウント ID と Identity Manager リソース ID が含まれています。エントリには、ネイティブの GUID やアカウントのステータス (有効または無効) などの追加情報が含まれる場合もあります。エントリには、アカウントの所有者として Identity Manager ユーザーの ID も記録でき、所有者候補のリストも記録できます。
この章で説明するトピックは次のとおりです。
データ読み込みの種類データ読み込みは、アカウント情報をリソースから Identity Manager にインポートし、それらのアカウントを Identity Manager ユーザーに割り当てるプロセスです。Identity Manager は、リソースからアカウントデータを読み込む次の機能をサポートします。
- 「検出」: リソースアカウントを最初に Identity Manager に読み込む基本機能を提供します。
- 「調整」: リソースアカウント情報を定期的に Identity Manager に読み込み、設定されたポリシーに従って各アカウントに適切な処置を行います。
- 「Active Sync」: アイデンティティー情報の源泉として「信頼性の高い」外部リソース (アプリケーションやデータベースなど) に格納されている情報を Identity Manager のユーザーデータと同期できるようにします。Active Sync 対応アダプタは、アイデンティティー情報の源泉として信頼性の高いリソースに対する変更を「待機」(ポーリング) します。
これらの概念について、それぞれ詳しく説明します。データ読み込みの種類を比較した表を「データ読み込みの種類の概要」に示します。
検出
検出プロセスは、リソースを初めて配備するときに使うことを目的に設計されています。アカウント情報を Identity Manager にすばやく読み込むための手段を提供します。そのため、調整や Active Sync に含まれる機能の一部が備えられていません。たとえば、検出プロセスではアカウントインデックスにエントリが追加されません。また、検出の前後にワークフローを実行することもできません。ただし、検出プロセスでは、相関規則が予期したとおりに機能するかどうかをより早く判定できます。
検出プロセスを開始すると、Identity Manager は入力アカウントが既存のユーザーと一致する (つまり相関する) かどうかを判定します。一致した場合、検出プロセスはアカウントをユーザーにマージします。一致しない入力アカウントがある場合は、新しい Identity Manager ユーザーが作成されます。
Identity Manager には、次の検出機能があります。
これらの検出プロセスの詳細については、次のセクションを参照してください。
ファイルから読み込み
「ファイルから読み込み」検出プロセスは、XML ファイルまたは CSV (Comma-Separated Value) ファイルに書き込まれたアカウント情報を読み取ります。
一部のリソース (Active Directory など) には、ネイティブのアカウント情報を CSV (Comma-Separated Value) 形式にエクスポートする機能があります。これらの CSV ファイルを使って、Identity Manager アカウントを作成できます。CSV 形式の詳細については、『Identity Manager 管理ガイド』を参照してください。
ファイルから読み込むときは、どのアカウント相関規則および確認規則を使用するかを指定する必要があります。詳細については、「相関と確認の規則」を参照してください。
リソースから読み込み
「リソースから読み込み」機能は、ターゲットシステムを走査し、すべてのユーザーの情報を返します。その後、Identity Manager がユーザーを作成して更新します。リソースから読み込む前に、アダプタがそのリソース用に設定されている必要があります。
リソースから読み込むときには、どのアカウント相関規則および確認規則を使用するかを指定する必要があります。詳細については、「相関と確認の規則」を参照してください。
一括処理の作成
一括処理では、複数のアカウントを同時に処理できます。一括処理を使って Identity Manager アカウントおよびリソースアカウントの作成、更新、および削除ができますが、ここでは Identity Manager アカウントの作成のみについて説明します。一括処理の詳細については、『Identity Manager 管理ガイド』を参照してください。
一括処理は、CSV (Comma-Separated Value) を使って指定します。これらの値の構造は、「ファイルから読み込み」プロセスで指定される値とは異なります。
この CSV 形式は、2 行以上の入力行で構成されます。各行は、コンマで区切られた値のリストで構成されます。1 行目にはフィールド名が入ります。残りの各行は、Identity Manager ユーザー、ユーザーのリソースアカウント、またはその両方に対して実行される処理に対応します。各行には、同じ数の値が含まれるようにしてください。値を空にすると、対応するフィールドの値は変更されません。
一括処理の CSV 入力には、常に次の 2 つのフィールドが必要です。
3 番目以降のフィールドは、ユーザービューのフィールドです。使用されるフィールド名は、ビュー内の属性のパス表現です。ユーザービューで利用可能な属性の詳細については、『Identity Manager ワークフロー、フォーム、およびビュー』の「ユーザービューについて」を参照してください。カスタマイズしたユーザーフォームを使用している場合は、フォーム内のフィールド名に使用可能なパス表現の一部が表示されます。
一括処理でよく使われるパス表現の一部を次に示します。
- waveset.roles: Identity Manager アカウントに割り当てる 1 つ以上のロール名のリストです。
- waveset.resources: Identity Manager アカウントに割り当てる 1 つ以上のリソース名のリストです。
- waveset.applications: Identity Manager アカウントに割り当てる 1 つ以上のリソースグループのリストです。
- waveset.organization: Identity Manager アカウントが配置される組織名です。
- accounts[resource_name].attribute_name: リソースアカウント属性です。属性の名前はリソースのスキーマに一覧されています。
複数の値を指定できるフィールドもあります。たとえば、waveset.resources フィールドを使って、1 人のユーザーに複数のリソースを割り当てることができます。フィールド内の複数の値を区切るには、縦棒 (|) 文字 (「パイプ」文字とも呼ぶ) を使用します。複数の値の構文は、次のようにして指定できます。
value0 | value1 [ | value2 ... ] ]
一括処理の作成の例を次に示します。
一括処理の作成は、「ファイルから読み込み」プロセスより汎用性があります。「ファイルから読み込み」では一度に 1 つのリソースから情報を読み込みますが、一括処理では複数のリソースを処理できます。
調整
調整では、アカウントインデックスの内容と各リソースに現在含まれている内容を比較します。調整では、次の機能を実行できます。
調整には、完全調整と差分調整の 2 つの種類があります。
完全調整
完全調整は、アダプタがリストする各アカウント ID に対して、存在、所有権、状況を再計算します。これは所有権を再計算するために、リソースを要求する各 Identity Manager ユーザーをチェックします。
Identity Manager ユーザーは、次の方法でリソースを要求できます。
調整プロセスは、アカウントインデックスに記録された Identity Manager 所有者がまだ存在し、アカウントを要求していることを、アカウントごとに確認します。所有者のいないすべてのアカウントは、このリソースの調整ポリシーで相関規則が指定されているかぎり、Identity Manager ユーザーと関連付けられます。相関規則で 1 人以上の所有者候補がいることがわかると、それぞれの候補が確認規則で二重にチェックされます (指定されている場合)。規則の詳細については、「相関と確認の規則」を参照してください。
アカウントに対して状況が設定されると、調整はこのリソースの調整ポリシーで設定された応答を実行します。調整ポリシーがアカウント単位で実行するワークフローを指定している場合、完全調整は、状況処理を実行したあとに、調整するアカウントごとにこれを実行します。ワークフローの詳細については、「調整ワークフロー」を参照してください。
差分調整
差分調整は、差分バックアップと同質のものです。完全調整よりも高速であり、必要な処理のほとんどを実行しますが、完全調整ほどには完璧ではありません。
差分調整では、アカウントインデックスで保守している情報が正確であると信頼しています。既知のアカウント ID のリストが正確であると信頼し、Identity Manager 所有者によるアカウントの所有は正確に記録されていると信頼しているので、差分調整はいくつかの処理段階を省略または短縮することができます。
差分調整は、リソースを要求している Identity Manager ユーザーを検査する手順を省略しています。また差分調整は前回のリソース調整のあとに追加または削除されたアカウントだけを対象にして状況を算出します。リソースのアカウントインデックスにあるアカウント ID のリストとリソースアダプタが返したアカウント ID のリストを比較して、この計算を実行します。新規アカウントは、既存のアカウントとして記録され、削除されたアカウントはもはや存在しないアカウントとして記録されます。これ以降、これらの 2 種類のアカウントだけが処理されます。
差分調整は完全調整よりもはるかに高速であり、使用する処理サイクルも少ないので、差分調整の実行頻度を高くし、完全調整の頻度を低くすると快適な環境にできます。
Active Sync
Active Sync では、リソースに対する変更を「待機」(ポーリング) し、差分変更をリアルタイムで検出します。Active Sync は変更を検出するように設計されているため、アカウント情報をはじめて Identity Manager に読み込むときには使用しないでください。代わりに、調整または検出プロセスを使用します。
一般に、次のような場合は Active Sync リソースに対して調整を実行します。
Active Sync は、次の点で調整と異なります。
Active Sync では、適切に設定された Active Sync 対応アダプタを使用する必要があります。リソースを設定して Active Sync を実装する方法の詳細については、『Identity Manager 管理ガイド』を参照してください。
データ読み込みの種類の概要
次の表は、検出と調整の機能を比較したものです。
表 3-1 データ読み込みの種類の概要
機能
検出
調整
Active Sync
新規アカウントの検出
あり
あり
あり
削除されたアカウントの検出
なし
あり
あり
アカウント属性値の変更の検出
なし
あり
あり
Identity Manager ユーザーと関連のないアカウントの検出
あり
あり
あり
リソース上の特定のコンテナからリソース上の別のコンテナにユーザーを移動した時刻の検出
なし
あり
あり
アカウントと Identity Manager ユーザーの関連付け
あり
あり
あり
検出した個々のアカウント状況に応じたワークフローの実行
なし
あり
あり
スケジュール可能
なし
あり
あり
差分モード
なし
あり
該当しない
アカウントインデックスへのエントリの追加
なし
あり
あり
複数リソース上の属性の同期
なし
なし
あり
読み込み処理のコンテキスト次の表には、読み込み処理カテゴリに関連する一般的な Identity Manager プロセスまたはタスクに関する情報を示します。
表 3-2 読み込み処理プロセスまたはタスク
プロセスまたはタスク
使用方法
名前空間
ファイルから読み込み
CVS または XML ファイル (管理者インタフェースから呼び出される) からアカウント情報を取得します。
Identity Manager は、ファイルから WSUser オブジェクトを読み込み、それをユーザービューに変換し、フォームを適用します。属性は Identity Manager ユーザーの拡張属性であるかのように処理されます。属性は accounts[Lighthouse] に配置され、フォームで属性ごとにグローバルフィールドが定義されている場合は、global 属性の下のみに配置されます。
ファイルの各行のすべての属性値は、グローバルな名前空間に配置されます。
global.<attr name>
注: create 処理のみに適用されます。
リソースから読み込み
特定のリソース (管理者インタフェースから起動され、アダプタを使用してアカウントを一覧表示およびフェッチする) からアカウント情報を取得します。
リソースの各アカウントのすべての属性値は、グローバルな名前空間に配置されます。
global.<LHS Attr Name>
注: create 処理のみに適用されます。
一括処理
CVS ファイル (管理者インタフェースから起動される) からコマンドおよびユーザービューデータを取得します。
ユーザービュー名前空間で、任意の属性を指定できます。属性名は、ビューパス構文を使用して指定されます。ユーザービュー名前空間およびビューパス構文の詳細については、『Identity Manager ワークフロー、フォーム、およびビュー』の「ユーザービューについて」を参照してください。
ファイルからの属性値は、グローバルな名前空間に配置されます。
注: 許可された利用可能セッションはありません。
調整を管理する調整プロセスは、主に管理者インタフェースを介して管理されます。ただし、このインタフェースから実行できない調整の機能もあります。たとえば、新しい相関規則や確認規則の作成、調整ワークフローの作成、または調整設定オブジェクトの編集が必要な場合があります。以降の項では、これらの機能およびその他について説明します。調整ポリシーの定義の概要については、『Identity Manager 管理ガイド』を参照してください。
調整ポリシー
調整ポリシーでは、調整タスクごとに (リソースによる) 一連の応答を設定できます。ポリシー内では、調整を実行するサーバーを選択し、調整の実行回数と実行時間を決定し、調整中に発生する個々の状況に対する応答を設定します。アカウント属性に対してネイティブに (Identity Manager を介さずに) 行われた変更を検出するように調整を設定することもできます。
これらの各ポリシー設定は、異なる範囲で定義できます。
それぞれの範囲の値は、下位の各範囲のデフォルトになります。したがって、調整ポリシーは、継承ツリーを定義します。
継承は、リソースが多い場合に、ポリシーの管理を容易にします (特に多くのリソースが同じ設定である場合)。
たとえば、すべてのリソースを同じ方法で処理したい場合、1 セットのポリシー設定をグローバルレベルで管理するだけで済みます。すべての Windows リソースを 1 つの方法で処理し、すべての Solaris リソースを別の方法で処理したい場合、2 つのリソースタイプにそれぞれ 1 つずつポリシーを設定し、それぞれの範囲内でポリシー設定を管理する必要があります。一部のリソースインスタンスのリソースタイプレベルで定義するポリシーに例外がある場合、これらの個々のリソースに対応するために、必要なポリシー設定を優先する (つまり、指定する) ことができます。各ポリシー設定は個々に継承されるので、指定する必要があるのは異なる設定だけです。その他のポリシー設定は、以前と変わらずに、上位から値を継承することができます。
相関と確認の規則
Identity Manager は、ユーザーにリンクされていないリソースアカウントと Identity Manager ユーザーを次の 2 段階で照合します。
相関規則は、アカウントを所有している可能性がある Identity Manager ユーザーを検索します。確認規則は、ユーザーが実際にアカウントを所有しているかどうかを確認するために、アカウントに対して Identity Manager ユーザーをテストします。所有者候補をすばやく検索したり (名前または属性に基づいて)、負担の大きなチェックの実行を所有者候補だけに制限したりするので、この 2 段階のアプローチによって、Identity Manager は相関を最適化することができます。
調整ポリシーでは、各リソースに対して、相関規則と確認規則を選択できます。また、「確認規則なし」も指定できます。デフォルトの相関規則は、入力したアカウントのアカウント ID と厳密に一致する名前を持つユーザーを検索します。デフォルトでは、「確認規則なし」が使用されています。
Identity Manager は、いくつかの相関規則と確認規則を sample/reconRules.xml 内で事前に定義しています。また独自の相関規則や確認規則を記述することもできます。SUBTYPE_ACCOUNT_CORRELATION_RULE または SUBTYPE_ACCOUNT_CONFIRMATION_RULE というサブタイプを持つすべての規則オブジェクトは、適切な調整ポリシー選択リストに自動的に表示されます。
相関規則
相関規則は、リソースアカウントの属性値に基づいて、ユーザー名のリストを生成できます。また相関規則は、ユーザーの選択に使用する属性条件のリストを生成できます (ユーザーオブジェクトのクエリー可能な属性を参照)。
要求されていない各アカウントに対して、相関規則は 1 回ずつ実行されます。
Identity Manager は、sample/reconRules.xml 内でいくつかの相関規則を事前に定義しています。
- アカウント ID と一致するユーザー名: accountId 属性の値を返します。これはリソースアカウント ID と一致する名前を持つあらゆる Identity Manager ユーザーを所有者候補として選択します。これがデフォルトの相関規則です。
- 一致するアカウント ID を所有するユーザー: 属性条件のリストを返します。これは同じ accountId 値に一致するリソースアカウントを持っているすべての Identity Manager ユーザーを所有者候補として選択します。
- ユーザーの電子メールがアカウントの電子メールに一致: アカウントの email 属性に基づいて Identity Manager ユーザーを選択する属性条件のリストを返します。
相関規則の入力は、アカウント属性のマップです。出力は次のいずれかでなければなりません。
より複雑な規則で、アカウント属性値を組み合わせたり、処理したりして、名前のリストや属性条件のリストを生成できます。
たとえば、reconRules.xml には、相関規則の 4 番目のサンプル、「アカウントフルネームと一致するユーザーフルネーム」があります。追加の設定を実行しなければ、このサンプルは正常に動作しないので、この規則は XML コメントで無効にしてあります。この規則は、fullname に基づいて Identity Manager ユーザーを検索しますが、この属性はデフォルトではクエリー可能になっていません。
拡張属性の相関には、特別な設定が必要です。
確認規則
確認規則は、相関規則が返す一致ユーザーごとに 1 回ずつ実行されます。
一般的な確認規則は、ユーザービューの内部の値とアカウント属性の値を比較します。相関処理のオプションの第 2 段階として、確認規則は相関規則で表現できないチェックを実行します (または、相関規則では負担が大きいので評価できないチェック)。一般的に、確認規則が必要なのは、次の場合だけです。
Identity Manager は、sample/reconRules.xml 内で 2 つの確認規則を事前に定義しています。
確認規則には、次のものを入力します。
ユーザーがアカウントを所有している場合、確認規則は文字列形式でブール値の true を返します。それ以外の場合、値として false を返します。
デフォルトの確認規則は、「確認規則なし」です。これは、相関規則がアカウントごとにほぼ 1 人のユーザーを検出するという状況を前提としています。相関規則が複数のユーザーを選択する場合、アカウントの状況は「DISPUTED」になります。
調整ワークフロー
ユーザー定義のワークフローに対応するいくつかの接続ポイントを提供することにより、典型的な調整処理を拡張できます。
負荷の大きい (つまり長時間実行する) アカウント単位ワークフローを使用する場合は、『Identity Manager ワークフロー、フォーム、およびビュー』の「ワークフロープロパティーの設定」セクションで説明されているように、デフォルトワークフロー設定を変更することを検討してください。
プレリソースワークフロー
プレリソースワークフローは、ほかの調整処理の前に起動できます。「Notify Reconcile Start」ワークフローは、プレリソースワークフローの例です。
「Notify Reconcile Start」ワークフローは、あるリソースに対する調整が開始したことを通知する電子メールを管理者に送信します。このワークフローを実行する前に、「Notify Reconcile Start」電子メールテンプレートを設定する必要があります。
プレリソースワークフローには、次のパラメータが渡されます。
アカウント単位ワークフロー
アカウント単位ワークフローは、応答 (使用する場合) が完了したあと、調整によって処理されるアカウントごとに起動されます。応答のタイプと応答の結果は、このワークフローに影響を与えません。
「Notify Reconcile Response」ワークフローは、アカウント単位ワークフローの例です。調整プロセスが、検出された状況に対して自動的に応答しようとしたときに管理者に電子メールを送信します。このワークフローを実行する前に、「Notify Reconcile Response」電子メールテンプレートを設定する必要があります。
アカウント単位ワークフローには、次のパラメータが渡されます。
- accountId - 調整されたリソースアカウントの名前です。
- resourceId - 調整しているリソースのオブジェクト ID です。
- resourceName - 調整しているリソースの名前です。
- userID - アカウントの所有者として識別される Identity Manager ユーザーのオブジェクト ID です (状況に応じて、要求または相関によって識別)。アカウントに関連付けられたユーザーがいない場合、この値は NULL になります。
- userName - アカウントの所有者として識別される Identity Manager ユーザーの名前です (状況に応じて、要求または相関によって識別)。アカウントに関連付けられたユーザーがいない場合、この値は NULL になります。
- initialSituation - アカウントに関して最初に検出され、応答を開始した状況です。値は有効なメッセージキーです。
- responseSuccess - 応答が正常に完了したかどうかを示すブール値です。実行された応答がない場合、値は NULL になります。
- finalSituation - 応答を適用したあとのアカウントの調整状況です。アカウントがすでに存在せず、Identity Manager にこのアカウントへの参照がない場合、この値は NULL になります。
ポストリソースワークフロー
ポストリソースワークフローは、ほかの調整処理がすべて完了したあとに起動できます。「Notify Reconcile Finish」ワークフローは、ポストリソースワークフローの例です。
「Notify Reconcile Finish」ワークフローは、あるリソースに対する調整が完了したことを通知する電子メールを管理者に送信します。このワークフローを実行する前に、「Notify Reconcile Finish」電子メールテンプレートを設定する必要があります。
ポストリソースワークフローには、次のパラメータが渡されます。
ネイティブ変更を監査する
「Audit Native Change To Account Attributes」ワークフローが起動されるのは、調整またはプロビジョナが、Identity Manager による変更ではなく、リソースアカウント属性のネイティブ変更を検出したときです。変更の監視が実行されるのは、ユーザーが指定した属性だけです。デフォルトでは、属性の監視は実行されません。
このワークフローには、次のパラメータが渡されます。
- resource - アカウントがネイティブに変更されたリソースオブジェクトです。
- accountID - ネイティブに変更されたリソースアカウントの名前です。
- prevAttributes - Identity Manager によって記録される監視対象のリソースアカウント属性を含むマップです。
- newAttributes - リソース上で現在設定されている監視対象のリソースアカウント属性を含むマップです。
- attributeChanges - どの属性が変更されたかを示す汎用オブジェクトのリストを含むマップです。各オブジェクトには、前の値と新しい値が格納されます。
- formattedChanges - 監査レコードに適した簡潔な形式で属性の変更を表す文字列です。
ネイティブ変更を監査するには、次を実行する必要があります。
リソースのスケジューリング
調整は、それぞれのリソースのために、差分調整と完全調整という 2 つの別々のスケジュールを保守します。
各リソースは、個々の「要求者」タスクによってスケジュールが管理されます。調整ポリシー GUI でリソースに対して調整スケジュールを設定すると、要求者タスク用の TaskSchedule が設定されます。必要があれば、これで外部のタスクスケジューラによって調整を管理できるようになります。またこれで調整タスクの負担が最小限になります。何も処理を実行していない調整デーモンは、ほとんどリソースを消費しません。このデーモンは、メモリー内のキューを定期的にポーリングしているからです (調整の準備が整ったリソースを探して、データベースのクエリーを実行することはない)。
調整は、リソースアダプタを通じて、各リソースにアクセスします。調整はアダプタを直接的に呼び出して、アカウントのリスト、アカウントの反復、または個人用リソースアカウントのフェッチを実行します。また調整は、プロビジョナを通じて間接的にリソースにアクセスし、プロビジョナを使用してリソースアカウントを作成したり、リソースアカウントから Identity Manager ユーザーを作成したりします。
調整とプロビジョナは、両方ともアカウントインデックスの保守を実行します。また、リソースの調整を行うたびに、アカウントインデックスから不要な情報が除去されます。調整タスクは、Identity Manager ユーザーがアカウントを所有していないかぎり、リソースにもはや存在しないアカウントのエントリを自動的に削除します。したがって、アカウントインデックスにあるリソースの情報を手動でクリアする必要はありません。
各 Identity Manager サーバーは、デーモンタスクとして調整を実行します。つまり、Identity Manager スケジューラは、調整タスクをすぐに開始し、これが停止した場合は、タスクを自動的に再開します。
注
リソース調整は自動的に再開されません。新しい要求に応答できるように、ReconTask デーモン自体は、自動的に再起動されますが、ホストサーバーが停止したとき (またはアプリケーションサーバーがシャットダウンされたとき) に実行していた要求は失われます。デーモンはリソース調整を再開しません。要求がないときに、リソースを調整するのは不適切だからです。
調整設定オブジェクト
ReconcileConfiguration オブジェクトには、「調整ポリシーの編集」ページで編集できない複数の属性が含まれます。
次の表で、調整の属性について説明します。ReconcileConfiguration オブジェクト (#ID#Configuration:ReconcileConfiguration) の属性値を編集するには、デバッグページを使用します。
表 3-3 ReconcileConfiguration オブジェクトの主要な属性
属性
説明
fetchTimeout
調整プロセスがアカウントをフェッチするときにリソースからの応答を待機するミリ秒数です。デフォルト値は、1 分 (60,000 ミリ秒) です。
listTimeout
調整プロセスがアカウントをリストするときにリソースからの応答を待機するミリ秒数です。デフォルト値は、10 分 (600,000 ミリ秒) です。
maxConcurrentResources
サーバーが同時に調整するリソースの最大数です。デフォルト値は、3 です。
maxQueueSize
調整サーバーの作業キューに含まれるエントリの最大数です。デフォルト値は、1000 です。
次の例では、ReconcileConfiguration オブジェクトのデフォルト値を示します。
コード例 3-1 ReconcileConfiguration オブジェクトのデフォルト値
<Configuration id='#ID#Configuration:ReconcileConfiguration' name='Reconcile Configuration'>
<Extension>
<Object>
<Attribute name='listTimeout' value='600000' />
<Attribute name='fetchTimeout' value='60000' />
<Attribute name='maxConcurrentResources' value='3' />
<Attribute name='maxQueueSize' value='1000' />
</Object>
</Extension>
<MemberObjectGroups>
<ObjectRef type='ObjectGroup' id='#ID#All' name='All'/>
</MemberObjectGroups>
</Configuration>
Active Sync を管理するActive Sync 対応アダプタは、管理者インタフェースで管理できます。このインタフェースには、1 つのアダプタに対する Active Sync のほとんどの設定項目を管理者が完全に設定できるウィザードが含まれます。このウィザードでは、管理者が Identity Manager IDE を使わずにリソース、入力、またはフォームを構築することもできます。Active Sync ウィザードの詳細については、『Identity Manager 管理ガイド』を参照してください。
Active Sync 対応アダプタが機能する仕組み
この項では、次の内容を説明します。
アダプタ処理の基本的な手順
すべての Active Sync 対応アダプタは、Identity Manager で定義されているリソースの変更を知るために、次の基本的な手順でリスニングまたはポーリングを実行します。変更されたリソースを検出すると、Active Sync 対応アダプタは次の手順を実行します。
- リソースから変更された情報を抽出します。
- どの Identity Manager オブジェクトに関係があるか判断します。
- システムに渡すユーザー属性のマップを、アダプタの参照および追加オプションのマップとともに生成します。これにより、Identity Application Programming Interface (IAPI) オブジェクトが作成されます。
- IAPI オブジェクトを ActiveSync マネージャーに送信します。
- ActiveSync マネージャーは、このオブジェクトを処理し、処理の成功を Active Sync 対応アダプタに通知する WavesetResult オブジェクトをアダプタに返します。このオブジェクトには、ID の更新のために Identity Manager システムが使用するさまざまな手順の結果を多く含めることができます。一般に、ワークフローは Identity Manager 内のエラーにも対応し、多くの場合、担当管理者の承認にあとを任せます。
Active Sync 名前空間
次の表には、Active Sync 処理カテゴリに関連する一般的な Identity Manager プロセスまたはタスクに関する情報を示します。
表 3-4 Active Sync プロセスまたはタスク
実行中のプロセスまたはタスク
使用方法
名前空間
ActiveSync IAPIUser
ActiveSync イベントからの属性をユーザービューにマージします。
入力フォームの一般的な属性は次のとおりです。
ActiveSync IAPIProcess
最上位のワークフロー global 属性にダンプされる ActiveSync ポーリング属性を使用して、指定したタスクを起動します。
ワークフロー属性では次の形式が想定されます。
global.<LHS Attr Name>
規則を使用する
Active Sync 対応アダプタは、リソース上でのアカウントの変更を検出すると、受け取った属性を Identity Manager ユーザーにマップします。あるいは、一致するアカウントがない場合や、アカウントを作成するように Active Sync リソースが設定されている場合は、Identity Manager ユーザーアカウントを作成します。
Active Sync ウィザードでは、さまざまな条件が発生したときの処理を制御するための規則を指定できます。次の表は、規則の種類についてそれぞれ説明しています。
表 3-5 規則の種類
パラメータ
説明
処理規則
TaskDefinition の名前、またはフィード内のすべてのレコードに対して実行される TaskDefinition の名前を返す規則のいずれかです。この処理規則は、activeSync 名前空間内のリソースアカウント属性を、リソース ID およびリソース名とともに取得します。
処理規則は、システムがリソース上の変更を検出したときに実行されるすべての機能を制御します。アカウント処理を完全に制御する必要がある場合に使用します。この結果、処理規則はほかのすべての規則より優先されます。
処理規則が指定されると、このアダプタ上にほかのどんな設定があっても、すべての行に対してその処理が実行されます。
処理規則は、少なくとも次の機能を実行する必要があります。
ユーザー以外のオブジェクト (LDAP ロールなど) を同期することもできます。
相関規則
リソースアカウントを所有する Identity Manager ユーザーのリソース情報が特定されない場合、Identity Manager は相関規則を呼び出し、(アカウントの名前空間内の) リソースアカウント属性に基づいて、ユーザーの照合に使用する、一致する可能性のあるユーザーまたはアカウント ID の候補のリスト、あるいは属性条件を特定します。
規則は、エントリを既存の Identity Manager アカウントに関連付けるために使用できる次のいずれかの情報を返します。
相関規則によって複数の Identity Manager アカウントが識別された場合は、複数の一致を処理するために確認規則またはプロセス解決規則が必要です。
データベーステーブル、フラットファイル、および PeopleSoft コンポーネントの Active Sync アダプタの場合は、デフォルトの相関規則はリソース上の調整ポリシーから継承されます。
調整と Active Sync で同じ相関規則を使用できます。詳細については、「相関と確認の規則」を参照してください。
確認規則
相関規則によって返されるすべてのユーザーを対象にして評価される規則です。ユーザーごとに、Identity Manager の ID と (「account.」名前空間にある) リソースアカウント情報の相関を示す完全なユーザービューが確認規則に渡されます。確認規則は、ブール値で表すことができる値を返すことが期待されます。たとえば、「true」、「1」、「yes」、および「false」、「0」、「null」です。
データベーステーブル、フラットファイル、および PeopleSoft コンポーネントの Active Sync アダプタの場合は、デフォルトの確認規則はリソース上の調整ポリシーから継承されます。
調整と Active Sync で同じ確認規則を使用できます。詳細については、「相関と確認の規則」を参照してください。
削除規則
activeSync. または account. という形式のキーを持つ値すべてのマップを期待できる規則です。プロキシ管理者のセッションに基づく LighthouseContext オブジェクト (display.session) は、この規則のコンテキストで利用できます。この規則は、ブール値で表すことができる値を返すことが期待されます。たとえば、「true」、「1」、「yes」、および「false」、「0」、「null」です。
あるエントリに関してこの規則によって true が返された場合、アダプタの設定方法に応じて、フォームとワークフローを介してアカウント削除要求が処理されます。
プロセス解決規則
TaskDefinition の名前、またはフィード内のあるレコードに対して複数の一致がある場合に実行される TaskDefinition の名前を返す規則のいずれかです。プロセス解決規則は、リソースアカウント属性をリソース ID およびリソース名とともに取得します。
この規則は、一致がなく、「一致しないアカウントの作成」が選択されていない場合にも必要です。
このワークフローは、管理者による手動処理を求める処理にすることもできます。
一致しないアカウントの作成
true に設定すると、一致する Identity Manager ユーザーが見つからない場合に、リソース上にアカウントが作成されます。false に設定すると、処理規則が設定され、その規則が識別するワークフローによって新しいアカウントが保証されていることが確認されないかぎり、Identity Manager はアカウントを作成しません。デフォルトは true です。
グローバルで利用
true に設定すると、activeSync 名前空間に加えてグローバル名前空間にも値が入力されます。デフォルト値は、false です。
アダプタがユーザーを検出しなかった場合
Identity Manager が既存の Identity Manager ユーザーと一致するものを見つけられない場合は、「一致しないアカウントの作成」が true に設定されているか、プロセス解決ワークフローで feedOp of create が指示されていれば、更新処理が作成処理に変更されます。
feedOp フィールドを利用できるのは、ユーザーの作成、削除、または更新を実行するロジックを設定したフォームです。このフィールドを使用すると、特定イベントの固有なフィールドを無効化、あるいは有効化することができます (たとえば、feedOp フィールドが作成に設定されると、パスワードを生成するなど)。
この例の feedOp フィールドがパスワードを作成するのは、Active Sync 対応アダプタが Identity Manager ユーザーと一致しないユーザーをリソース内で検出し、Identity Manager 内にこのユーザーを作成するときだけです。
コード例 3-2 feedOp フィールドの例
<Field name='waveset.password'>
<Disable>
<neq>
<ref>feedOp</ref>
<s>create</s>
</neq>
</Disable>
<expression>
<cond>
<notnull>
<ref>activeSync.password</ref>
</notnull>
<ref>activeSync.password</ref>
<s>change12345</s>
</cond>
</expression>
</Field>
フォームを使用する
一般的に、Active Sync 対応アダプタは、処理中にリソースフォームとユーザーフォームの 2 つのフォームを使用します。
フォーム処理は、次の 3 つの手順で実行されます。
$WSHOME/sample/forms ディレクトリには、末尾に ActiveSyncForm.xml が付けられたサンプルフォームがあります。これらのフォームには、新規ユーザーと既存ユーザーの対応を分けるロジックのほかに、リソース上で削除を検出したときに Identity Manager ユーザーの無効化または削除を行うロジックも含まれています。
注
リソースフォームにはリソース固有のロジックだけを設定し、ユーザーフォームに共通のロジックを設定します。リソース固有のロジックは、feedop フィールドが NULL 以外の値になったときに有効になります。リソースフォームを「なし」に設定すると、すべての Active Sync 属性 (accountId を除く) がグローバル属性と見なされ、自動的にその設定がほかの属性に反映されます。
リソースフォーム
リソースフォームは、リソースの作成または編集時に、管理者がプルダウンメニューから選択するフォームです。選択したフォームの参照は、リソースオブジェクトに保存されます。
リソースフォームは、次のように Active Sync 対応アダプタで使用されます。
- スキーママップから受け取った属性を変換します。
- パスワード、ロール、および組織などのフィールドを生成します。
- 新規ユーザーと既存ユーザーの対応を分けるロジック、削除を検出したときに Identity Manager ユーザーの無効化または削除を行うロジックなど、カスタマイズした処理のために、簡単な制御ロジックを提供します。
- ユーザーフォームが入力として使用するフィールドに、ActiveSync から取得した属性をコピーし、オプションでこの値を変換します。作成処理に必要なフィールドは、waveset.accountId と waveset.password です。ほかのフィールドも設定できます (たとえば、accounts[AD].email または waveset.resources)。
- IAPI.cancel に true を設定して、ユーザーの処理をキャンセルします。多くの場合、これは特定のユーザーの更新を無視するために使用します。
リソースフォームには、新規ユーザーと既存ユーザーの対応を分けるロジック、削除を検出したときに Identity Manager ユーザーの無効化または削除を行うロジックがあります。
ユーザーフォーム
ユーザーフォームは、Identity Manager インタフェース上での編集作業に使用します。プロキシ管理者をアダプタに割り当てることで、ユーザーフォームを割り当てます。プロキシ管理者が自分に関連付けられたユーザーフォームを持っている場合、処理の実行時に、このフォームがユーザービューに適用されます。
プロキシ管理者とユーザーフォーム
ProxyAdministrator 属性を使用して、アダプタに対してプロキシ管理者を設定します。この属性は、あらゆる Identity Manager 管理者に設定できます。すべての Active Sync 対応アダプタの処理は、プロキシ管理者が実行したかのように実行されます。プロキシ管理者が割り当てられていない場合、デフォルトユーザーフォームが指定されます。
属性を処理する代替フォーム
ベストプラクティスとしては、名と姓からフルネームを導出するなど、共通の変更はユーザーフォームに設定することをお勧めします。リソースフォームには、HR ステータスの変更時にユーザーを無効化するなど、リソース固有の変更だけを設定します。ただし、目的の属性が incoming など共通のパスに入れられたあとは、組み込みフォームなどに代替的に共通の変更を設定できます。
<Form>
<Field name='incoming.lastname'>
<ref>activeSync.lastname</ref>
</Field>
<Field name='incoming.firstname'>
<ref>activeSync.firstname</ref>
</Field>
</Form>
これ以降、共通のフォームでは、共通のロジックのために incoming.xxx を参照します。
<Form>
<Field name='fullname'>
<concat>
<ref>incoming.firstname</ref><s> </s>
<ref>incoming.lastname</ref>
</concat>
</Field></Form>
キャンセル処理の実行
ユーザーの処理をキャンセルするには、リソースフォームで IAPI.cancel に true を設定します。これを使用すると、特定のユーザーへの更新を無視できます。
注
Active Sync フォームで IAPI.cancel に true の値が設定された場合、IAPIUser イベントまたは IAPIProcess イベントに関連付けられたプロセスは起動されません。
次の例では、「Doe」という姓を持つ全ユーザーを無視する、リソースフォーム内の簡単なフィールドを説明します。
<Field name='IAPI.cancel'>
<Disable><eq><ref>activeSync.lastName</ref><s>Doe</s></eq>
</Disable>
<Expansion>
<s>true</s>
</Expansion>
</Field>
ワークフロープロセスを起動する
管理者は、Active Sync ウィザードを使ってポーリング前またはポーリング後のワークフローを指定できます。これらのワークフローは、「調整ワークフロー」で説明したワークフローと概念上ほぼ同じです。
一部の Active Sync 対応アダプタは、取得したユーザービューの変更をチェックする代わりに、指定されたワークフローを実行するリソース属性をサポートします。このワークフローは、Active Sync データだけで構成される入力変数で実行されます。個々のプロセスをサポートしないアダプタの場合、または標準的なユーザーフォームを使用してプロセスを起動したいアダプタの場合、オプションを設定してプロセスよりも優先させることができます。
<Form>
<Field name='sourceOptions.Process'>
<Expansion>
<s>My workflow process name</s>
</Expansion>
</Field>
</Form>
フォームで指定したワークフローは、標準的なプロビジョニングワークフローと同じように呼び出されます。カスタムワークフローは、標準的な作成ワークフローや更新ワークフローに基づいて作成することを強くお勧めします。workflow.xml 内のユーザー作成ワークフローやユーザー更新ワークフローを参考にしてください。
例: Active Sync 対応アダプタからアカウントを無効化する
この例では、企業における従業員の現在のステータスでリソース (HR データベース) を更新できます。Active Sync 対応アダプタは、この HR データベースからの入力に基づいて、Identity Manager リポジトリを更新し、企業全体を通じてユーザーアカウントの無効化、削除、作成、あるいはその他の処理を実行できます。
次のコード例では、Status という属性を受け取り、これがアクティブ (「A」) でない場合、従業員の全アカウントを無効化します。次の表では、この属性の 4 つの状態を示します。
Status 属性の値に基づいて、アカウントの有効化または無効化を設定できます。
コード例 3-4 受け取ったアクティブでない Status 属性に基づくアカウントの無効化
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Configuration PUBLIC 'waveset.dtd' 'waveset.dtd'>
<Configuration wstype='UserForm' name='PeopleSoft ActiveSync Form'>
<Extension>
<Form>
<!-- this is a sample of how to map the accountID to a different
field than the one from the schema map
Commented out because we want to use the default account
ID mapped from the resource Schema Map.
<Field name='waveset.accountId'>
<Disable><neq><ref>feedOp</ref><s>create</s></neq></Disable>
<Expansion>
<concat><s>ps</s><ref>waveset.accountId</ref></concat>
</Expansion>
</Field>
-->
<!-- this is the real one, limited to create -->
<Field name='waveset.accountId'>
<Disable><neq><ref>feedOp</ref><s>create</s></neq></Disable>
<Expansion>
<ref>activeSync.EMPLID</ref>
</Expansion>
</Field>
<!-- we need to make up a password for accounts that are being
created.This picks the last six digits of the SSN.
-->
<Field name='waveset.password'>
<Disable><neq><ref>feedOp</ref><s>create</s></neq></Disable>
<expression>
<s>change123456</s>
</expression>
</Field>
<Field name='waveset.resources'>
<!-- <Disable><neq><ref>feedOp</ref><s>create</s></neq></Disable> -->
<!-- Don't change the resources list if it already contains peoplesoft -->
<Disable>
<member>
<ref>activeSync.resourceName</ref>
<ref>waveset.resources</ref>
</member>
</Disable>
<expression>
<appendAll>
<ref>waveset.resources</ref>
<ref>activeSync.resourceName</ref>
</appendAll>
</expression>
</Field>
<!-- Status is mapped by the schema map to PS_JOB.EMPL_STATUS which
has at least four states - A for active, T terminated,
L laid off, and S which is a pending change.
The audit data tells us what the state was, and the global
data tells us what it is. Based on the change we can disable
or enable the account
Note that this can happen on a create also!
-->
<Field>
<Disable><eq><ref>activeSync.Status</ref><s>A</s></eq></Disable>
<Field name='waveset.disabled'>
<Expansion>
<s>true</s>
</Expansion>
</Field>
<FieldLoop for='name' in='waveset.accounts[*].name'>
<Field name='accounts[$(name)].disable'>
<expression>
<s>true</s>
</expression>
</Field>
</FieldLoop>
</Field>
<!-- Status is mapped by the schema map to PS_JOB.EMPL_STATUS which has at least four states - A for active, T terminated, L laid off, and S which is a pending change.
This is the enable logic. It is disabled if the account status is <> A or is already enabled
-->
<Field>
<Disable>
<neq>
<ref>activeSync.Status</ref>
<s>A</s>
</neq>
</Disable>
<Field name='waveset.disabled'>
<Disable><eq><ref>waveset.disabled</ref><s>false</s></eq></Disable>
<Expansion>
<s>false</s>
</Expansion>
</Field>
<FieldLoop for='name' in='waveset.accounts[*].name'>
<Field name='accounts[$(name)].disable'>
<Expansion>
<s>false</s>
</Expansion>
</Field>
</FieldLoop>
</Field>
</Form>
</Extension>
<MemberObjectGroups>
<ObjectRef type='ObjectGroup' id='#ID#Top' name='Top'/>
</MemberObjectGroups>
</Configuration>