midPoint からCSVにプロビジョニングする

[midPoint by OpenStandia Advent Calendar 2024](https://qiita.com/advent-calendar/2024/midpoint-by-openstandia) の11日目は、いよいよmidPointからプロビジョニングしてみます。これまでは源泉システム（HRシステム）からCSVファイルでユーザーと組織情報をmidPointにインポートする部分を設定してきました。今回は外部のシステムにmidPointで保持しているデータをプロビジョニングする部分を設定していきます。連携先の種類として、一番シンプルであるCSVを利用します。

:::note info
10日目までで構築した環境が前提となります。
:::

# 連携先システムの仕様

今回のサンプル連携システムは、「アドレス帳（Addressbook）」システムとします。このシステムはCSVファイルで、以下の情報を受け取る仕様とします。

- **userId**：従業員番号
- **familyName**：姓
- **givenName**：名
- **email**：メールアドレス
- **tel**：電話番号
- **orgId**：主務組織の名称
- **orgName**：主務組織の名称

出力されるCSV内容例としては以下のイメージです。

```csvs
userId,familyName,givenName,email,tel,orgId,orgName
1001,山田,太郎,taro.yamada@example.com,09001234567,005,営業第一部
...（省略）
```

出力されるCSVファイルの空データのもの（ヘッダ行のみ存在）を作成し、`./addressbook/users.csv`として配置しておきます。midPointからはこのファイルにユーザー情報をプロビジョニングするように設定します。

```
.
├── .env
├── addressbook
│   └── users.csv
├── docker-compose.yml
├── hr
│   ├── orgs.csv
│   └── users.csv
└── post-initial-objects
    ├── 000-system-configuration.xml
    ├── 100-resource-hr-orgs.xml
    ├── 100-resource-hr-users.xml
    ├── 900-task-hr-import-users.xml
    └── 900-task-hr-recon-orgs.xml
```

```csvs:./addressbook/users.csv（ヘッダ行のみ存在）
userId,familyName,givenName,email,tel,orgId,orgName
```


# docker-compose.ymlの修正

`./addressbook/`配下をmidPointコンテナからアクセスできるように、`docker-compose.yml`を以下のように修正しておきます。これで、midPointからは`/var/lib/addressbook/users.csv`でこのファイルにアクセスできます。

```diff_yaml:docker-compose.yml
  midpoint_server:
    image: evolveum/midpoint:${MP_VER:-latest}-alpine
    container_name: midpoint_server
    hostname: midpoint-container
    depends_on:
      data_init:
        condition: service_completed_successfully
      midpoint_data:
        condition: service_started
    command: [ "/opt/midpoint/bin/midpoint.sh", "container" ]
    ports:
      - 8080:8080
    environment:
     - MP_SET_midpoint_repository_jdbcUsername=midpoint
     - MP_SET_midpoint_repository_jdbcPassword=db.secret.pw.007
     - MP_SET_midpoint_repository_jdbcUrl=jdbc:postgresql://midpoint_data:5432/midpoint
     - MP_SET_midpoint_repository_database=postgresql
     - MP_SET_midpoint_administrator_initialPassword=Test5ecr3t
     - MP_UNSET_midpoint_repository_hibernateHbm2ddl=1
     - MP_NO_ENV_COMPAT=1
     - MP_ENTRY_POINT=/opt/entry-point
     - TZ=Asia/Tokyo
    networks:
     - net
    volumes:
     - midpoint_home:/opt/midpoint/var
     - ./post-initial-objects:/opt/entry-point/post-initial-objects:ro
     - ./hr:/var/lib/hr
+    - ./addressbook:/var/lib/addressbook
```

# midPointの起動

`docker compose up -d`で環境を起動します。


# リソース設定の追加

[5日目の記事](https://qiita.com/wadahiro/items/a239a743af5404a7325f)などで解説した源泉データのインポートと同じように、プロビジョニングする際もリソース設定の追加を行います。作成の流れは基本的に同じですので、具体的な操作は過去の記事も参考にしてください。

midPointでは源泉データの取り込みもプロビジョニングも、リソースを作成してオブジェクト・タイプを追加し、その外部システムとのマッピングを定義します。今までは源泉データからの取り込みを実施するため、インバウンドマッピングという種類のマッピングを設定していました。一方、プロビジョニングの場合は、アウトバウントマッピングという種類のマッピングを設定します。


:::note info
midPointでは、インバウンドマッピングとアウトバウンドマッピングの両方を設定し、双方向の同期を設定することも可能です。ただし、データフローが複雑化するため、基本的には一方向にデータが流れるように全体を設計した方がよいでしょう。
:::

新規リソース作成時のリソースカタログでは、CSVファイルに連携したいため「CsvConnector」選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/e0bfbd8d-ee1f-53d4-c568-1070b165e3f2.png)

基本情報の設定です。区別が付くように名前を設定します。

- **名前**：`Addressbook Users`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/e8922cf3-238a-6f90-f3d8-f60dfdd9e526.png)

