midPointで学ぶ、アクセス要求による権限付与の申請、承認とワークフロー：midPointで学ぶIDガバナンス＆管理（IGA）の基礎（5）

「IDガバナンス＆管理」（IGA）についてOSS「midPoint」を利用したハンズオンで学ぶ連載。今回は、アクセス要求による権限付与の申請、承認とワークフローについてです。

[上杉啓恵, 五戸禎人，野村総合研究所／クラウドネイティブ]

　オープンソースソフトウェア（OSS）でありながら「IDガバナンス＆管理」（Identity Governance and Administration：IGA）機能を備えた「midPoint」を使って、ハンズオン的にIGAについて学ぶ本連載『midPointで学ぶ「IDガバナンス＆管理」（IGA）の基礎』。

　前回の連載第4回では人事異動のユースケースを基にロールを使って自動的にプロビジョニングしました。今回は自動化が難しい権限付与のユースケースに対するワークフローを使ったアクセス要求を紹介します。

アクセス要求とは

　連載第4回では、人事システムなどの源泉情報から権限を自動で付与しました。しかし、権限付与が必要な場面は他にもあります。具体例としては次の通りです。

1. 一時的に他部署の業務を行う場面
2. プロジェクト型組織への配属
3. 一時的な特権の利用

　こうしたケースに対応するために、midPointはワークフローを使った権限付与も可能です。本稿でハンズオンはしませんが、代理申請、期限付きの委任（代理承認）、多段承認についても実現可能です。

アクセス要求のハンズオン

　本稿では、「開発プロジェクトの工期を圧縮するために、運用2課の一般社員が『開発アプリケーション』ロールを申請し、開発ツール（PostgreSQL）のアクセス権限が付与される」というシナリオでハンズオンします。さらに「承認者が不在の自動承認の場合」「承認が必要な場合」の2つでシナリオを分けます。なお、承認が必要な場合、申請に対する承認者は「開発マネージャー」ロールが割り当てられている開発部部長です。

　ハンズオンでは下表のように申請者と承認者を設定します。

シナリオ	従業員番号	氏名	所属	役職
申請者	023	渡辺英輔	運用2課（1320）	一般社員
承認者	001	安藤ありす	サービス開発部（1200）	部長

事前準備

アクセス要求の設定

　今回のハンズオンは連載第4回で構築および設定した環境を前提としています。まだ環境を構築していない場合はリポジトリ（https://github.com/Hitachi/midpoint-sample-configuration.git）から取得してください。なお、本手順では新たなファイル取得は発生しません。

$ cd midpoint-sample-configuration
$ git pull

　midPointにおいて、ロールの初期状態は管理者による付与が原則となります。そのため、まずは申請者がロールを要求できるように設定変更します。midPointの管理画面から「ロール」→「すべてのロール」→「Development Application Role」（名前部分）を選択します。

　「基本情報」タブ→「プロパティー」の下部にある「空項目を表示する」を選択します。

　「要求可能」という項目があるので、「未定義」から「True」に変更してください。この操作で該当ロールは各メンバーがセルフで要求できるようになりました。

申請者の設定

　次に、渡辺さんが開発ツールの権限を要求するには渡辺さん自身でログインできる必要があるので、設定します。

　midPointの管理画面から「ユーザー」→「すべてのユーザー」を選択し、2ページ目にある「023」を選択します。

　「アサイン」から「ロール」を選択し、「新規」ボタンを選択します。

　「End User」ロールを選択し、「追加」ボタンを押して保存します。

　ログインできるようになったので、ログインしてみます。一度画面右上からログアウトし、ユーザー名「023」、パスワード「qwe123」を入力します。

　画面が表示されたらログイン設定は完了です。midPointでは「administrator」以外のユーザーがログインするためには「End User」というロールが必要となります。承認者の設定でも必要になるので覚えておきましょう。

自動承認

　承認者がいない自動承認のケースです。要求と同時にロールが付与されることを確認します。

　まず、渡辺さんの画面左側にある「ロールの要求」を選択します。アクセスを要求できていれば、「Development Application Role」が表示されます。

　midPointではロールを要求することをECサイトに模して表現しています。選択したロールはショッピングカートに入り、ショッピングカートから要求を確定するという流れで進んでいきます。

　カートに追加するボタンを押して、ショッピングカートに行くボタンを選択します。なお、ショッピングカートに行くボタンだけでなく、ショッピングカートからでも次の新規アサインの一覧画面に遷移できます。

