[MIM]同期方法（ポリシーベース、Scope Filterベース）を比較する

こんにちは、富士榮です。

Microsoft Identity Manager 2016（MIM）を使って外部システムへIDをプロビジョニングするためには2つの方法があります。（コードベースを合わせると正確には3つですが、ここでは開発を伴う方法は除外して考えます）


◆２つの同期方式
①ポリシーベースのプロビジョニング
一つ目は、Forefront Identity Manager 2010から実装された管理ポリシールール（Management Policy Rule / MPR）、セット（SET）、アクションワークフロー（Action Workflow / WF）、送信同期規則（Outbound Synchronization Rule / OSR）を組み合わせて行う方法です。

ざっくり説明すると、
・一定の条件に当てはまるリソース（ユーザなど）を
・同期規則に割り当てる
ことによって外部システムへプロビジョニングを行います。

この条件をSET、外部システムとの同期するためのルール（属性マッピングなど）をOSR、同期規則へ割り当てるアクションの定義をWF、全体をまとめてMPR、と呼びます。

内部的には、以下の処理が行われます。

1. 人事などからリソースがFIM（CS）へインポートされる
2. Metaverseへ同期されるタイミングでISRによりFIM ServiceのCSへ同期される
3. FIM ServiceへExportされる
4. リソースがSETの条件に当てはまるかどうか評価される
5. FIM Service上でリソース毎にExpected Rules Entry（ERE）が生成され、リソースに参照型の属性としてEREが割り当てられる
6. FIM Service上のリソースとEREがImportされ、Metaverseに同期される
7. EREによりMetaverse上のリソースとOSRが紐づけられて外部システム用のConnector Spaceへ同期される
8. 外部システム用のMAでExportを行うことで外部システム上にプロビジョニングされる

キモはリソースがMetaverseに同期されたタイミングでリソースのERE属性が参照しているEREを見て適用するOSRを設定する、という部分です。（処理７の部分）


②Scope Filterベース
こちらはForefront Identity Manager 2010 R2から実装された少しシンプルな同期方法です。

OSRを適用するための条件（Scope Filter）を定義しておくことにより、Metaverseにリソースが同期された段階で条件にマッチすると即OSRが適用され、対象の外部システム向けのCSへリソースが同期されます。
ポリシーベースの同期ではEREオブジェクトがリソースとOSRの間を取り持っていたのに対して、とりあえずMetaverse上のすべてのリソースに対してScope Filterへの適合を確認する、という点で非常にシンプルです。

◆同期方式の機能面での比較
最大の違いは、デプロビジョニング（外部システムからリソースを削除する）ができるか、できないか、です。
ポリシーベースではSET条件に当てはまらなくなった場合に何を行うか？についても定義ができるので、デプロビジョニングするためのWFを作成し、MPRを定義しておけば外部システムからリソースを削除する、などの細かい制御を行うことが可能です。

ざっくりまとめると以下のような比較になります。

比較項目	ポリシーベース	Scope Filterベース
プロビジョニング条件判断	MPR、SET、WFの組み合わせにより適用するOSRを決定する	OSR自体に設定された条件（Scope Filter）に合致するすべてのMetaverse上のリソースにOSRを適用する
複雑な条件の設定	可能 （SETの条件はかなり柔軟、かつ手動でメンバ追加を行うことも可能）	不可能 （基本はリソースの属性の値による判断で、複数の条件を設定する場合はすべてAND条件となる）
FIM Service上へのリソースの同期の要否	必要	不要
生成されるオブジェクトの数	多い（EREオブジェクトが必要）	少ない
デプロビジョニング	可能 （デプロビジョニング用のMPRとWFを定義することで外部システムからリソースを削除できる）	不可能 （Scope Filterに合致しなくなったリソースに関しては同期されなくなるだけで外部システムからリソースは消えない）
管理面	FIM Portal上のユーザに対して適用する予定のルール（ERE）と実際に適用されたルール（DRE）が割り当てられるので、トラブルシュートが楽	FIM Portal上で対象ユーザにどの同期規則が適用されているのかの判断がしづらい（FIM Serviceへユーザを同期しないことも可能になってしまうため。FIM Serviceへ同期されたユーザについてはDREを設定することで状態確認は可能）

◆同期方式を性能面で比較
これは圧倒的に差があります。
ポリシーベースだと一旦FIM Serviceにリソースが入ってからでないとリソース割り当ての判断ができないため、処理的にはかなりのオーバーヘッドとなります。また、リソースとは別にERE自体がオブジェクトとして生成され、Metaverse上へ同期されるため、オブジェクト数が外部システムの数分増えていくため、データベースの性能を圧迫します。

一方でScope FilterベースだとリソースがMetaverse上に同期された段階でScope Filterが評価され、適用されるOSRの判断が行われるので無駄がありません。

実際の性能測定をすると以下のような結果となります。
ADにユーザがプロビジョニングされて使えるようになるまで、という条件ですが10,000ユーザで1時間以上の差がついています。

属性条件
・Macbook Air上のVMware Workstationで計測
・ホストスペック
　OS : Windows 10 Pro x64
　CPU : Core i7-4650U 2.3GHz
　メモリ : 8GB
　ディスク : SSD
　VM : VMware Workstation 10
・ゲストスペック
　OS : Windows Server 2012 R2
　CPU : 1vCPU(2core)
　メモリ : 4GB
・ミドルウェア（すべて１台に同居）
　SQL Server 2014 Standard SP1
　SharePoint Foundation 2013 SP1
　Active Directory Domain Service
　Microsoft Identity Manager 2016
　- Synchronization Service
　- MIM Service
　- MIM Portal
・同期条件
　入力（HR相当）：CSVファイル
　出力：ADDS
　ユーザ件数：10,000
　同期属性：
　- Account Name
　- Display Name
　- First Name
　- Last Name
　- Department
　同期条件：Department属性値がEIDENTITYとなっていること


◆どちらの方式を使うべきなのか
ケースバイケースなので、なんとも言えませんが例えばActive Directoryなど、ほぼ全員がプロビジョニングされてデプロビジョニングすることがない（無効化はするが実削除はしない）ようなケースであればScope Filterベースがあっていると思います。
今回のテスト環境は非常にプアな環境だったこともあり、データベースでロックが発生してしまい10,000ユーザをポリシーベースで同期しようとしただけでエラーが発生してしまったりしていることもあり、まずはScope Filterベースで設計できないかどうかを検討した上で、どうしても問題がある場合に限ってポリシーベースを使うというのが良いのかもしれません。