先ほど配置したヘッダのみのCSVファイルのパス（midPointコンテナ内での）を設定します。

- **File path**：`/var/lib/addressbook/users.csv`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/a5816444-92ab-f4d6-ee1f-67fd6f90eac4.png)


CSVコネクターの設定は下記の通りとします。

- **Field delimiter**：`,`
- **User password attribute name**：（空のまま）
- **Name attribute**：`userId`
- **Unique attribute name**：`userId`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/4241c151-3e02-91f4-92f7-d95dc465a33f.png)


オブジェクトタイプ・スキーマはデフォルトの「AccountObjectClass」のままでよいです。これでリソースの作成を行います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/3347f617-46c3-c534-1da7-b2ec3f29ac13.png)


## オブジェクト・タイプの追加

続いて作成した「Addressbook Users」リソースに、オブジェクトタイプを追加していきます。基本情報では、以下を設定します。

- **表示名**：`Account`
- **種類**：`アカウント`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/7ba030dc-d509-438d-5b46-1e1c75bb0172.png)


リソース・データの設定はデフォルトのままで次へ進みます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/a90862c0-85fa-001d-3ecb-465268dab113.png)


MidPointデータの設定では、以下を設定します。midPoint内のユーザーオブジェクトをプロビジョニングするため、ここでは**ユーザー**を選択します。

- **タイプ**：`ユーザー`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/827a2af1-cab6-1cc0-4253-a30e0bd2be75.png)

### マッピングの設定

マッピングの設定では、プロビジョニングを行うために **「アウトバウンドマッピング」** タブをクリックし、こちらのマッピングを追加していきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/21b5b351-cd3d-049b-09ee-2e94c649dc2a.png)

「アウトバウンドの追加」ボタンをクリックすると、編集行が追加されます（緑色の箇所）。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/3bf7134d-c3ae-ef74-ec90-f1fb3eee4001.png)

入力フィールドではサジェスト機能が働くため、先頭文字を少し入力すると絞込んで表示してくれます。

以下のように設定します。なお、名前（このマッピングの名前）は必須ではありません。デバッグ用途で使われます。**ソース** はプロビジョニング元であるmidPointのユーザー属性を指定します。**To resource attribute** にはターゲット側（プロビジョニング先）である連携先システム（CSVファイル）のカラム名を指定します。

- **ソース**：`name`
- **式**：`現状`
- **To resource attribute**：`userId`


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/07bb76b1-f6e4-9d1b-a7ed-d770987c1552.png)

続けて「アウトバウンドの追加」ボタンをクリックし、編集行を追加して他の属性のマッピングも設定します。これをプロビジョニングしたい属性の数分繰り返します。マッピング内容は下表を参考に設定します。