　リクエストボタンを押します。これで「Development Application Role」はすぐに利用できます。

　念のため、付与されているかどうか確認しましょう。画面左側の「プロファイル」→「アサイン」→「ロール」を選択してください。「Development Application Role」が表示されていれば、完了です。

手動承認（ワークフロー）

　手動承認（ワークフロー）のケースの流れは次の通りです。

1. midPointにログインし、開発アプリケーションロールを申請する（権限リクエストを参照する）
2. ワークフローが承認依頼として処理する
3. 開発部部長に承認依頼を通知する（リクエスト承認を参照する）
4. 承認作業を実施後、ワークフローに通知する
5. ワークフローが承認済みとして処理する
6. 運用課一般社員に開発アプリケーションロールを付与する（結果確認を参照する）

承認者の設定

　手動で承認するために、先ほど取得したロールの削除と承認者の設定を行います。一度「administrator」でログインし直します。

　先ほど付与したロールを外しておきます。画面左側の「ユーザー」→「すべてのユーザー」から名前「023」を選択します。「アサイン」→「ロール」を選択し、「Development Application Role」の右側にあるマイナスボタンを選択後、「保存」ボタンを押します。

　念のため再度、画面左側の「ユーザー」→「すべてのユーザー」から名前「023」を選択し、「アサイン→ロール」を選択して「Development Application Role」がなくなっていることを確認します。

　承認者の設定に移ります。画面左側の「ユーザー」→「すべてのユーザー」から名前「001」を選択します。「アサイン」→「ロール」を選択し、「新規」ボタンを押します。「End User」の他に「Approver」を選択します。Approverとは承認者のロールで、承認するために必要なロールです。「追加」ボタンを選択します。

　次に「どのロールを承認するのか」を設定するために、再度「新規」ボタンを押します。「Development Application Role」を選択し、パラメーターにあるリレーションを「承認者」に変更します。確認後、「追加」ボタンを押します。

　ロールには「Approver」「Development Application Role」（承認者）、「Development Manager Role」「End User」の4つのロールが表示されているはずです。確認後、「保存」ボタンを押します。

　これで承認者の設定は完了です。

権限リクエスト（申請者）

　一度画面右上からログアウトし、再びユーザー名「023」、パスワード「qwe123」を入力します。ロールの要求を選択し、「カートに追加する」を選択します。

　ここまでは先ほどの自動承認と変わりません。「リクエスト」ボタンを押します。

　すると、「あなたのリクエストは進行中です」と表示されます。

　付与されているかどうかを確認します。画面左側の「プロファイル」→「アサイン」→「ロール」を選択してください。今度は表示されておらず、承認が必要であるということが分かります。

リクエスト承認（承認者）

　承認をしてみましょう。一度画面右上からログアウトし、ユーザー名「001」、パスワード「qwe123」を入力します。

　画面左側の「ケース」→私の作業アイテムを選択します。ユーザー「023」から要求があったことが分かります。「ユーザー“023”にロール“Development Application Role”をアサインしています」をクリックします。

　承認画面が表示されるので、「承認」ボタンを押します。

　これで承認が必要な作業は全て完了しました。

結果確認（申請者）

　画面右上からログアウトし、再びユーザー名「023」、パスワード「qwe123」を入力します。画面左側の「プロファイル」→「アサイン」→「ロール」を選択してください。

　「Development Application Role」が表示されていれば、承認が完了し、利用できる状態になっています。

監査ログによる変更内容の確認

　最後に、連載第3回の監査ログで行った、アカウント状態の変更を確認します。midPoint の「レポート」→「監査ログビューアー」に移動してください。第3回と異なり、イニシエータ（実施者）が「023」と「001」の両方が記録されています。イニシエータ「001」、イベントタイプ「作業アイテム」、ターゲット「023」の記録を見てみましょう。確認するには時刻のリンクを選択します。

　デフォルトだと変更ユーザーが閉じられているので、右側にある矢印ボタンを押します。すると結果「Approval（承認）」、追加アサインに「Development Application Role」が表示されていることを確認できます。これはユーザー「001」がユーザー「023」に「Development Application Role」の付与要求を承認したということを意味しています。

次回は重要な“権限の棚卸し”について

　今回はmidPointを利用したロールの申請、承認をハンズオンで試し、統制の観点で重要なワークフローを紹介しました。次回は同じく重要な“権限の棚卸し”を紹介します。