midPointにおける「プロビジョニング」実践編（RDBへの連携）

はじめに

midPointアドベントカレンダー12日目は、midPointを使用したRDBへの連携(プロビジョニング)を試してみます。
アカウントのようなアイデンティティ情報の他システムへの連携、同期を自動化することは、midPointのようなIDMにおいて非常に重要な機能です。
今回はRDBを対象に、源泉データ(アカウント情報)の取得、アカウントの同期、更新、削除といった一連のプロセスが実現できることを確認します。
なお、11日目の記事「midPointにおける「フルフィルメント（プロビジョニング）」実践編（CSV/LDAPへの出力）」のまとめでご案内させていただいた通り、
ロールを元に自動でリソースをアサインする方式を使用します。
そもそもプロビジョニングとは？という場合には、10日目の記事「midPointにおける「フルフィルメント（プロビジョニング）」を解説する」をご確認ください。

RDBへのプロビジョニングの概要

midPointはアカウント情報の源泉に対し、更新チェックを行います。
返却された登録内容から、アカウントの作成/更新/削除を検知し、他DBに内容を反映(同期)します。

なお、今回はRDBへプロビジョニングを実施していますが、様々な媒体に対応するコネクタが用意されています。
コネクタについては、wikiを参照してください。

環境情報

実行環境は以下になります。

サーバ	説明	バージョン
midPoint	dockerで構築	4.0.1
MySQL(以下マスタ)	プロビジョニングの源泉(マスタ)とする	5.7.28
MySQL(以下連携システムX)	プロビジョニング対象とする(ただしロール：管理者/利用者のみ)	5.7.28
MySQL(以下連携システムY)	プロビジョニング対象とする(ただしロール：管理者のみ)	5.7.28

状態としては、2日目の記事「midPointのインストール」に源泉(マスタ)と連携先のRDBを追加した環境です。

本動作確認の方針

マスタに格納されている資格情報の種類によって、プロビジョニング先を切り替えてみます。

• 資格情報
  • 管理者
    • midPointにアカウント情報を取り込み、連携システムX、連携システムYへそれぞれプロビジョニングを実施します。
  • 利用者
    • midPointにアカウント情報を取り込み、連携システムXへのみプロビジョニングを実施します。
  • NULL
    • midPointにアカウント情報を取り込むのみとします。

マスタの資格情報	midPointで設定するロール	midPointへの同期	連携システムXへの同期	連携システムYへの同期
管理者	管理者(Manager)	○	○	○
利用者	利用者(User)	○	○	×
NULL	未設定	○	×	×

上記方針でマスタに対しレコードの新規登録/更新/削除を実施すると、それぞれ以下のようになります。

• マスタにレコードが新規追加された場合の例(資格情報：利用者)
  

• マスタのレコードが更新された場合の例(資格情報：管理者)
  

• マスタのレコードが削除された場合の例(資格情報：管理者)
  

構築

RDBへの接続を行うには、事前にmidPoint側にJDBCドライバをインストールしておく必要があります。
また、当然ながら各DB/テーブルを用意しておかなければならないため、作成します。
事前準備完了後、midPoint側の設定を実施していきます。

JDBCドライバのインストール

MySQL用のJDBCドライバをmidPointにインストールします。
MariaDBなどの一部RDBのドライバはバンドルされているようですが、MySQLはライセンス上の理由で対象外となっています。
midPointのホームディレクトリ配下にlibディレクトリを作成し、ダウンロードしたMySQLドライバ(jar)を格納します。

• 設定例 格納後、midPointの再起動が必要です。

マスタDB/テーブルの準備

MySQL(マスタ)にDB/テーブルを作成します。
レイアウトは自由ですが、midPoint上のタスクで変更を検知するために更新年月日を保持するカラムが必須です。
テーブル構成は以下にしています。

• マスタ(userテーブル)

カラム名	型	説明
userId	VARCHAR(30)	主キー
password	VARCHAR(64)	パスワード
firstName	VARCHAR(16)	名
lastname	VARCHAR(16)	姓
fullName	VARCHAR(32)	姓名
userType	VARCHAR(6)	資格情報(ロール)
updDate	TIMESTAMP	midPointの変更検知用