| ソース              | 式       | ターゲット       |
|:--------------------|:---------|:----------------|
| name               | 現状     | userId         |
| familyName         | 現状     | familyName     |
| givenName          | 現状     | givenName      |
| emailAddress       | 現状     | email          |
| telephoneNumber    | 現状     | tel            |
| organization       | 現状     | orgId          |
| organization       | スクリプト | orgName        |


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/0fd94d20-2299-1a06-4b64-5e20e2f2699c.png)

`orgName`へのマッピングでは、`スクリプト`を選択している点に注意してください。今回、`orgName`にはmidPointで管理している組織オブジェクトの表示名（`displayName`属性）をマッピングします。しかしながら、ユーザーの`organization`属性には、組織IDが入っています。この組織IDから組織オブジェクトの表示名を解決する必要があります。

そこで、**「式」** で`スクリプト`を設定しつつ、Groovyコードを記述して解決するように設定します。すぐ横の「スクリプトを表示」ボタンをクリックすると、「スクリプトの値」設定のダイアログがポップアップしますので、コードに`midpoint.getOrgByName(organization.orig)?.displayName.orig`を設定します。「実行」ボタンをクリックしてダイアログを閉じます。

:::note info
midPointでは、Groovyスクリプト内で利用可能なビルトインの関数ライブラリが提供されています。以下のドキュメントに記載されています。

https://docs.evolveum.com/midpoint/reference/support-4.8/expressions/expressions/script/functions/

そのうちの一つが`midpoint`変数で利用可能な「MidPoint Library」です。今回利用している`midpoint.getOrgByName(String name)`は、組織名（`name`属性）の値を引数で渡すと組織オブジェクトを検索して返してくれます。「ソース」で設定したmidPoint側の属性である`organization`は、その変数名で参照できるため、これを引数に渡せばよいです。ただし、注意点として`organization`属性の型はPolyStringとなっており、そのまま`getOrgByName`関数に渡すことができません。PolyStringは、`orig`プロパティでオリジナルの値を参照可能ですので、`organization.orig`とします。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/8c7ad3d3-42bc-ac81-7445-67e7f2aea90c.png)

スクリプトを設定すると、以下のように「Evaluator value is set」と値が設定されている状態に変わります。これで「マッピングを保存」ボタンをクリックして保存します。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/b3cbbab3-d786-9e71-76bb-a69fc7caf141.png)

### 同期の設定

プロビジョニング目的の場合、同期の設定は実はなくてもプロビジョニング自体は可能です。ただし、このリソースに対するリコンシリエーションタスクを使用して名寄せにより紐づけ（リンク）させたり、同期や不整合の解消を行う場合は必要なので、ここではその設定を追加しておきます。

| 状況       | アクション           | 設定意図                                                                 |
|:-----------|:--------------------|:-------------------------------------------------------------------------|
| Linked     | 同期                 | 既にLinked状態のユーザーに対して、リコンシリエーションタスクの実行時に差分があれば反映する[^1]           |
| Unlinked  | 紐づけ    | 名寄せ処理にて、プロビジョニング先システムのデータと一致するmidPoint側のデータを発見した場合に、紐づけを行う                         |
| Unmatched  | リソース・オブジェクトの削除 | リコンシリエーションタスク実行時にCSV側にだけ存在するユーザを発見した場合は、CSVから削除する                         |
| Deleted    | 同期                    | リコンシリエーションタスク実行時にプロビジョニング先システム側でユーザーが削除されたことを検知した場合は、再び連携先にユーザーをプロビジョニングする   |


[^1]:例えば、連携先システム側で値の変更が行われた場合に、リコンシリエーションタスクの実行でmidPointのデータ内容で正すことができるようになります。なお、アウトバウンドマッピングの項目単位の詳細設定で、**強さ（strength）** に`strong`を設定しておく必要があります。GUIからマッピングを設定した場合はデフォルトで`strong`が設定されています。

