#はじめに
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)を格納します。
##マスタ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 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 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 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 |
---|---|---|---|---|---|---|
manage@example.com |
ハッシュ値 | 管理 | ユーザー | 管理ユーザー | 管理者 | NULL |
user@example.com |
ハッシュ値 | 一般 | ユーザー | 一般ユーザー | 利用者 | NULL |
test@example.com |
ハッシュ値 | テスト | アカウント | テストアカウント | NULL | NULL |
INSERT INTO USER(userId,password,firstName,lastName,fullName,userType) VALUES ('manage@example.com','5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8','管理','ユーザー','管理ユーザー','管理者');
INSERT INTO USER(userId,password,firstName,lastName,fullName,userType) VALUES ('user@example.com','5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8','一般','ユーザー','一般ユーザー','利用者');
INSERT INTO USER(userId,password,firstName,lastName,fullName,userType) VALUES ('test@example.com','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上にアカウントが作成されていることを確認します。
次に、ロールが適切にアサインされているか確認します。
それぞれ意図した内容でロールがアサインされていることを確認できました。
続いて、連携システムX、連携システムYにレコードが作成されていること(プロビジョニングされていること)を確認します。
それぞれのテーブルにレコードが作成されていることを確認できました。
##アカウントの更新
マスタの更新に追随して、各テーブルのレコードが更新されることを確認します。
レコードをこんな感じに更新してみます。
次に、midPointに更新を検知してもらうためタスクを実行します。
今度はリコンシリエーションを実行します。
こちらも設定に不備がなければ、画面右上に緑色のチェックマークと共に成功
と表示されるはずです。
midPoint、各連携システムのレコードが更新されていることを確認します。
それぞれ更新されています。
##アカウントの削除
アカウントの削除を確認します。
midPoint、各連携システムのレコードが削除されていることを確認します。
それぞれ削除されています。
#最後に
RDBに対してアカウント登録~更新~削除の一連のプロセスを確認しました。
midPointは本当はもっと柔軟なシステムで、例えばプロビジョニングする値を加工したり、
もっと細かな条件分岐に対応したりなど、連携するシステムの実態に沿った形でID連携することも可能です。
#参考資料
Comments
Let's comment your feelings that are more than good