midPoint におけるマルチバリュー項目に対するマッピング処理

はじめに

midPoint by OpenStandia Advent Calendar 2024 の7日目は、5日目で説明しきれなかった下記の2つ目について、補足します。1つ目については4日目の記事で補足していますので、そちらを参照してください。

• 源泉削除に対する同期処理
• マルチバリュー項目に対するマッピング処理

5日目で構築したDocker Composeを利用した環境が前提となります。

マルチバリュー項目に対するマッピング処理

5日目の記事にて、マッピング先の属性がマルチバリュー項目の場合に、midPointでは安全のため他の値を消さない（洗い替えしない）という戦略をデフォルトで取っているとお伝えしました。これについて、midPointの公式ガイドでは、以下で述べられています。

• Mappings: Replacing and Removing Values
• Mapping Range
• Range Of Inbound Mappings

特に、マルチバリュー項目に関しては、あるマッピング処理結果で生み出された値の反映だけすればよいか、もしくはその値以外の既存の値を削除、つまりすべて洗い替えるかは難しい問題です。マッピング先の属性を決定するのが、とある源泉データ1つであれば分かりやすいです。信頼できるソース（IGA/IDMの世界ではAuthoritative Sourceとよく呼びます）が1つなので、そこからマッピングされる値ですべて洗い替えても問題ないはずです。

しかし、現実にはそうではないケースがあります。例えば、管理者による画面操作で、その属性に値が追加されるケースも考えられます。他にも、別の源泉システムから同じ属性に値を設定するケースも考えられます。そうなると、単純に洗い替えてしまうと危険なわけです。

midPointとしては、自動的に洗い替えるのではなくて、マッピングの設定者にどの値を削除するか細かくコントロールすることを求めています。そこで登場するのが、 「Mapping Range」 です。これは、マッピングの際にどの範囲の値を削除するか制御するために使用される機能です。リソースの設定において、インバウンドマッピングでこのMapping Rangeの設定を行うと、このリソースからmidPointへのデータのマッピングの際に、どの値を削除する/しないを細かく制御することが可能になります。

なお、Mapping Rangeはリソースのインバウンドマッピングに限らず、以下のような他のマッピング設定箇所でも利用可能です。

• リソース設定のアウトバウンドマッピング
• Object Templateでのマッピング

特にアウトバウンドマッピングのケースでは、値の削除する/しないの処理はmidPoint側ではなく、プロビジョニング先になります。往々にしてリソース側で手動メンテされ値が追加されたりすることはありますので、そういった値を洗い替えて削除してしまうと事故になるわけで、midPointとしては慎重にデフォルトでは消さない、という戦略を取っています。

実はmidPoint 4.9ではこのあたりの機能強化が行われ、自動的に判断して値を削除するモードが追加されました。4.9のMapping Rangeのドキュメントをみると、Range DefinitionにmatchingProvenanceという定義が追加されていることが分かります。これを利用すると、そのマッピングで設定された値をメタデータとして現在の値とは別に保存しておき、次回のマッピングで設定されなければ自動的に削除する、といった制御を行っているようです。

Mapping Rangeの設定

では、試しにMapping Rangeを設定し、5日目で問題となっていた主務組織と兼務組織で洗い替えを行うようにしてみます。

残念ながらMapping Rangeの設定は、midPoint 4.8/4.9 ではまだGUIサポートがされていません。よって、この設定はリソース設定のRaw更新で行う必要があります。HRシステムの源泉CSVのリソース編集画面を開き、「RAWデータの編集」ボタンをクリックしてRaw編集画面を開きます。

primaryOrgIdとsecondaruOrgIdsのインバウンドマッピング設定箇所を探し、<target>タグ配下に、以下の<set>〜</set>を挿入して「保存」ボタンをクリックします。predefinedは事前定義された値で、allを指定するとそのマッピングで設定される値以外のものは削除する、つまり洗い替えるという動作になります。

            <attribute id="15">
                <ref>ri:primaryOrgId</ref>
                <inbound id="16">
                    <strength>strong</strength>
                    <target>
                        <path>organization</path>