:::note info
状況が**Unmatched**のときに`リソース・オブジェクトの削除`を実行することで、連携先システム側でmidPointと関係なく追加されたデータを自動的にお掃除することができます。一方、運用上削除されると困るケースも想定されます。その場合はUnmatchedのルールは定義しないようにします。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/8a562652-6c1f-742c-0438-1dc165dedcb6.png)



### Correlationの設定

**名寄せ** の設定です。先程の同期の設定で、状況が「Unlinked」の際にアクションを「紐づけ」と設定しました。この紐づけを正しく動作させるには、Correlationの設定を行い、どういったロジックで名寄せを行うのか設定する必要があります。また、後述するプロビジョニング時に名寄せを行うケースに対応するためにも、Correlationの設定が必要となります。

#### 名寄せ用のインバウンドマッピングの追加

先程マッピングの設定にて、アウトバウンドマッピングのみを設定しました。しかし名寄せではインバウンドマッピングの情報を利用するため、名寄せ用のインバウンドマッピングを追加します。再度マッピングの設定画面を開き、以下の内容でインバウンドマッピングを追加します。

- **ソース**：`name`
- **式**：`現状`
- **To resource attribute**：`userId`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/4f800714-9921-8d55-a1dd-4eaf98e54226.png)

さらに、![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/06d86032-de78-60e7-5e41-db78074b2912.png)をクリックしてこのインバウンドマッピングの詳細設定画面を表示します。ここで、**Use for** に`相関`を設定します。これにより、このインバウンドマッピングは名寄せ用途のみで使われます。同期には使用されません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/032217c4-a1cd-2810-9d0d-bc14ebf288af.png)

「ウィザードを終了」ボタンをクリックしてマッピング画面に戻ります。そして「マッピングを保存」ボタンをクリックして保存します。

#### Correlationの設定

Correlationの設定画面を開き、ルールを追加ます。「ルールの追加」ボタンをクリックし、**ルール名**に区別が付くようにルール名（例：`userId`）を入力し、![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/06d86032-de78-60e7-5e41-db78074b2912.png)をクリックして詳細設定画面を開きます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/3468a417-6d0c-2cf2-94c8-d813c40289a7.png)

「Add correlator」ボタンをクリックし、「アイテム」に先ほど追加した名寄せ用のインバウンドマッピングのアイテムである`name`を選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/22066add-c290-6ede-a2e6-14deb0b11a2f.png)

「設定を確認」ボタンをクリックしてCorrelationの設定画面に戻り、「Correlation設定を保存」ボタンをクリックして保存します。


# プロビジョニングの確認

リソースの設定が完了したので、いよいよプロビジョニングさせてみます。いくつかやり方がありますが、簡易的な確認方法として、リソースを直接アサインしてプロビジョニングする方法を今回は紹介します。

## リソースアサイン追加によるプロビジョニング

プロビジョニングを行うユーザーの詳細画面を開き、「アサイン ＞ リソース」メニューを開きます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/cc250168-d4a2-a023-bbc8-87c6d6cf63f3.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/3cfe8ec3-75c4-da15-3767-137d581251d8.png)アイコンをクリックして、「オブジェクトの選択」ダイアログを表示します。「Addressbook Users」リソースにチェックを入れて、「種類」では`アカウント`、「用途」では`default`を選択して、「追加」ボタンをクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/03b17b60-9775-1056-35c2-a4c9c1f2d26b.png)

アサイン追加予定のリソースが追加されます（緑色の箇所）。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/c8ecf5a6-1c89-60e8-d299-11ce29a611dc.png)

この状態で、「変更のプレビュー」をクリックしてみましょう。リソースの設定が正しければ、CSVへのプロビジョニング処理のプレビューが見れるはずです。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/c563f726-6dbe-d0f2-d977-ef287635e502.png)

右上の「高度」の箇所をクリックすると、「Addressbook Users」リソースに対する変更内容の詳細を展開できます。CSVに追加されるデータ内容を確認し、想定通りの値になっていることを確認します。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/af384871-5b2f-ce1e-9971-7fab5081fe94.png)

