6.13 ルール、ポリシー、およびスタイルシート
識別マネージャのルールはポリシーの集合です。各ルールは、満たさなければならない条件と、条件が真の場合に実行するアクションで構成されます。条件の文法は人間が読めるようになっており、おおむね意味を理解できます。たとえば、「if object class equal user」という条件は、現在の文書で記述されているオブジェクトがユーザオブジェクトならばTrueになり、オブジェクトがグループならばFalseになります。条件は条件グループで構成されています。1つの条件グループ内で、すべての条件をAndまたはOrで組み合わせることができます。結果がTrueならば、条件グループはTrueと評価され、それ以外の場合はFalseと評価されます。AndとOrを使って複数の条件グループを組み合わせることもできます。条件グループがTrueと評価されると、ルールのアクションが実行されます。
図 6-2 ポリシービルダの条件
アクションは現在の文書に対して実行できます。多くの場合はこれで十分ですが、アクションでは、ソースまたはあて先(現在のチャネルに応じて識別ボールトまたは接続システム)に追加情報を問い合わせることもできます。また、現在の文書を変更してその変更版を作成したり、文書全体をブロックしたりすることもできます。アクションを使用してさまざまな文書を作成できます。たとえば、接続システム内の削除イベントを記述する文書を条件(if operation equal delete)でテストして、一連のアクションを実行することで、関連付けられたオブジェクトが識別ボールトから削除されないようにし(veto)、代わりに、そのオブジェクトを変更して関連付け値をアプリケーションから削除し(remove-association)、その値を無効にすることができます(set destination attribute value Login Disabled = True)。
図 6-3 ポリシービルダのアクション
ポリシーは、転送するデータを定義し、接続システムと識別ボールト間でデータを同期する方法を指定します。ポリシーのデフォルト設定は、ドライバの構成で使用できます。これ以外のポリシーは、ドライバのローカルカスタマイズ版として使用できます。ポリシーは、DirXMLスクリプト、XSLT、ECMAスクリプトを使用して記述できます。
ポリシーの目的は、入力文書に何か変更を加えて出力文書を生成することです。多くのポリシーは、購読者チャネルと発行者チャネルのいずれか一方のみで評価されます。スキーママッピングポリシー、入力変換ポリシー、および出力変換ポリシーは両方のチャネルで評価されます。たとえば、ある組織ではメインのユーザクラスとしてinetOrgPersonを使用していて、別の組織ではUserを使用しているとします。最初の組織に対して、電話番号の変更をinetOrgPersonに追加するポリシーを実装し、これが機能するようにUserクラスには別のルールを実装することもできます。ポリシーは、スキーマ変換の実行や、オブジェクトが接続システムまたは識別ボールトにすでに存在するかどうかを判定するマッチング条件の指定など、多くのタスクを実行します。このため、追加したオブジェクトが識別ボールトにすでに存在するとマッチングポリシーによって判定された場合、接続システムによってレポートされたAddイベントが、識別ボールトで変更操作として送信される場合があります。
購買者チャネルでは、新しいユーザが識別ボールトで作成されたとき、Identity Managerエンジンが一連のポリシーを呼び出し、コマンドがドライバへ送信される前に、接続システムでそのユーザを作成する必要があります。それらのポリシーは、オブジェクトの作成方法を定義し、対応するユーザが接続システムにすでに存在するかどうかを判断します。さらに、配置について決定したり、値が未定義の必須の属性にデフォルト値を指定したりします。このAddイベントは、オブジェクトが接続システム内に存在する場合、変更イベントに変換できます。元のイベントに含まれていない属性を追加して、接続システムのオブジェクト作成モデルを確認できます。
スタイルシートは、XSLTの変換ルールを定義します。スタイルシートは、入力または出力コマンドを別のコマンドに変換したり、イベントをある種類から別の種類に変更したり、その他の任意のXML変換を実行したりできます。詳細については、Identity ManagerのStyle Sheetsに関する説明を参照してください。
6.13.1 入力変換ルール
入力変換ルールは、購読者チャネルと発行者チャネルの両方に適用されます。入力変換ルールの目的は、接続システムがIdentity Managerに送信するすべてのXML文書と選択システムがIdentity Managerに返すすべてのXML文書に対して予備的な変換を実行することです。入力変換ルールは、接続システムから呼び出されると、XmlCommandProcessor.executeおよびXmlQueryProcessor.queryに送信されるXML文書に適用され、Identity Managerエンジンに呼び出されると、SubscriptionShim.executeおよびXmlQueryProcessor.queryから返されるXMLドキュメントに適用されます。入力変換ポリシーは、スキーママッピングポリシーよりも先に適用されます。
入力変換ルールは、しばしばアプリケーションの形式から識別ボールトの形式へデータを変換するために使用されます。入力変換を使用してデータ形式を変換する場合は、通常、出力変換ポリシーで逆方向のデータ変換を実行します（つまり、識別ボールトの形式からアプリケーションの形式へデータを変換します）。このルールは、アプリケーションのネームスペースで動作します。たとえば、1(815)555-1212の形式の電話番号を1-815-555-1212の形式に変更するなど、データの形式を変更するために使用できます。シムに送信したコマンドの結果に応じてアクションを実行するために、入力変換ルールも使用されます。スキーマ名は常に、入力変換ポリシーで処理されるXMLのアプリケーションネームスペースにあります。入力変換ポリシーを使って、接続アプリケーションに固有の任意のXML形式からIdentity Managerが要求する形式に変換することもできます。この変換は、XSLTで記述する必要があります。これは、DirXMLスクリプトがIdentity Manager専用のXMLボキャブラリのみで動作するためです。
6.13.2 出力変換ルール
出力変換ポリシーは、購読者チャネルと発行者チャネルの両方に適用されます。出力変換ポリシーの目的は、Identity Managerエンジンがシムに送信するすべてのXML文書とIdentity Managerエンジンがシムに返すすべてのXML文書に対して最後の変換を実行することです。出力変換ポリシーは、Identity Managerから呼び出されると、SubscriptionShim.executeおよびXmlQueryProcessor.queryに送信されるXML文書に適用され、シムから呼び出されると、XmlCommandProcessor.executeおよびXmlQueryProcessor.queryから返されるXMLドキュメントに適用されます。出力変換ルールは、スキーママッピングルールよりも後に適用されます。
出力変換ルールは入力変換ルールの逆です。必要時にシムに送信されるコマンドを変更します。これは、多くの場合、入力変換ルールで行われた操作を元に戻すときに使用されます。たとえば、1(815)555-1212の形式の電話番号を1-815-555-1212に変換する入力変換ルールがある場合、1-815-555-1212を1(815)555-1212に変換する出力変換ルールが必要になります。
また、出力変換ポリシーを使用して、Identity Managerで使用されている形式を任意の接続アプリケーションのネイティブXMLフォーマットに変換することができます。このような変換は、XSLTで記述する必要があります。これは、DirXMLスクリプトがIdentity Manager専用のXMLボキャブラリのみで動作するためです。
6.13.3 関連付け
関連付け値は、接続システム内のどのオブジェクトが識別ボールト内のどのオブジェクトに対応するかをIdentity Managerで把握するための手段です。ほとんどの場合、これは一対一の対応です。したがって、HRシステム内の「john doe」、従業員番号1234567が、識別ボールト内のユーザオブジェクト「jdoe13」、Active Directory内の「doe john」、および電子メールシステム内の「jdoe13@example.com」と完全に一致すると仮定できます。ほとんどのコンピュータシステムには、何らかの内部固有識別子があります。eDirectoryとActive Directoryにはグローバル一意識別子、つまりGUIDがあります。多くのHRシステムには従業員番号があります。電子メールシステムには通常、一人ひとりの一意の電子メールアドレス値があります。Identity Managerでは、それらの識別子を使用して関連付けを作成します。関連付けは識別ボールトに格納されます。購読者チャネルでは、Identity Managerエンジンがこの値を使用して、接続システム内の正しいオブジェクトをシムが変更できるようにします。発行者チャネルでは、シムが関連付け値を供給し、識別ボールト内の正しいオブジェクトをIdentity Managerエンジンがすばやく簡単に検索できるようにします。
6.13.4 合成Add
Modify操作がAddプロセッサに到達したときに実際のオブジェクトへと解決する関連付けが含まれていない場合、Identity ManagerエンジンがModifyイベントを合成Addプロセスに変換します。これを合成Add処理といい、発行者チャネルと購読者のどちらでも発生する可能性がありますIdentity ManagerエンジンはModifyイベントを使用して、どのオブジェクトを操作するかを特定します。次に、フィルタを使ってソースに問い合わせ、そのオブジェクトに利用できる属性のうち、現在のチャネル上でSyncまたはNotifyに設定されているものをすべて取得します。さらにModifyイベントを廃棄して、それに代わるAddイベントを作成します。このAddイベントはその後、マッチング、作成、配置、およびコマンド変換を通過します(購読者チャネルではスキーママップと出力変換も通過します)。イベント変換ルールは、合成Addを起動しません。これは、ルールの位置がAddプロセッサより前にあるためです。
図 6-4 購読者チャネルの関連付けプロセッサ
6.13.5 マージ処理
Merge操作は、Identity ManagerエンジンがAdd操作をModify操作に変換するときに発生します。これが最もよく発生するのは、初期マイグレーション時にmigrateがオブジェクトをチャネルに送信し、マイグレートするオブジェクトと関連付けることができるオブジェクトをマッチングルールで検索するときです。
Merge操作の場合、最新の文書は、合成Add操作のように破棄され、フィルタは、すべての値について接続システムと識別ボールトの両方にクエリを実行するために使用されます。次に、フィルタ内の各属性の設定によって、データの処理方法が決まります。処理方法として、ソースの情報をあて先の情報で上書きする、あて先の情報をソースの情報で上書きする、2つを組み合わせてその結果で両方を更新する、何もしないなどがあります。次のフローチャートは、発行者マージプロセッサと購読者マージプロセッサを示しています。
図 6-5 発行者マージプロセッサ
図 6-6 購読者マージプロセッサ
