「IDガバナンス&管理」(IGA)についてOSS「midPoint」を利用したハンズオンで学ぶ連載。最終回は、「兼務」と人事異動時の「引き継ぎ期間」の対応についてです。また、最後にmidPointの今後のロードマップ、展望についても触れます。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
オープンソースソフトウェア(OSS)でありながら「IDガバナンス&管理」(Identity Governance and Administration:IGA)機能を備えた「midPoint」を使って、ハンズオン的にIGAについて学ぶ本連載『midPointで学ぶ「IDガバナンス&管理」(IGA)の基礎』。
連載第6回は付与した権限を定期的に棚卸しする「アクセス認定」を紹介しました。最終回となる今回は、より高度なユースケースの対応例として「兼務」と人事異動時の「引き継ぎ期間」の対応を紹介します。また、最後にmidPointの今後のロードマップ、展望についても触れます。
これまでの連載で紹介した構成では、従業員の所属組織は1つに固定されていました。しかし多くの企業には、主だって所属している組織(主務)だけでなく他の組織にも同時に所属する「兼務」があり、ID管理システムでもこの「兼務」に対応することがよく求められます。
また、日本企業の人事異動では、所属組織が変わったとしても一定期間は旧所属を継続させるケースがよく見られます。「業務の引き継ぎのために、引き継ぎ期間中は旧所属組織の権限を残しておきたい」といった目的があります。しかし、源泉となる人事システム上は発令日のタイミングで所属組織が完全に切り替わっていることがよくあります。
下図は、4月1日の発令日を迎えると「開発1課」所属の従業員が「運用2課」に異動となる場合の例です。もしその情報をそのままID管理システムで取り込むと、引き継ぎ期間には対応できません。
一口に「兼務」といっても、さまざまな細かい要件が考えられますが、今回は次の要件を前提とします。
また、人事システムから渡される従業員情報のCSVは下記の形式を想定します。
empno firstname lastname password orgnum title secorgnum 001 ありす 安藤 qwe123 1200 部長 1300 002 蛍 佐島 qwe123 1210 課長 003 加奈 工藤 qwe123 1210 係長 1310;1320 … … … … … …
これまでの連載で使用していたCSVに、兼務先の組織コード(Secondary Org Number)を表す列として「secorgnum」を追加しています。兼務が複数存在する場合はマルチバリューとなるので、「;」区切りで表現するとします。
人事異動による引き継ぎについては、「所属組織が切り替わるタイミングで14日間は旧所属組織に所属させる」とします。
midPointでは組織への所属をロールと同様に「アサイン」という形で表現しています。連載第3回のハンズオンを実施すると、従業員の詳細画面の「アサイン」メニューからアサイン一覧を参照できます。
アサインの数に特に制限はないので、兼務の場合は複数の組織にアサインすることで表現できます。他のID管理/IGAシステムでは、兼務を表現するためにユーザー属性で「兼務1、兼務2、兼務3、……」という属性を個別に持つケースもありますが、その場合、兼務数の上限が属性の数で固定されてしまいます。midPointでもカスタム属性を追加して同様の方式を採ることも可能ですが、アサインで表現すると、そのような制約はありません。
ただし、単純に兼務ごとにアサインを増やすだけでは、要件にある「所属する組織が主務なのか、兼務なのかは区別可能とする」に対応できません。加えて、単なるアサインでは、引き継ぎ期間終了時にアサインを無効化することも表現できません。これらの課題を解決するには、midPointの「アサインパラメーター※」という仕組みを利用します。
※midPointのドキュメントでは、英語で「Assignment Parameter」として解説されていますが、日本語では「アサインメント」のことを「アサイン」と省略して使うことが多いので、本記事では「アサインパラメーター」としています。
midPointでは、ユーザーやロール、組織といったオブジェクト間の関連は「アサイン」によって関係性を表現できます。このアサインごとに、関係性の種類を表す「リレーション」と幾つかの「パラメーター」を保持する仕組みが備わっています。この「パラメーター」をアサインパラメーターといいます。
「リレーション」については今回のシナリオにおいては関係ありませんが、少し補足します。リレーションには「メンバー」「管理者」「承認者」「オーナー」といった種類があり、どの役割で関係性を結ぶかを指定することできます。デフォルトは「メンバー」であり、このリレーションに応じて、ワークフローの承認者やmidPointのGUI操作の認可処理を制御したり、リレーションに応じてカスタムで処理したりすることができます。
「パラメーター」には、次のような属性が存在します(カスタム属性として任意の属性を追加することも可能です)。
アサインの際に上記のパラメーターを設定することでアサイン単位に追加のメタデータを保持できる仕組みです。midPointの管理画面からは、アサイン情報の詳細を開くとこれらの情報を参照、更新できます。
アサインパラメーターに主務と兼務を表す情報を格納することで、どのアサインが主務か、兼務かを区別できます。この情報を利用することで「ある連携先アプリケーションには主務の所属情報だけを渡す」といった制御が可能になります。
今回のサンプルでは、アサインパラメーターのサブタイプ属性を使い、下記のように表現するとします。なお、サブタイプ属性は他のアサインと区別するための情報を自由に入れるための領域です。自社のID管理業務要件に応じて自由に使えます。
下図は主務でアサインした場合の例です。サブタイプ属性に「primary」を設定しています。
サブタイプの設定は、人事システムのCSVを取り込む際にアサインするタイミングで自動的に行うようにします。アサイン自体は連載第3回で設定したリソース定義で行っていますが、アサインのマッピング定義内で、追加で設定することで、アサインパラメーターの値を指定できます。兼務については前述の通り、CSVの「secorgnum」列を利用するので、以下のマッピングルールを定義することで実現します。
具体的な設定例については、「midpoint-sample-configuration/resources/chapter-7/resource-csv-hr.xml at main - Hitachi/midpoint-sample-configuration - GitHub」を参照してください。
アサインパラメーターの「終了日時」を利用して、引き継ぎ期間の終了日を表現します。「終了日時」を設定しておくと、その日時を迎えたときにmidPointは該当のアサインを無効状態として自動的に扱います。また、システムタスク「Validity Scanner」が動作すると(デフォルトで、15分間隔で定期起動)、終了日時を迎えたアサインが付与されているオブジェクト(今回の場合だと、従業員を表すユーザー)を自動的に再計算します。再計算の結果、該当のアサインは無効状態として扱われた上で連携先システムに自動的に反映されることになります。
下図は、4月1日の発令日を迎えて「開発1課」所属の従業員が「運用2課」に異動となったが、引き継ぎ期間(4月15日まで)として旧組織のアサインを付与した状態です。「開発1課」のアクティベーション列が「有効, to 2023/04/15」となり、期限付きとなっていることが分かります。
このように引き継ぎ期間を表現するために、手動でアサインパラメーターを利用した旧組織へのアサインを設定することもできますが、IGAとしては自動化して統制をとるべきです。midPointにはさまざまなカスタム制御の汎用(はんよう)的な仕組みがあり、引き継ぎ期間対応の自動化についても幾つか実装方式が考えられます。
今回は、「Scripting Hooks」というmidPointの仕組みを利用した実装方式を紹介します。
midPointに対するオペレーション実行時にコードを注入したり、インターセプトしたりする仕組みとして、「Hook」があります。例えば、オペレーション完了後にカスタム通知を挿入したり、オペレーション要求が処理される前にその内容を変更したり、処理をワークフローシステムなどに転送したりといったカスタマイズが可能な汎用的な仕組みです。
Hookは通常、Javaのコードの一部であり、コンパイルしてmidPointに組み込む必要があります。しかし、Groovyのスクリプトを使用してHookを作成する軽量な方法もあります。midPointではこれを「Scripting Hooks」といいます。
次のようなScripting Hooksを実装することで、今回の要件に合わせた自動的な引き継ぎ期間への対応が可能です。
具体的な設定例については、「midpoint-sample-configuration/bulk-actions/chapter-7/system-configuration-patch.xml at main - Hitachi/midpoint-sample-configuration - GitHub」を参照してください。
ここからは、兼務と引き継ぎ期間のmidPointにおける操作についてハンズオンで解説します。
本手順は連載第3回、第4回で構築および設定した環境を前提としています。今回利用するファイルをリポジトリから取得して更新してください。
$ cd midpoint-sample-configuration $ git pull
今回利用するリソース定義は、 https://github.com/Hitachi/midpoint-sample-configuration/blob/main/resources/chapter-7/ に格納されています。連載第4回と同様の手順で、次のファイルをインポートしてください。
midpoint-sample-configuration/bulk-actions/chapter-7 at main - Hitachi/midpoint-sample-configuration - GitHub」にある「system-configuration-patch.xml」の内容をバルクアクションとして実行する必要があります。
※Scripting Hooksの設定はmidPointのグローバル設定であるSystem ConfigurationオブジェクトをXMLで編集する必要があります。サンプルではバルクアクションでScripting Hooks設定部分のみをパッチで適用するようにしています。
管理画面の「バルク・アクション」を選択して画面を開き、XMLの内容を貼り付け、「開始」ボタンをクリックして実行します。これで、System ConfigurationにScripting Hooksの設定が追加されます。
以上で、準備は完了です。
まず、兼務の情報を取り込んで動作を確認します。兼務を表す列を追加した人事情報は「data/midpoint/chapter-7/hr.csv」に格納しています。先ほどインポートしたリソース定義は、このファイルを読み込み対象としています。既に過去の連載の手順を実施し、従業員番号「001」のユーザーをmidPoint内にインポート済みの場合は、midPoint管理画面の「ユーザー」→「すべてのユーザー」画面に遷移し、各ユーザー行の右のメニューボタン(▼)でメニューを開き、リコンサイルをクリックしてください。もし、従業員番号「001」のユーザーがmidPointにまだ存在しない場合は、連載第3回の手順でユーザーをmidPointにインポートしてください。これで、以下の兼務情報を取り込んだ状態になっています。
従業員番号 | 氏名 | 所属(主務) | 所属(兼務) |
---|---|---|---|
001 | 安藤ありす | サービス開発部(1200) | サービス運用部(1300) |
従業員番号001(安藤ありす)の詳細画面から「アサイン」→「組織」をクリックして確認すると、アサインされている組織が2つになっていることを確認できます。
また、主務の「サービス開発部」をクリックすると、サブタイプが「primary」に設定されていることを確認できます。
同様に、兼務の「サービス運用部」をクリックすると、サブタイプが「secondary」に設定されていることを確認できます。
今回の兼務追加を、監査ログで確認します。midPoint管理画面の「レポート」→「監査ログビューアー」を選択し、ターゲット列が「001」の行を探します。
イベントステージ列が「実行」の行の日時をクリックして詳細画面を表示します。
赤枠で囲った箇所から、兼務として組織アサインが追加されていることが分かります。
「data/midpoint/chapter-7/hr.csv」を編集して取り込み、引き継ぎ期間の自動設定を試します。ここでは、開発1課に所属していたユーザーが運用1課に異動となるケースで動作を確認します。次の状態になるように「hr.csv」の「orgnum」列を編集してください。
旧所属 | 新所属 | ||
---|---|---|---|
従業員番号 | 氏名 | 所属 | 所属 |
004 | 伊達大吾 | 開発1課(1210) | 運用1課(1310) |
midPoint管理画面の「ユーザー」→「すべてのユーザー」画面に遷移し、従業員番号004(伊達大吾)の右のメニューボタン(▼)でメニューを開き、「リコンサイル」をクリックしてください。
従業員番号004(伊達大吾)の詳細画面から「アサイン」→「組織」をクリックして確認すると、人事情報の変更に従ってアサインされる組織が自動的に変更されていることを確認できます。また、旧所属の「開発1課」へのアサインが有効期限付きで存在することも確認できます。
続いて、詳細画面の「プロジェクション」をクリックしてプロビジョニング先の情報を確認します。
赤枠で囲った部分のように、開発ツールを表す「Developer Tools」リソースがまだ残っています。連載第4回で解説した通り、開発ツールは開発部の社員だけが利用可能としています。人事異動によって開発部から外れたこのユーザーは、「Developer Tools」リソースのアカウントを本来は持たないはずですが、まだ引き継ぎ期間中なので引き続き利用可能な状態です。
最後に、引き継ぎ期間終了後の動作をします確認。疑似的に確認するためにOSのシステム日付を進めてもよいですが、midPointには検証用の便利な時間設定機能があるので、そちらを利用して確認します。
midPoint管理画面の「内部設定」→「時刻設定」画面に遷移し、引き継ぎ期間終了後の日時を設定して「時間を変更」をクリックします。すると、midPoint内部で持つ日時情報が設定した値で固定化されます(元の状態に戻す場合は、「システム時刻を使用してリセット」をクリックします)。
再度、従業員番号004(伊達大吾)の詳細画面から「アサイン」→「組織」をクリックして確認すると、旧所属の「開発1課」が「無効」の表示に変わっています。
さらに、「サーバー・タスク」→「システム・タスク」をクリックしてシステムタスク一覧を表示し、「Validity Scanner」の右のメニューボタン(▼)でメニューを開き、「今すぐ実行」をクリックしてください(デフォルトで15分間隔で定期実行されるので、タイミングによっては既に自動実行済みの場合もあります)。
再度、従業員番号004(伊達大吾)の詳細画面からプロジェクションを確認すると、開発ツールを表す「Developer Tools」リソースが消えていることを確認できます。
引き継ぎ期間を終えて旧所属組織である「開発1課」のアサインが無効となったので、midPointによって自動的に開発ツールのアカウントが削除されています。
今回の引き継ぎ対応の各種処理を、監査ログで確認します。管理画面の「レポート」→「監査ログビューアー」を選択します。これまでの操作の監査ログが表示されます。
ここで、赤枠で囲った行に注目します。これは、編集したhr.csvの内容を取り込み、新所属に切り替わった際の更新ログです。内容を見るには日時をクリックします。
旧所属である開発1課への主務アサインの解除と、新所属である運用1課への主務アサインと同時に、引き継ぎのために終了日時を設定した開発1課へのアサインが追加されていることが分かります。
次に、Validity Scannerタスク実行後の再計算処理のログも確認します。Validity Scanner実行直後の、ターゲット列が「004」である行の日時をクリックして詳細を開きます。
※動作確認のためにmidPointの時刻を設定していますが、監査ログビューアーに記録される時刻はシステム日付のものと時刻設定のものが混在することがあるので注意してください。
旧所属である開発1課への主務アサインが無効となったので、開発ツールを表す「Developer Tools」リソースの削除が記録されていることを確認できます。
本連載では、LTS(Long-Term Support)バージョンの4.4系を使用しました。一方、現在の最新バージョンは4.7系が2023年4月にリリースされました。また、2023年の秋ごろには次のLTSとなる4.8がリリースされる予定です。これまでのリリース一覧は「MidPoint Releases - Evolveum Docs」から参照できます。
バージョン | リリース日 | サポート終了日 |
---|---|---|
4.4(LTS) | 2021年11月26日 | 2024年11月26日 |
4.5 | 2022年4月11日 | 2023年4月11日 |
4.6 | 2022年10月21日 | 2023年10月21日 |
4.7 | 2023年4月14日 | 2024年4月14日 |
4.8(LTS) | 2023年10月17日(予定) | 2026年10月17日(予定) |
4.4と4.8との間で追加された主な新機能(4.8については予定されている機能)は次の通りです。詳細は記載のリリースノートを参照してください。
バージョン | 主な新機能 | リリースノート |
---|---|---|
4.5 | ・IDマッチング ・メッセージテンプレート ・OpenID Connect対応 |
https://docs.evolveum.com/midpoint/release/4.5 |
4.6 | ・UIの変更 ・新しいリソース定義ウィザード ・新しいアクセス要求ウィザード |
https://docs.evolveum.com/midpoint/release/4.6 |
4.7 | ・シミュレーション機能 ・IGAレポート ・オブジェクトマーク ・パスワードリセットの改善 |
https://docs.evolveum.com/midpoint/release/4.7 |
4.8 | ・LTSに向けた安定化 ・効率的なアップグレード ・セキュリティの向上 ・パフォーマンスの向上 |
- |
midPointのロードマップは、「MidPoint Roadmap - Evolveum Docs」に記載されています。「IGA Capabilities Summary - Evolveum Docs」で「IGA Capabilities Summary」というドキュメントが公開されており、IGAの各機能に対してmidPointが現状どの程度充足しているか、また、将来のバージョンで強化したいかが記載されています。こちらを参照すると、現状のmidPointが弱い点は「Idenityty Analytics and Reporting」分野に集中していることが分かります。この領域の機能については、利用者のニーズに合わせて今後実装される可能性があります。
全7回にわたり、本連載にお付き合いいただきありがとうございました。midPointがID管理だけでなくIGAも実現できるOSSであることを紹介できたと思います。また、「専門性が高い」「ハードルが高い」といった従来のID管理に対する印象をお持ちの方が、本連載を読んで少しでも身近に感じていただければ幸いです。
Copyright © ITmedia, Inc. All Rights Reserved.