「保存」をクリックしてエラーが発生しなければ、CSVファイルにデータが書き込まれているはずです。CSVファイルの内容を確認しておきます。


```csvs:./addressbook/users.csv
userId,familyName,givenName,email,tel,orgId,orgName
1001,山田,太郎,taro.yamada@example.com,,005,営業第一部
```


また、ユーザーの詳細画面よりプロジェクションの状態も確認しておきます。「Addressbook Users」のプロジェクションが追加されていることが分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/2c31f8cc-ce7a-9c1a-eed0-2ea177b1c421.png)

プロジェクションの詳細を開くと、連携したCSVレコードの内容を確認することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/c2444e98-d2a0-5a7b-0290-33ce1b58ea4d.png)

## ユーザーデータ更新時のリアルタイププロビジョニング

出力されたCSVには、電話番号が含まれていません。これは今回のサンプルでは、電話番号は源泉システムから提供されておらず、midPointのユーザーオブジェクトでは空のままのためです。それでは、画面からこのユーザーの電話番号を設定した場合の挙動を確認してみましょう。

ユーザーの詳細画面を開き、「空項目を表示する」をクリックします。そうすると、現在は空が設定されているその他の属性が表示されます。「電話番号」に`090-0123-4567`と入力し、「変更のプレビュー」をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/b4a2ac55-a48d-5a3f-1ddd-88481d0ac169.png)

変更内容の詳細を展開すると、ユーザーに対する電話番号の追加に伴い、リアルタイムに「Addressbook Users」リソースに対しても電話番号を設定しようとしていることが分かります。「保存」ボタンをクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/675d6dc3-6b68-d86b-a406-6fc782ae52ca.png)

CSVファイルを確認すると、電話番号が設定されていることが分かります。

```csvs:./addressbook/users.csv
userId,familyName,givenName,email,tel,orgId,orgName
1001,山田,太郎,taro.yamada@example.com,090-0123-4567,005,営業第一部
```

:::note info
midPointの基本思想として、midPointのオブジェクトと連携先がリンク状態にある場合、何らかの変更がmidPointのオブジェクトに対して行われると、アウトバウンドマッピングが評価されリアルタイムにプロビジョニングが行われます。この事は、[The Bookの「Synchronization and Provisioning」](https://docs.evolveum.com/book/practical-identity-management-with-midpoint.html#_synchronization_and_provisioning)でmidPointの特徴として語られており、他のIDMプロダクトのように追加のプロビジョニング用タスクを必要としない点をアピールされています。
:::



## リソースアサイン解除によるデプロビジョニング

プロビジョニングだけでなく、CSVからのユーザーの削除（デプロビジョニング）の動作も確認しておきます。

ユーザーの詳細画面を開き、「アサイン ＞ リソース」メニューを開きます。登録されている「Addressbook Users」リソースの行の![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/4041fad0-2160-91d0-4476-50f472d3aa45.png)をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/ab365bb2-17e0-98c4-4db7-3b4d82016a69.png)

すると、削除予定を示す色に変わります（まだ保存されていません）。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/588d4460-84b8-2d26-2321-eaac2cec9c95.png)

追加時と同様に、まずは「変更のプレビュー」をクリックして変更内容を確認してみましょう。リソースアサインの解除に伴い、「Addressbook Users」リソース上の「アカウント 1001」が削除予定である旨を確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/476b4a35-fb90-5c1c-863e-c427bca56dce.png)

「保存」をクリックすると、アサインが解除されCSVからもデータが削除されます。

```csvs:./addressbook/users.csv
userId,familyName,givenName,email,tel,orgId,orgName
```

## プロビジョニング時の名寄せ