続けて、プロビジョニング対象のDB/テーブルを作成します。
テーブル構成は以下にしています。

• 連携システム(連携システムX、連携システムYで共通)

カラム名	型	説明
userId	VARCHAR(30)	主キー
firstName	VARCHAR(16)	名
lastname	VARCHAR(16)	姓
fullName	VARCHAR(32)	姓名
updDate	TIMESTAMP	更新年月日

上記3テーブルを作成します。

create_user_table.sql

CREATE TABLE user (
  userId varchar(30) NOT NULL,
  password varchar(64) DEFAULT NULL,
  firstName varchar(16) DEFAULT NULL,
  lastName varchar(16) DEFAULT NULL,
  fullName varchar(32) DEFAULT NULL,
  userType varchar(6) DEFAULT NULL,
  updDate  timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (userId)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

create_systemX_table.sql

CREATE TABLE systemX (
  userId    VARCHAR(30) NOT NULL,
  firstName VARCHAR(16),
  lastName  VARCHAR(16),
  fullName  VARCHAR(32),
  updDate    TIMESTAMP,
  PRIMARY KEY (userId)
) ENGINE=InnoDB DEFAULT CHARSET=UTF8

create_systemY_table.sql

CREATE TABLE systemY (
  userId    VARCHAR(30) NOT NULL,
  firstName VARCHAR(16),
  lastName  VARCHAR(16),
  fullName  VARCHAR(32),
  updDate    TIMESTAMP,
  PRIMARY KEY (userId)
) ENGINE=InnoDB DEFAULT CHARSET=UTF8

マスタに初期データを投入します。
実運用ではあまり見られない例ですが、わかりやすくするために資格情報には文字列を使用することにします。

userId	password	firstName	lastName	fullName	userType	updDate
[e-mail]	ハッシュ値	管理	ユーザー	管理ユーザー	管理者	NULL
[e-mail]	ハッシュ値	一般	ユーザー	一般ユーザー	利用者	NULL
[e-mail]	ハッシュ値	テスト	アカウント	テストアカウント	NULL	NULL

insert_mst_data.sql

INSERT INTO USER(userId,password,firstName,lastName,fullName,userType) VALUES ('[e-mail]','5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8','管理','ユーザー','管理ユーザー','管理者');
INSERT INTO USER(userId,password,firstName,lastName,fullName,userType) VALUES ('[e-mail]','5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8','一般','ユーザー','一般ユーザー','利用者');
INSERT INTO USER(userId,password,firstName,lastName,fullName,userType) VALUES ('[e-mail]','5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8','テスト','アカウント','テストアカウント',NULL);

midPointの設定

ここからは、midPoint側でRDBを操作するための設定、及びプロビジョニングのための設定を実施します。

ロールの作成

midPointでプロビジョニングを実施する手段はいくつかありますが、今回はロールベースプロビジョニングを実施するため、下図のような紐づけになるようにロールを作成します。
ロールベースプロビジョニングについては、6日目の記事「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」を解説する」で解説していますので、ご確認ください。

まず、midPointにadministratorユーザでログインし、画面左のメニューから「ロール」⇒「新規ロール」を選択し、ロールを作成します。

• 作成するロール

ロール名称	意味
Manager	管理者
User	利用者
SystemXUserRole	システムX利用
SystemXManageRole	システムX管理
SystemXMetaRole	システムX集約
SystemXConnectMetaRole	システムX接続
SystemYManageRole	システムY管理
SystemYMetaRole	システムY集約
SystemYConnectMetaRole	システムY接続

• 設定例

紐付け

Managerロール、Userロールに紐付けを作成します。
6日目の記事「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」を解説する」の通り、紐付けにはインデュースメントを使用します。
ロールを選択し、インデュースメントタブにて、紐づけしたいロールを追加して保存すればOKです。
7日目の記事「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」実践編」に詳しい手順と詳細が記載されていますので、併せてご確認ください。

• 設定内容

ロール名	インデュースメントするロール or リソース	備考
Manager	SystemXManageRole、SystemYManageRole
User	SystemXUserRole
SystemXManageRole	SystemXMetaRole
SystemYManageRole	SystemYMetaRole
SystemXUserRole	SystemXMetaRole
SystemXMetaRole	SystemXConnectMetaRole
SystemYMetaRole	SystemYConnectMetaRole
SystemXConnectMetaRole	リソース：SystemX	リソース作成後
SystemYConnectMetaRole	リソース：SystemY	リソース作成後

• 設定例

作成後、Manager、Userのoidを確認します。
それぞれのロールを一覧から選択し、RAWデータの編集ボタンからxmlを開き、定義されているoidを控えておきます。

オブジェクトテンプレートの作成/インポート

同期実行時に自動的にロールをアサインしたいため、オブジェクトテンプレートを作成します。
作成したテンプレートは、画面左のメニューから「オブジェクトのインポート」を選択し、以下内容のテンプレートを登録します。
オブジェクトテンプレートについては、7日目の記事「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」実践編」にて詳しく解説されていますので、ご確認ください。
定義内容としては、「midPointのフィールド：subTypeが管理者ならManagerロールをアサインし、利用者ならUserロールをアサインする」ということを定義しています。

<objectTemplate xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xmlns:icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3" xmlns:org="http://midpoint.evolveum.com/xml/ns/public/common/org-3" xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3" xmlns:ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3" xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3" oid="10000000-0000-0000-0000-000000123456">
    <name>Qiita Example User Template</name>
    <mapping>
        <strength>strong</strength>
        <source>
            <c:path>subtype</c:path>
        </source>
        <expression>
            <assignmentTargetSearch xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xsi:type="c:AssignmentTargetSearchExpressionEvaluatorType">
                <targetType>c:RoleType</targetType>
                <oid>ロール：ManagerのOID</oid>
            </assignmentTargetSearch>
        </expression>
        <target>
            <c:path>assignment</c:path>
        </target>
        <condition>
            <script xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xsi:type="c:ScriptExpressionEvaluatorType">
                <language>http://midpoint.evolveum.com/xml/ns/public/expression/language#Groovy</language>
                <code>subtype == '管理者'</code>
            </script>
        </condition>
    </mapping>
    <mapping>
        <strength>strong</strength>
        <source>
            <c:path>subtype</c:path>
        </source>
        <expression>
            <assignmentTargetSearch xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xsi:type="c:AssignmentTargetSearchExpressionEvaluatorType">
                <targetType>c:RoleType</targetType>
                <oid>ロール：UserのOID</oid>
            </assignmentTargetSearch>
        </expression>
        <target>
            <c:path>assignment</c:path>
        </target>
        <condition>
            <script xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xsi:type="c:ScriptExpressionEvaluatorType">
                <language>http://midpoint.evolveum.com/xml/ns/public/expression/language#Groovy</language>
                <code>subtype == '利用者'</code>
            </script>
        </condition>
    </mapping>
</objectTemplate>

• 設定例

オブジェクトテンプレートの反映

作成したオブジェクトテンプレートを同期実行時に反映されるように設定します。
7日目 「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」実践編」にて解説されている内容の通り、
画面左のメニューからシステム ⇒ オブジェクトポリシーから登録を実施しました。

• 設定例

リソース設定(マスタ)

画面左のメニューからリソース ⇒ 新規リソースを選択します。
ウィザードに沿って設定を実施することができます。

リソースの基本

リソース名とコネクターを設定します。
リソース名はmaster、コネクターはRDBへの接続のため、ConnId org.identityconnectors.databasetable.DatabaseTableConnector v1.4.3.0を選択しています。

設定

DBの接続先などを指定します。

設定項目が多いですが、重要な設定は以下です。
その他の設定は、必要に応じて設定が必要となります。

項目名	説明	補足
Host	RDBのホスト名	IPアドレス可
TCP Port	RDBのポート
User	RDBにアクセスするユーザ名
User Password	RDBにアクセスするパスワード
Database	マスタとするテーブルが存在するDB名
Table	マスタとするテーブル名
Key Column	このテーブルの主キー名	今回はuserId
Password Column	パスワード保持カラム名	今回はpassword
JDBC Driver	JDBC接続ドライバクラス名	MySQLなのでcom.mysql.cj.jdbc.Driver
JDBC Connection URL	JDBC接続URL	MySQLなのでjdbc:mysql://ホスト名～ ちなみに、ホストは%h、ポートは%p、データベースは%dでHost、TCP Port、Databaseの入力項目をそれぞれ参照可能です。

設定後、保存と接続テストボタンを押下して、エラーがなければ次に進みます。

スキーマ

設定に問題がなければ、マスタのカラムが表示されます。
特にここで設定すべきことはないため、確認が済み次第次に進みます。

スキーマ処理

ここでは、各カラム毎のマッピングの設定を行います。
(matserテーブルの各カラムとmidPoint内部DBの各カラムへのマッピング)
オブジェクトタイプの追加を押下し、設定画面を開いてください。

• 設定項目

項目名	説明	設定例
種類	操作するリソースオブジェクトの種類。	アカウント
用途	リソースオブジェクトの意図。今回は種類がアカウントなので、defaultならデフォルトアカウントの意。	default
オブジェクトクラス	midPointのコネクタに渡すオブジェクトクラス。	AccountObjectClass
属性	以下表参照

各項目の詳細はwikiのこのページを参照してください。
設定値の意味はこちらを。

• 属性

属性名	ターゲット
ri:firstName	$user/givenName
ri:lastName	$user/familyName
ri:fullName	$user/fullName
ri:userType	$user/subType
icfs:name	$user/name

属性はとても重要な設定で、対象テーブルのカラムをどのような形式でどこにマッピングするかを設定します。
アウトバウンドマッピングは、RDBからmidPointへのマッピング、
インバウンドマッピングは、上記の逆でmidPointからRDBへのマッピングです。

今回はマスタをmidPointから更新しないため、インバウンドマッピングのみ設定を実施します。
完了次第、次へ進みます。

※Userオブジェクトのフィールドはwikiを参照してください。
※riはリソースのフィールド、icfsはmidPointがプロビジョニングをするにあたって使用する値です。詳細はこれまたwikiを参照してください。

• 設定例

同期

ここでは、同期時のアクションを設定します。
これも重要な設定で、midPointがマスタの変更を検知した際の挙動の設定です。

• 同期オブジェクトの設定内容

項目名	説明	補足
名前	設定名	自由入力
種類	操作するリソースオブジェクトの種類	アカウント
用途	リソースオブジェクトの意図。今回は種類がアカウントなので、defaultならデフォルトアカウントの意。	default
オブジェクトクラス	midPointのコネクタに渡すオブジェクトクラス。	AccountObjectClass
相関	レコードを新規作成するか更新するかの条件設定	表下のフィルター句を登録
リアクション	同期状況毎の処理の定義	下記設定を登録

• 相関 ⇒ フィルター句の設定内容

<q:equal xmlns:org="http://midpoint.evolveum.com/xml/ns/public/common/org-3" xmlns="">
    <q:path >c:name</q:path>
    <expression xmlns="">
        <path>declare namespace ri='http://midpoint.evolveum.com/xml/ns/public/resource/instance-3'; $account/attributes/icfs:uid</path>
    </expression>
</q:equal>

• リアクションの設定内容

状況	同期	アクション
Linked	True	未定義
Unlinked	未定義	紐づけ
Deleted	未定義	フォーカスの削除
Unmatched	未定義	フォーカスの追加

アクションの意味はwikiを参照してください。

• 設定例

ここまで設定が完了したら、保存します。

リソース設定(プロビジョニング対象 連携システムX＆連携システムY)

次に、プロビジョニング対象である、連携システムX及び連携システムYのリソースの設定を実施します。
更新をかけるだけなので、マスタと比較して幾分か設定項目が少なくなります。

リソースの基本

マスタと設定内容が異なるのはリソース名のみです。

設定

マスタと設定項目はほぼ同一です。

• 設定例

設定後、保存と接続テストボタンを押下して、エラーがなければ次に進んでください。

スキーマ

マスタと同様、確認して次に進んでください。

スキーマ処理

マスタと同様重要な設定です。

項目名	設定例
種類	アカウント
用途	default
オブジェクトクラス	AccountObjectClass
属性	以下表参照

• 属性

属性名	ソース
icfs:name	$user/name
ri:firstName	$user/givenName
ri:lastName	$user/familyName
ri:fullName	$user/fullName

このリソースはmidPoint経由での更新のみ実施するため、アウトバウンドマッピングのみ設定を実施します。
インバウンドマッピングではターゲットに設定を行いましたが、アウトバウンドマッピングではソースに設定が必要です。
設定完了次第、次へ進みます。

• 設定例

同期設定は、各連携システムのリソースではデフォルトのままで問題ないため、設定を保存します。

同期タスクの作成

画面左のメニューから「サーバータスク」⇒「新しいタスク」を選択し、以下内容のタスクを登録します。
今回は、Live同期、リコンシリエーションの2種を作成します。
本来は両タスク共にポーリングさせることが望ましいですが、今回は手動実行とします。
同期種別の詳細はwikiを参照してください。

• Live同期

項目名	説明	設定内容
タスク名	タスクの名前	masterポーリング
タイプ	同期タイプの選択	Live同期
リソース参照	どのリソースをタスクの対象とするか	master
種類	処理するオブジェクトの種類	アカウント
用途	処理するオブジェクトの用途	default
オブジェクトクラス	処理するオブジェクトのクラス	AccountObjectClass

• 設定例
  

• リコンシリエーション

項目名	説明	設定内容
タスク名	タスクの名前	リコンシリエーション
タイプ	同期タイプの選択	リコンシリエーション
リソース参照	どのリソースをタスクの対象とするか	master
種類	処理するオブジェクトの種類	アカウント
用途	処理するオブジェクトの用途	default
オブジェクトクラス	処理するオブジェクトのクラス	AccountObjectClass

• 設定例

動作確認

それでは、実際に動かしてみます。
先ほど作成したLiveタスクを選択し、今すぐ実行ボタンを押下すると、タスクが実行されます。
設定に不備がなければ、画面右上に緑色のチェックマークと共に成功と表示されるはずです。

アカウントの作成

画面左のメニューから「ユーザー」⇒「すべてのユーザー」を選択し、
midPoint上にアカウントが作成されていることを確認します。

• 確認OK

次に、ロールが適切にアサインされているか確認します。

• 管理者(Managerロール)
  

• 利用者(Userロール)

• 

それぞれ意図した内容でロールがアサインされていることを確認できました。
続いて、連携システムX、連携システムYにレコードが作成されていること(プロビジョニングされていること)を確認します。

• 連携システムX(ロール：管理者、利用者のみ)
  

• 連携システムY(ロール：管理者のみ)
  

それぞれのテーブルにレコードが作成されていることを確認できました。

アカウントの更新

マスタの更新に追随して、各テーブルのレコードが更新されることを確認します。
レコードをこんな感じに更新してみます。

次に、midPointに更新を検知してもらうためタスクを実行します。
今度はリコンシリエーションを実行します。
こちらも設定に不備がなければ、画面右上に緑色のチェックマークと共に成功と表示されるはずです。

midPoint、各連携システムのレコードが更新されていることを確認します。

• midPoint
  

• 連携システムX
  

• 連携システムY
  

それぞれ更新されています。

アカウントの削除

アカウントの削除を確認します。

マスタのレコードをすべて削除してみます。

再びタスク(リコンシリエーション)を実行します。

midPoint、各連携システムのレコードが削除されていることを確認します。

• midPoint
  

• 連携システムX
  

• 連携システムY
  

それぞれ削除されています。

最後に

RDBに対してアカウント登録～更新～削除の一連のプロセスを確認しました。
midPointは本当はもっと柔軟なシステムで、例えばプロビジョニングする値を加工したり、
もっと細かな条件分岐に対応したりなど、連携するシステムの実態に沿った形でID連携することも可能です。

参考資料

• wiki

• OpenStandiaのmidPoint最新情報

• 設定サンプル

• 6日目「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」を解説する」

• 7日目「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」実践編」

• 10日目「midPointにおける「フルフィルメント（プロビジョニング）」を解説する」