はじめに
midPointアドベントカレンダー9日目は昨日の記事で紹介された「アクセス要求」「ワークフロー」について、実際のmidPointでの設定方法をご紹介します。
紹介する設定は、ユーザが必要なロールを自ら要求しアサインできるようにする設定や、ロールに対して承認者を設定しておき、ロールの要求後、その承認者による承認操作をもって要求したユーザにロールをアサインできるようにするといった内容になります。
また、ロールを管理する機能についても紹介します。
「アクセス要求」や「ワークフロー」の詳細については昨日の記事をご参照ください。
また、昨日の記事中でも触れられていますが、midPointではユーザの要求ベースのロールアサインの他に、予め定めておいたポリシー(アサインルール)に基づいて自動でロールを割当てる機能もあります。この機能については本アドベントカレンダーの6日目、7日目のmidPointにおける「エンタイトルメント管理」「ポリシーとロール管理」の記事をご参照ください。
今回、midPointはmidPointの公式Docker Hubリポジトリで公開されているバージョン4.0.1の evolveum/midpoint:4.0.1 を使用しています。
アクセス要求とワークフローの基本設定
アクセス要求設定
昨日の記事でも触れられていますが、midPointではアサイン要求はロールの要求という名前の機能で実現されています。
まずは単純に、ユーザがロールを要求し、その要求をもってそのユーザにロールをアサインできるようにする設定を説明します。
設定
はじめに、ロール要求を行うための、midPointへのアクセス権限をもつユーザを作成します。
End userロールは、midPointにデフォルトで用意されているmidPointの一般ユーザロールです。このロールをアサインすることで、midPointへのログインが可能となります。
次に、ユーザに要求を許可するロールを作成します。
要求可能をtrueとすることで、ユーザからの要求ができるロールとなります。
要求可能なロールの準備はこれで完了です。
動作確認
先程作成したtestユーザで、実際にロール要求をして動作確認をしてみます。現時点ではtestユーザにアサインされているロールはEnd userのみです。
ロール要求はロールの要求から行います。
先程作成したProjectA userロールが表示されていますので、選択しロールを要求します。ロール要求はECサイトでの買い物を模しており、選択したロールはショッピングカートに入り、ショッピングカートから要求を確定するというUIになっています。なお、ショッピングカートへ行くボタンだけではなくショッピングカートアイコンからでも新規アサインの一覧(ショッピングカートの中身)に遷移できます。
ロール要求が完了すると、割当はすぐに使用できます。となっているように、そのままtestユーザにProjectA userロールがアサインされます。これは、現時点では承認が必要な設定をしていないためです。
ユーザプロファイルのアサイン画面でアサインされていることが確認できます。
ワークフローの設定
承認が不要なロールであれば上記のアクセス要求設定の手順で設定できますが、承認者による承認を必要とするようにしたい場合も多いかと思います。ここでは、そのような承認が必要な要求可能ロールを作成する手順を説明します。
設定
設定方法を説明していきます。まず、承認者となるユーザを作成しておきます。
承認者には、End userロールに加え、Approver(承認者)ロールをアサインしておきます。Approverロールをアサインすることで下記のキャプチャのように、End userロールだけの場合と違い、左部にケースというメニューが表示されるようになります。
承認者ユーザの用意ができたので、ロールを作成します。ロールは前述のアクセス要求設定と同じように作成します。
次に、作成したロールの承認者を設定します。承認者に設定したいユーザに承認者としてロールをアサインすることで、ロールの承認者として設定することができます。
これで設定は完了です。
動作確認
アクセス要求設定の動作確認と同じように動作を確認していきます。アクセス要求設定で作成したtestユーザで先ほど作成したProjectB userロールを要求してみます。
今度はアクセス要求設定の際とは違い、要求しただけではロールがアサインされず、進行中といったメッセージが表示されました。
承認者に設定したtestapproverユーザでログインしてみます。
midPointでは承認タスクは作業アイテムと言う名前で扱われます。トップページにて、承認依頼として作業アイテムが来ていることやメニューのケースにバッチがついていることが確認できます。作業アイテムの名前を選択すると、詳細が確認できます。なお、ケースからでも作業アイテム画面に行くことができます。
先ほどtestユーザで要求したロールの承認依頼であることが確認できますので、承認します。
再度testユーザでログインすると、ProjectB userがアサインされていることが確認できます。
アクセス要求対象のロールの管理
ここまでで、アクセス要求(ロールの要求)とワークフローの基本的な設定をご紹介しました。
しかし、ここまでの設定内容だけでは、ロールが横並びとなってしまい、ロール数が増えると管理が難しくなります。また、ロール要求をするユーザも要求したいロールをロールの要求画面から探すのが大変です。
ここでは、要求可能なロールを管理するための機能を少し説明します。
ロールカタログ設定
1つ目はロールカタログです。ロールカタログは、ロールを階層管理する機能です。
midPointでは、組織構造として、組織を階層管理する機能があります。ロールの管理においては、その組織にロールを割り当てることでロールの階層管理が実現できます。これをロールカタログと呼んでいます。
設定
ロールカタログの設定方法を見ていきます。まず、ロールカタログとする組織を作成します。
子組織としてアクセス要求設定とワークフロー設定で作成したロール用の組織を作ります。
同様の手順でProjectB user用の組織も作成しました。
作成したProjectAにProjectA userロールを割り当てます。
メンバー内のタイプをロールまたはすべてにすることで、割り当てたロールが確認できます。
同様にProjectBにProjectB userロールを割り当てました。
次に作成した組織をロールカタログに指定する設定です。ロール管理(システム > ロール管理)のロール・カタログへの参照を先ほど作成したロールカタログ組織にします。
これで、ロールカタログの設定は完了です。
動作確認
ロールカタログの確認をします。
ただし、midPointのデフォルトのEnd userロールでは組織(OrgTypeオブジェクト)の参照権限がないため、階層化されたロールカタログが参照できません。
そのため、End userロールに権限を付けておきます。End userロールの編集画面のRAWデータの編集を選択してください。XMLのroleタグ内に下記のOrgType参照権限設定を追加します。
<authorization>
<name>orgtype-read</name>
<action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#read</action>
<object>
<type>OrgType</type>
</object>
</authorization>
これで、権限設定は完了です。
アクセス要求設定で作成したtestユーザのロールの要求画面に行くと、設定したロールカタログが確認できます。
ロールの要求画面カスタマイズ
最後にロールの要求画面のカスタマイズ方法をご紹介します。
先程説明したロールカタログの表示もロールの要求画面のカスタマイズの一つですが、その他にロールの要求画面上部のすべてのロールの表示などが表示されているタブも表示内容が変えられます。
設定はシステムのRAWデータの編集から行います。XMLのroleタグ内のroleManagementタグ内で以下の設定を行います。ロールカタログ設定を行っている場合は、roleManagementタグはすでにあるかと思いますので、そこを編集してください。ない場合はroleManagementタグを追加してください。
<roleCatalogCollections>
<collection>
<collectionUri>http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#roleCatalog</collectionUri>
</collection>
<collection>
<collectionUri>http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#allRoles</collectionUri>
</collection>
</roleCatalogCollections>
<defaultCollection>
<collectionUri>http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#roleCatalog</collectionUri>
</defaultCollection>
この設定は、ロールの要求の上部のタブにロールカタログの表示とすべとのロールの表示を表示し、ロールの要求へのアクセス時に表示する画面はロールカタログの表示にするという設定内容になります。roleCatalogCollectionsタグが上部のタブに表示するボタン群の設定で、defaultCollectionがロールの要求へのアクセス時に表示する画面の設定です。
testユーザでロールの要求画面を確認すると以下のように想定どおりとなっていることが確認できます。
その他のタブを含むタブのcollectionUriの一覧は下記のとおりです。
| collectionUrl | タブ名 |
|---|---|
http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#roleCatalog |
ロールカタログの表示 |
http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#allRoles |
すべてのロールの表示 |
http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#allOrgs |
すべての組織の表示 |
http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#allServices |
すべてのサービスの表示 |
http://midpoint.evolveum.com/xml/ns/public/common/object-collections-3#userAssignments |
ユーザのアサイン |
参考: Role Request and Shopping Cart Configuration - midPoint - Evolveum Confluence
おわりに
今回は、アクセス要求とワークフローについて、midPointでの実際の設定方法をご説明しました。あわせて、要求可能とするロールを管理する機能にも触れました。
この他にも、midPointには、承認者に作業アイテムが振られた際に、メールなどで通知する機能等もあり、ID管理におけるアクセス要求やワークフローの基本的な機能は揃っているものと思います。
また、少し高度な設定(※)が必要になりますが、ロール管理という視点では、ロールカタログの組織の管理者を、そのロールカタログ内のロールの承認者にするといった設定も可能です。これにより、ロールの管理がより効率的に行なえます。
※ midPointの設定の管理ファイルであるXMLを編集する必要がありますが、設定内にGroovyやJavaScriptといったスクリプトを利用することができます。midPointはそれにより柔軟に動作をカスタマイズすることができます。
なお、ロールカタログ以外のロールの管理機能として、本アドベントカレンダーの6日目の「midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」を解説する」の「拡張されたロールベースアクセスコントロール（RBAC）」でも触れられているように、ロールをアサインする際に組織などのパラメータを付与する仕組みもあります。
ロールカタログでは管理すべきロールの数は、ロールカタログ設定中の図のように、組織(プロジェクト等)の数×権限ロール(一般ユーザ、管理者ユーザ等)の数から変わりません。しかし、上記の機能では組織(プロジェクト等)の数+権限ロール(一般ユーザ、管理者ユーザ等)ですむことになります。
参考
Approval - midPoint - Evolveum Confluence
Role Request and Shopping Cart - midPoint - Evolveum Confluence
Role Catalog - midPoint - Evolveum Confluence
Role Catalog Configuration - midPoint - Evolveum Confluence
Role Request and Shopping Cart Configuration - midPoint - Evolveum Confluence
Script Expression - midPoint - Evolveum Confluence