1.2 ポリシーの概要
この節では、使用できるポリシーのタイプ、Identity Managerにおけるポリシーの役割、および独自のポリシーを定義する方法の概要を説明します。次のトピックについて説明します。
1.2.1 ポリシー
購読者チャネルと発行者チャネルの両方で定義できるポリシーにはさまざまなタイプがあります。各ポリシーは、データ変換のさまざまな段階で適用されます。また、一部のポリシーは特定のアクションが発生した場合にのみ適用されます。たとえば、作成ポリシーは新しいオブジェクトが作成される場合にのみ適用されます。
チャネルでのポリシーの実行順序を次に示します。
図 1-1 ポリシーの実行順序
イベント変換ポリシー
イベント変換ポリシーは、アイデンティティボールトまたは接続アプリケーションで発生したイベントの、メタディレクトリエンジンでのビューを変更します。イベント変換ポリシーで実行される最も一般的なタスクは、スコープフィルタリングやイベントタイプフィルタリングなどのカスタムフィルタリングです。
スコープフィルタリングは、イベントの位置または属性値に基づいて、不要なイベントを削除します。たとえば、部署属性が特定の値と一致しないか、特定のグループのメンバではない場合に、イベントを削除します。
イベントタイプフィルタリングは、イベントタイプに基づいて、不要なイベントを削除します。たとえば、すべての削除イベントを削除します。
例:
- スコープフィルタリング
- タイプフィルタリング
スコープフィルタリング: 次のDirXMLスクリプトポリシーの例では、Usersサブツリー内に含まれ、無効になっておらず、役職属性に「Consultant」または「Manager」という語が含まれていないユーザに対するイベントだけを許可します。操作がブロックされていることを示すステータスドキュメントも生成します。
<policy>
<rule>
<description>Scope Filtering</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
<or>
<if-src-dn op="not-in-subtree">Users</if-src-dn>
<if-attr name="Login Disabled" op="equal">True</if-attr>
<if-attr mode="regex" name="Title" op="equal">.*Consultant.*</if-attr>
<if-attr mode="regex" name="Title" op="equal">.*Manager.*</if-attr>
</or>
</conditions>
<actions>
<do-status level="error">
<arg-string>
<token-text>User doesn’t meet required conditions</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
次のDirXMLスクリプトポリシーは、ユーザオブジェクトに対する変更操作を拒否します。ただし、すでに関連付けられているオブジェクトの変更を除きます。
<policy>
<rule>
<description>Veto all operation on User except modifies of already associated objects</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
<or>
<if-operation op="not-equal">modify</if-operation>
<if-association op="not-associated"/>
</or>
</conditions>
<actions>
<do-veto/>
</actions>
</rule>
</policy>
タイプフィルタリング: 次のDirXMLスクリプトポリシーの例では、最初のルールで、EmployeeおよびContractorコンテナ内のオブジェクトの同期だけを許可します。2つ目のルールでは、すべての名前変更操作および移動操作をブロックします。
<policy>
<rule>
<description>Only synchronize the Employee and Contractor subtrees</description>
<conditions>
<and>
<if-src-dn op="not-in-container">Employees</if-src-dn>
<if-src-dn op="not-in-container">Contractors</if-src-dn>
</and>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text>Change ignored: Out of scope.</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
<rule>
<description>Don’t synchronize moves or renames</description>
<conditions>
<or>
<if-operation op="equal">move</if-operation>
<if-operation op="equal">rename</if-operation>
</or>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text>Change ignored: We don’t like you to do that.</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
次のDirXMLスクリプトポリシーは、すべての追加イベントをブロックします。
<policy>
<rule>
<description>Type Filtering</description>
<conditions>
<and>
<if-operation op="equal">add</if-operation>
</and>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text>Change ignored: Adds are not allowed.</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
一致ポリシー
購読者一致および発行者一致などの一致ポリシーは、ソースデータストア内の関連付けられていないオブジェクトに対応するオブジェクトをターゲットデータストアで検索します。重要な点は、一致ポリシーが常に必要または望ましいとは限らないということです。
たとえば、次の状況では一致ポリシーが望ましくない可能性があります。
- 既存のオブジェクトまたは対応するオブジェクトが存在しない初期移行時
一致ポリシーは、誤った一致が検出されないように十分に注意して作成する必要があります。
例:
- インターネット電子メールアドレスによる一致
- 共通名による一致
IDによる一致: 次のDirXMLスクリプトポリシーの例は、インターネット電子メールアドレスに基づいてユーザを照合します。
<policy>
<rule>
<description>Match Users based on email address</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
</and>
</conditions>
<actions>
<do-find-matching-object>
<arg-dn>
<token-text>ou=people,o=novell</token-text>
</arg-dn>
<arg-match-attr name="Internet EMail Address"/>
</do-find-matching-object>
</actions>
</rule>
</policy>
名前による一致: 次のDirXMLスクリプトポリシーの例では、その共通名属性に基づいて、グループオブジェクトを照合します。
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<rule>
<description>Match Group by Common Name</description>
<conditions>
<or>
<if-class-name op="equal">Group</if-class-name>
</or>
</conditions>
<actions>
<do-find-matching-object scope="subtree">
<arg-match-attr name="CN"/>
</do-find-matching-object>
</actions>
</rule>
</policy>
作成ポリシー
購読者作成ポリシーおよび発行者作成ポリシーなどの作成ポリシーは、新しいオブジェクトを作成するときに満たす必要がある条件を定義します。作成ポリシーがないことは、オブジェクトを作成できることを意味します。
たとえば、アイデンティティボールトに新しいユーザを作成しますが、新しいユーザオブジェクトには名前とIDだけを指定するとします。この作成はeDirectoryツリーでミラーリングされますが、追加はアイデンティティボールトに接続されているアプリケーションでは直ちに反映されません。これは、より完全な定義が指定されたユーザオブジェクトだけを許可するように、作成ポリシーで指定されているためです。
作成ポリシーは、発行者と購読者の両方で同じにすることも別にすることもできます。
テンプレートオブジェクトを指定して、オブジェクトがeDirectoryで作成される場合に作成プロセスで使用することができます。
作成ポリシーは、通常、次の目的で使用されます。
- 属性がないなどの理由で条件を満たさないオブジェクトの作成を拒否する。
- デフォルト属性値を設定する。
- デフォルトパスワードを設定する。
例:
- 必須属性
- デフォルト属性値
- デフォルトパスワード
- テンプレートの指定
必須属性: 次に示すDirXMLスクリプトポリシー例の最初のルールでは、ユーザを作成するにはユーザオブジェクトにCN、名前、名字、インターネット電子メールアドレスの各属性があらかじめ含まれている必要があります。2つ目のルールでは、すべての部門オブジェクトでOU属性が必要になります。最後のルールでは、名前が「Fred」であるすべてのユーザオブジェクトが拒否されます。
<policy>
<rule>
<description>Veto if required attributes CN, Given Name, Surname and Internet EMail Address not available</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
</conditions>
<actions>
<do-veto-if-op-attr-not-available name="CN"/>
<do-veto-if-op-attr-not-available name="Given Name"/>
<do-veto-if-op-attr-not-available name="Surname"/>
<do-veto-if-op-attr-not-available name="Internet EMail Address"/>
</actions>
</rule>
<rule>
<description>Organizational Unit Required Attributes</description>
<conditions>
<or>
<if-class-name op="equal">Organizational Unit</if-class-name>
</or>
</conditions>
<actions>
<do-veto-if-op-attr-not-available name="OU"/>
</actions>
</rule>
</policy>
デフォルト属性値: 次のDirXMLスクリプトポリシーの例では、ユーザの説明属性のデフォルト値を追加します。
<policy>
<rule>
<description>Default Description of New Employee</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
</conditions>
<actions>
<do-set-default-attr-value name="Description">
<arg-value type="string">
<token-text>New Employee</token-text>
</arg-value>
</do-set-default-attr-value>
</actions>
</rule>
</policy>
デフォルトパスワード: 次のDirXMLスクリプトポリシーの例では、名前の最初の2文字と名字の最初の6文字(すべて小文字)で構成したパスワード値を作成します。
<policy>
<rule>
<description>Default Password of [2]FN+[6]LN</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-password op="not-available"/>
</and>
</conditions>
<actions>
<do-set-dest-password>
<arg-string>
<token-lower-case>
<token-substring length="2">
<token-op-attr name="Given Name"/>
</token-substring>
<token-substring length="6">
<token-op-attr name="Surname"/>
</token-substring>
</token-lower-case>
</arg-string>
</do-set-dest-password>
</actions>
</rule>
</policy>
テンプレートの指定: 次のDirXMLスクリプトポリシーの例では、ユーザの役職属性で、そのユーザがマネージャであることが示されている(「Manager」を含んでいる)場合のテンプレートオブジェクトを指定します。
<policy>
<rule>
<description>Assign Manager Template if Title contains Manager</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr name="Title" op="available"/>
<if-op-attr mode="regex" name="Title" op="equal">.*Manager.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-template-dn>
<arg-dn>
<token-text>Users\Manager Template</token-text>
</arg-dn>
</do-set-op-template-dn>
</actions>
</rule>
</policy>
配置ポリシー
配置ポリシーは、新しいオブジェクトを配置する場所と、アイデンティティボールトおよび接続されたアプリケーションでのオブジェクトの名前を決定します。
配置ポリシーはアイデンティティボールトでオブジェクト作成を行う場合に、発行者チャネルで必要です。配置ポリシーは、購読者チャネルでは必須でない場合もあります。これはターゲットデータストアの特性に応じて、接続されたアプリケーションでオブジェクト作成を行う場合も同じです。たとえば、リレーショナルデータベースへの同期では、リレーショナルデータベースの行には位置も名前もないので配置ポリシーは不要です。
例:
- 属性値による配置
- 名前による配置
属性値による配置: 次のDirXMLスクリプトポリシーの例では、部署属性の値に基づいて、特定のコンテナにユーザを作成します。
<policy>
<rule>
<description>Department Engineering</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Department" op="equal">.*Engineering.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Eng</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Department HR</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Department" op="equal">.*HR.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>HR</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
次のDirXMLスクリプトポリシーでは、入力ドキュメントのsrc-dnによって、ユーザまたは部門の配置を決定します。
<policy>
<rule>
<description>PublisherPlacementRule</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
<if-class-name op="equal">Organizational Unit</if-class-name>
</or>
<or>
<if-src-dn op="in-subtree">o=people, o=novell</if-src-dn>
</or>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>People</token-text>
<token-text>\</token-text>
<token-unmatched-src-dn convert="true"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
名前による配置: 次のDirXMLスクリプトポリシーの例では、ユーザの名字の最初の文字に基づいて、特定のコンテナにユーザを配置します。名字がA～Iで始まるユーザはUsers1コンテナ、J～RのユーザはUsers2コンテナ、S～ZはUsers3コンテナに配置されます。
<policy>
<rule>
<description>Surname - A to I in Users1</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[A-I].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users1</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Surname - J to R in Users2</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[J-R].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users2</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Surname - S to Z in Users3</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[S-Z].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users3</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
コマンド変換ポリシー
コマンド変換ポリシーは、コマンドを置き換えるか追加することによって、Identity Managerがターゲットデータストアに送信するコマンドを変更します。削除コマンドを行わずに、それを変更、移動、または無効化コマンドに置き換えるのは、コマンド変換ポリシーのコマンド置き換えの例です。コマンド変換ポリシーでのコマンドの追加の一般的な例として、追加コマンドの属性値に基づいた変更コマンドの作成があります。
基本的には、コマンド変換ポリシーは、メタディレクトリエンジンに送信されたイベントのデフォルト処理の結果としてIdentity Managerが実行するコマンドを変更するために使用されます。
また、他のポリシーの説明に合致しないポリシーをここで含めるのも一般的な使用法です。
例:
- 削除から変更および移動への変換
- 追加操作の作成
- パスワード期限の時刻の設定
削除から変更への変換: 次のDirXMLスクリプトポリシーでは、「ログインの無効化」属性の削除操作を変更操作に変換します。
<policy>
<rule>
<description>Convert User Delete to Modify</description>
<conditions>
<and>
<if-operation op="equal">delete</if-operation>
<if-class-name op="equal">User</if-class-name>
</and>
</conditions>
<actions>
<do-set-dest-attr-value name="Login Disabled">
<arg-value type="state">
<token-text>true</token-text>
</arg-value>
</do-set-dest-attr-value>
<do-veto/>
</actions>
</rule>
</policy>
追加操作の作成: 次のDirXMLスクリプトポリシーでは、ユーザのターゲットコンテナがすでに存在するかどうかを判断します。コンテナがない場合、このポリシーでは、コンテナオブジェクトを作成する追加操作を作成します。
<policy>
<rule>
<description>Check if destination container already exists</description>
<conditions>
<and>
<if-operation op="equal">add</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="target-container">
<arg-string>
<token-dest-dn length="-2"/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="does-target-exist">
<arg-string>
<token-dest-attr class-name="OrganizationalUnit" name="objectclass">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
</token-dest-attr>
</arg-string>
</do-set-local-variable>
</actions>
</rule>
<rule>
<description>Create the target container if necessary</description>
<conditions>
<and>
<if-local-variable name="does-target-exist" op="available"/>
<if-local-variable name="does-target-exist" op="equal"/>
</and>
</conditions>
<actions>
<do-add-dest-object class-name="organizationalUnit" direct="true">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
</do-add-dest-object>
<do-add-dest-attr-value direct="true" name="ou">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
<arg-value type="string">
<token-parse-dn dest-dn-format="dot" length="1" src-dn-format="dest-dn" start="-1">
<token-local-variable name="target-container"/>
</token-parse-dn>
</arg-value>
</do-add-dest-attr-value>
</actions>
</rule>
</policy>
パスワード期限の時刻の設定: 次のDirXMLスクリプトポリシーでは、eDirectoryユーザの「パスワード期限の時刻」属性を変更します。
<?xml version="1.0" encoding="UTF-8"?>
<policy xmlns:jsystem="http://www.novell.com/nxsl/java/java.lang.System">
<rule>
<description>Set password expiration time for a given interval from current day</description>
<conditions>
<and>
<if-operation op="equal">modify-password</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="interval">
<arg-string>
<token-text>30</token-text>
</arg-string>
</do-set-local-variable>
<do-set-dest-attr-value class-name="User" name="Password Expiration Time" when="after">
<arg-association>
<token-association/>
</arg-association>
<arg-value type="string">
<token-xpath expression="round(jsystem:currentTimeMillis() div 1000 + (86400*$interval))"/>
</arg-value>
</do-set-dest-attr-value>
</actions>
</rule>
</policy>
スキーママッピングポリシー
スキーママッピングポリシーは、アイデンティティボールトと接続システム間のスキーママッピングの定義を保持します。
アイデンティティボールトスキーマは、eDirectoryから読み込まれます。接続されているアプリケーションのスキーマは、接続システムのIdentity Managerドライバから提供されます。2つのスキーマが特定された後、アイデンティティボールトとターゲットアプリケーション間で単純なマッピングが作成されます。
スキーママッピングポリシーをIdentity Managerドライバ環境設定に定義した後は、対応するデータをマップできます。
次の点に十分注意してください。
- 同じポリシーが両方向で適用されます。
- メタディレクトリエンジンとアプリケーションシム間で渡されるドキュメントは、いずれのチャネルでも、またいずれの方向でも、すべてのドキュメントがスキーママッピングポリシーを通過します。
管理情報については、セクション 7.0, スキーママッピングポリシーの管理を参照してください。
例:
- 基本的なスキーママッピングポリシー
- カスタムスキーママッピングポリシー
基本的なスキーママッピングポリシー: 次のDirXMLスクリプトポリシーの例では、基本的なスキーママッピングポリシーのXMLソースをそのまま表示しています。ただし、Identity ManagerのDesignerを使用してポリシーを編集する場合、デフォルトのスキーママッピングエディタでは、ポリシーをグラフィカルに表示および編集できます。
<?xml version="1.0" encoding="UTF-8"?><attr-name-map>
<class-name>
<app-name>WorkOrder</app-name>
<nds-name>DirXML-nwoWorkOrder</nds-name>
</class-name>
<class-name>
<app-name>PbxSite</app-name>
<nds-name>DirXML-pbxSite</nds-name>
</class-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>PBXName</app-name>
<nds-name>DirXML-pbxName</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>TelephoneNumber</app-name>
<nds-name>Telephone Number</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>LoginName</app-name>
<nds-name>DirXML-pbxLoginName</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>Password</app-name>
<nds-name>DirXML-pbxPassword</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>Nodes</app-name>
<nds-name>DirXML-pbxNodesNew</nds-name>
</attr-name>
</attr-name-map>
カスタムスキーママッピングポリシー: 次のDirXMLスクリプトポリシーの例は、DirXMLスクリプトを使用してカスタムスキーママッピングを実行します。
<?xml version="1.0" encoding="UTF-8"?><policy>
<rule>
<!--
The Schema Mapping Policy can only handle one-to-one mappings.
That Mapping Policy maps StudentPersonal addresses.
This rule maps StaffPersonal addresses.
-->
<description>Publisher Staff Address Mappings</description>
<conditions>
<and>
<if-local-variable name="fromNds" op="equal">false</if-local-variable>
<if-xpath op="true">@original-class-name = ’StaffPersonal’</if-xpath>
</and>
</conditions>
<actions>
<do-rename-op-attr dest-name="SA" src-name="Address/Street/Line1"/>
<do-rename-op-attr dest-name="Postal Office Box" src-name="Address/Street/Line2"/>
<do-rename-op-attr dest-name="Physical Delivery Office Name" src-name="Address/City"/>
<do-rename-op-attr dest-name="S" src-name="Address/StatePr"/>
<do-rename-op-attr dest-name="Postal Code" src-name="Address/PostalCode"/>
</actions>
</rule>
<rule>
<description>Subscriber Staff Address Mappings</description>
<!--
The Schema Mapping Policy has already mapped addresses to StudentPersonal.
This rule maps StudentPersonal to StaffPersonal.
-->
<conditions>
<and>
<if-local-variable name="fromNds" op="equal">true</if-local-variable>
<if-op-attr name="DirXML-sifIsStaff" op="equal">true</if-op-attr>
</and>
</conditions>
<actions>
<do-rename-op-attr dest-name="Address/Street/Line1" src-name="StudentAddress/Address/Street/Line1"/>
<do-rename-op-attr dest-name="Address/Street/Line2" src-name="StudentAddress/Address/Street/Line2"/>
<do-rename-op-attr dest-name="Address/City" src-name="StudentAddress/Address/City"/>
<do-rename-op-attr dest-name="Address/StatePr" src-name="StudentAddress/Address/StatePr"/>
<do-rename-op-attr dest-name="Address/PostalCode" src-name="StudentAddress/Address/PostalCode"/>
</actions>
</rule>
</policy>
出力変換ポリシー
出力変換ポリシーは主に、メタディレクトリエンジンが提供するデータからアプリケーションシムで求められるデータへのデータ形式の変換を行います。次に変換の例を示します。
- 属性値の形式の変換
- XMLボキャブラリの変換
- 出力変換ポリシーでは、メタディレクトリエンジンからアプリケーションシムに返されるステータスメッセージのカスタム処理も提供できます
いずれかのチャネルでメタディレクトリエンジンがアプリケーションシムに提供するドキュメントはすべて出力変換ポリシーを通過します。出力変換はスキーママッピングの後に実行されるので、すべてのスキーマ名はアプリケーションネームスペース内にあります。
例:
- 属性値の形式の変換
- ステータスメッセージのカスタム処理
属性値の変換: 次のDirXMLスクリプトポリシーの例は、電話番号を「(nnn) nnn-nnnn」形式から「nnn.nnn.nnnn」形式に再フォーマットします。逆の変換については、入力変換ポリシーの例を参照してください。
<policy>
<rule>
<description>Reformat all telephone numbers from (nnn) nnn-nnnn to nnn.nnn.nnnn</description>
<conditions/>
<actions>
<do-reformat-op-attr name="telephoneNumber">
<arg-value type="string">
<token-replace-first regex="^\((\d\d\d)\) *(\d\d\d)-(\d\d\d\d)$" replace-with="$1.$2.$3">
<token-local-variable name="current-value"/>
</token-replace-first>
</arg-value>
</do-reformat-op-attr>
</actions>
</rule>
</policy>
ステータスメッセージのカスタム処理: 次のDirXMLスクリプトポリシーの例では、レベルが「success」と等しくなく、また操作データ内に子のpassword-publish-status要素を含むステータスドキュメントを検出し、DoSendEmailFromTemplate(テンプレートから電子メールを送信)アクションを使用して電子メールを生成します。
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<description>Email notifications for failed password publications</description>
<rule>
<description>Send e-mail for a failed publish password operation</description>
<conditions>
<and>
<if-global-variable mode="nocase" name="notify-user-on-password-dist-failure" op="equal">true</if-global-variable>
<if-operation op="equal">status</if-operation>
<if-xpath op="true">self::status[@level != ’success’]/operation-data/password-publish-status</if-xpath>
</and>
</conditions>
<actions>
<!-- generate email notification -->
<do-send-email-from-template notification-dn="\cn=security\cn=Default Notification Collection" template-dn="\cn=security\cn=Default Notification Collection\cn=Password Sync Fail">
<arg-string name="UserFullName">
<token-src-attr name="Full Name">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="UserGivenName">
<token-src-attr name="Given Name">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="UserLastName">
<token-src-attr name="Surname">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="ConnectedSystemName">
<token-global-variable name="ConnectedSystemName"/>
</arg-string>
<arg-string name="to">
<token-src-attr name="Internet Email Address">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="FailureReason">
<token-text/>
<token-xpath expression="self::status/child::text()"/>
</arg-string>
</do-send-email-from-template>
</actions>
</rule>
</policy>
入力変換ポリシー
入力変換ポリシーは主に、アプリケーションシムが提供するデータからメタディレクトリエンジンで求められるデータへのデータ形式の変換を行います。次に変換の例を示します。
- 属性値の形式の変換
- XMLボキャブラリの変換
- ドライバハートビート
- 入力変換ポリシーでは、アプリケーションシムからメタディレクトリエンジンに返されるステータスメッセージのカスタム処理も提供できます。
いずれかのチャネルでアプリケーションシムがメタディレクトリエンジンに提供するドキュメントはすべて入力変換ポリシーを通過します。
例:
- 属性値の形式の変換
- ドライバハートビート
属性値の形式の変換: 次のDirXMLスクリプトポリシーの例では、電話番号を「nnn.nnn.nnnn」形式から「(nnn) nnn-nnnn」形式に再フォーマットします。逆の変換については、出力変換ポリシーの例を参照してください。
<policy>
<rule>
<description>Reformat all telephone numbers from nnn.nnn.nnnn to (nnn) nnn-nnnn</description>
<conditions/>
<actions>
<do-reformat-op-attr name="telephoneNumber">
<arg-value type="string">
<token-replace-first regex="^(\d\d\d)\.(\d\d\d)\.(\d\d\d\d)$" replace-with="($1) $2-$3">
<token-local-variable name="current-value"/>
</token-replace-first>
</arg-value>
</do-reformat-op-attr>
</actions>
</rule>
</policy>
ドライバハートビート: 次のDirXMLスクリプトポリシーでは、ステータスハートビートイベントを作成します。ドライバのハートビート機能は、各ハートビート間隔の成功メッセージ(HEARTBEAT: $driver)の送信に使用されます。メッセージは、Novell Auditによって監視されます。Identity Managerドライバは、ハートビートをサポートしている必要があります。また、ハートビートがドライバ環境設定ページで有効になっている必要があります。
<?xml version="1.0" encoding="UTF-8" ?>
<policy>
<rule>
<description>Heartbeat Rule, v1.01, 040126, by Holger Dopp</description>
<conditions>
<and>
<if-operation op="equal">status</if-operation>
<if-xpath op="true">@type="heartbeat"</if-xpath>
</and>
</conditions>
<actions>
<do-set-xml-attr expression="." name="text1">
<arg-string>
<token-global-variable name="dirxml.auto.driverdn" />
</arg-string>
</do-set-xml-attr>
<do-set-xml-attr expression="." name="text2">
<arg-string>
<token-text>HEARTBEAT</token-text>
</arg-string>
</do-set-xml-attr>
</actions>
</rule>
</policy>
1.2.2 ポリシーの定義
すべてのポリシーは、次の2つの方法のいずれかで定義されます。
- ポリシービルダインタフェースを使用してDirXMLスクリプトを作成する。既存のXSLT以外のルールは、インポート時に自動的にDirXMLスクリプトに変換されます。
- XSLTスタイルシートを使用する。
スキーママッピングポリシーは、スキーママッピングテーブルを使用して定義することもできます(通常はこちらが使用されます)。
ポリシービルダおよびDirXMLスクリプト
ポリシービルダインタフェースは、実装するポリシーのほとんどの定義に使用されます。ユーザがポリシーを簡単に定義および管理できるように、ポリシービルダインタフェースでは、グラフィック環境が使用されます。
ポリシービルダ内のルール作成の基になる機能は、DirXMLスクリプトと呼ばれるカスタムスクリプト言語によって提供されます。
DirXMLスクリプトには、テスト可能な多岐にわたる条件、実行するアクション、およびポリシーに追加する動的な値が含まれます。これらのオプションはいずれも、それぞれの場所で有効な選択肢のみを提示するインテリジェントドロップダウンリスト、および共通の値へのクイックリンクを使用して表示されます。
ポリシービルダを使用すれば、DirXMLスクリプトを直接変更する必要はありません。
ポリシービルダの詳細については、セクション 2.0, Designerでポリシービルダを使用したポリシーの定義およびセクション 3.0, iManagerのポリシービルダを使用したポリシーの定義を参照してください。DirXMLスクリプトの詳細については、セクション 1.1.2, DirXMLスクリプトを参照してください。
ヒント:ポリシービルダは使用しなくてもかまいません。完全なDirXMLスクリプトについては、DirXML Driver Developer Kit DocumentationのWebサイトを参照してください。
XSLTスタイルシート
より複雑なポリシーを定義するには、XSLTスタイルシートを使用して、XMLドキュメントを、必要な変更を含む別のXMLドキュメントに直接変換します。
スタイルシートでは柔軟な指定ができるので、ポリシービルダのルール作成を使用して利用できる定義済みの条件およびアクションに合わない場合に使用されます。
XSLTスタイルシートを作成するには、XSLT、nds.dtd、およびメタディレクトリエンジンとの間で変換するコマンドおよびイベントについて十分に理解しておく必要があります。nds.dtdの詳細については、NDS DTDを参照してください。
XSLTスタイルシートの詳細については、セクション 5.0, XSLTスタイルシートを使用したポリシーの定義を参照してください。
ダウンロード可能なIdentity Managerポリシー
Novellでは、ダウンロードして自分の環境で使用できるサンプルポリシーが用意されています。ポリシーは、Patches (NovellのサポートWebサイト)で入手できます。ファイルをダウンロードし、それを解凍します。How_To_Install.rtfファイルには、インストールの手順が含まれています。
Designerを使用してファイルをインポートするには、XMLファイルからのポリシーのインポートを参照してください。iManagerを使用してファイルをインポートするには、セクション 3.2.9, XMLファイルからのポリシーのインポートを参照してください。