+                       <set>
+                           <predefined>all</predefined>
+                       </set>
                    </target>
                </inbound>
            </attribute>
            <attribute id="17">
                <ref>ri:secondaryOrgIds</ref>
                <inbound id="18">
                    <strength>strong</strength>
                    <target>
                        <path>organizationalUnit</path>
+                       <set>
+                           <predefined>all</predefined>
+                       </set>
                    </target>
                </inbound>
            </attribute>

CSVの更新とインポートタスクの実行

では、5日目では駄目だったケースを試してみます。

1001ユーザーが以下の状態のCSVをmidPointにインポートした状態から始めます。

1001,太郎,山田,[e-mail],005,006;007

1001の詳細画面をみると以下の状態です。

では、CSVを以下のように編集します。

1001,太郎,山田,[e-mail],005,006;007
↓
1001,太郎,山田,[e-mail],006,007;009

これで再度インポートタスクを実行します。すると今度は、CSVに記載の値で完全に入れ替わっています。期待通り洗い替えが行われました。

高度なRange Mapping設定

より高度な設定として、predefinedを使わずにスクリプトを記述することで、何を削除するかロジック実装することができます。例として、先頭が1から始まる値の場合は削除対象外としてみます。

まずは現状の状態で、画面から100を組織単位に追加して保存してみます。をクリックすると入力項目が追加されるので、100を設定します。これで「保存」ボタンをクリックして保存します。

再度ユーザー詳細画面を開いても、まだ100は存在します。

この状態で、再度インポートタスクを実行します。すると想定どおり洗い替えが行われ、画面から入力した100は削除されます。

では、再度リソース設定のRaw編集画面を開き、以下のように変更します。predefinedは削除し、<condition>〜</condition>を追加します。このタグを使うと、条件をGroovyスクリプトで設定することができます。このスクリプトの評価結果では、boolean値を返すことが期待されています。その値により削除の挙動が決まります。

• trueの場合：値を削除する
• falseの場合：値を削除しない

スクリプト内では、<path>organizationalUnit</path>とパス定義したものを使って、その属性の値を1つずつその変数名称で参照することができます。今回、!organizationalUnit?.startsWith("1")と記述しているので、

• 0から始まる値：true → 削除、つまり洗い替え対象
• 1から始まる値：false → 削除しない、つまり洗い替え対象外

という挙動になります。

            <attribute id="17">
                <ref>ri:secondaryOrgIds</ref>
                <inbound id="18">
                    <strength>strong</strength>
                    <target>
                        <path>organizationalUnit</path>
+                       <set>
-                           <predefined>all</predefined>
+                           <condition>
+                               <script>
+                                   <code>
+                                       !organizationalUnit?.startsWith("1")
+                                   </code>
+                               </script>
+                           </condition>
                        </set>
                    </target>
                </inbound>
            </attribute>

これで再度画面から100を追加して保存した上で、インポートタスクを再実行してみましょう。そうすると、今度は100が残り続けています。

本当に1から始まるもの以外は洗い替えられるか、またCSVファイルを編集して試してみます。元の所属組織の状態に戻してみます。

1001,太郎,山田,[e-mail],006,007;009
↓
1001,太郎,山田,[e-mail],005,006;007

これで再度インポートタスクを実行します。すると結果は以下のようになります。100だけが残り、他の値は洗い替えが行われました。このように、<condition>タグを利用すると細かくRange Mappingを設定することができます。

まとめ

7日目は、5日目で説明しきれなかった 「マルチバリュー項目に対するマッピング処理」 について、補足解説を行いました。

midPointがなぜデフォルトでマルチバリュー項目の値をマッピング処理で洗い替えないか、解説しました。また、その挙動をカスタマイズする 「Range Mapping」 の設定例を紹介しました。

これでようやく次回は、組織データのインポートについて紹介したいと思います。組織データのインポートでは、6日目の記事で解説したリコンシリエーションタスクと、本記事で解説したRange Mappingの両方を使います。お楽しみに！