リコンシリエーションタスクの実行時ではなく、プロビジョニング時にも名寄せが行われるケースがあります。midPointは設定したアウトバウンドに従って連携先へのプロビジョニングデータを用意して、作成を試みます。ここで成功すれば名寄せは必要ありません。しかし、すでに同名のデータが存在することを示すエラーがリソース（コネクター）側から返された場合[^2]に、midPointは[Discoveryというタイプの同期処理](https://docs.evolveum.com/midpoint/reference/support-4.8/synchronization/flavors/)を開始します。このDiscovery処理では、Correlation設定に従って名寄せ処理を行います。このそして名寄せでmidPoint内に該当のデータが1件見つかった場合は自動的にリンクを作成[^3]し、今度は更新処理を行います。

[^2]:より詳細に言うと、コネクターから`org.identityconnectors.framework.common.exceptions.AlreadyExistsException`という例外がスローされた場合です。

[^3]:このリンクの作成は、同期の設定を行わなくても実施されます。同期の設定はタスクの実行時に利用されます。

実際にこの動きも確認してみましょう。今、ユーザー`1001`にはリソースがアサインされていない状態であり、AddressbookのCSV側にも存在しません。CSVファイルを開き、以下のように`1001`のデータを追加しておきます。この時、更新を確認できるようにmidPoint側で持っているのと別の属性（例：メールアドレスを`yamada@example.org`）にしておきます。

```csvs:./addressbook/users.csv
userId,familyName,givenName,email,tel,orgId,orgName
1001,山田,太郎,yamada@example.org,111,005,営業第一部
```

これでmidPoint側のユーザー`1001`に対して、再度「Addressbook Users」リソースをアサインします。すると処理は正常終了し、CSVが更新されたことを確認できます。もし名寄せの設定を行ってない場合は、コンフリクトのエラーが発生し、CSVは更新されません。

```csvs:./addressbook/users.csv
userId,familyName,givenName,email,tel,orgId,orgName
1001,山田,太郎,taro.yamada@example.com,111,005,営業第一部
```

監査ログを確認すると、リソースのアサイン追加に伴いプロビジョニングを試みたがエラーとなり、その後名寄せを行いCSVの更新を行ったことが分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35233/9292d535-ea49-1e56-97c2-e04ffa60d471.png)


このようにCorrelationの設定を行っておくことで、プロビジョニング時に既に同名のデータが連携先にある状況でもうまくリカバリして更新を行うことができます。

:::note info
既に同名のデータが連携先に存在するケースとしては、既存システムをmidPointの連携先として新たに繋ぐ場合が多いかと思います。ここで紹介したDiscoveryの処理を検知して名寄せによりリンクを作成する方法もありますが、マイグレーション用に一度リソースを設定しつつ、リコンシリエーションタスクを実行して名寄せを行ってリンクを作成し、その後アウトバウンドマッピングによりmidPointを正にした同期を行うという、段階的なアプローチもあります。詳しくは、[1日目の記事](https://qiita.com/wadahiro/items/5a50efe246302ca4585b)で紹介した[The Bookの「Synchronization Example: LDAP Account Correlation」](https://docs.evolveum.com/book/practical-identity-management-with-midpoint.html#_synchronization_example_ldap_account_correlation)で解説されています。
:::


# まとめ

11日目では、midPointから外部システムへのプロビジョニング設定の追加について解説しました。midPointではプロビジョニングの場合も、源泉システムと同様にリソース設定を追加して実施する形になっていることをご理解頂けたかと思います。記事内ではユーザー情報のプロビジョニングを行いましたが、同様のリソース設定を追加することで、組織情報を別のCSVファイルにプロビジョニングすることも簡単にできます。是非試してみてください。

また、プロビジョニングの動作確認のために、今回はリソースのアサインという方法で解説しました。ただし、この方法は限定的な使い方であり、実際にはロールやアーキタイプ経由で間接的にリソースをアサインするように設計することが多いです。次回は、そのロール経由でアサインする方法（いわゆるロールベースプロビジョニング）を紹介したいと思います。お楽しみに！