FormsとPower AutomateでEntra IDのゲスト招待システム&棚卸システムをつくってみる（その４）
このシリーズは、他社のユーザーを自社にゲストとして招待することを従業員から申請させるシステムを作ろうというチャレンジです。
システムと入っても、ユーザーの申請画面はアンケートなどで用いられるFormsで作り、管理用データベースにはSharePointリストを使います。
後続の処理はPower Automateのクラウドフローを使ってノーコード（ちょこっと関数は使うけれど）で構成しています。従業員から申請された内容の承認も組み込みます。
自社のMicrosoft 365運用で、テナントにゲストを招待しているもののその棚卸に苦労している管理者の方の参考にしてもらえれば嬉しいです。ブログのコメントやTwitter(現X.com)にメッセージやご指摘をいただけると励みになります。
ここまでと、これから
過去３回の記事で作成した処理内容とこれからの予定です。部分的に知りたいという方はリンク先に飛んでみてください。
- （その１）Formsでユーザーがゲスト招待申請を投稿する。
- （その１）クラウドフその１，その２ローがSPOリストの追加によってトリガーされる。
- （その２）入力されたゲストEmailがメールアドレスとして妥当か（正規表現が使える？）確認して、受付または却下メールを申請者へ送る（却下ならステータスを「却下」にして、備考に理由を書き込む。妥当ならステータスを「承認待ち」にして申請日を書き込む）。
- （その２）承認者ユーザーに承認要求を送る。
- （その３）承認が通ったら承認日時に書き込み、ステータスを「承認済み」に更新して次へ進む。
- （その３）却下の場合は、承認者のコメントを含めたメールを申請者に送る。
- （その３）14日間承認されない場合は、ステータスを「承認待ち14日期限切れ」に変えて申請者へメールを送る。
- （その３）各ステータスをSPOリストに書き込む。
- （今回）管理者としてEntra IDのゲストを登録する。
- 登録が成功したら、SPOリストの棚卸期限列に、ゲスト招待期間の数字を加えた日付を登録する。
- 登録が成功したら、承認者と申請者にメールで通知する。
- 登録が失敗したら、管理者へ通知する（チャネル投稿）→Teamsチャネルを見て、エラーを確認し、手動でゲスト登録をしてSPOリストを書き換え、チャネルに行った対応を投稿する運用で回避。SPOリストにTeamsの投稿URLを入力できる列があっても良いかも。
前回まで作成した処理
ここまでで作成した処理です。ユーザーが申請したゲストのEmailアドレスの妥当性を正規表現でチェックし、Forms上で指定された承認者に承認要求を送ります。却下されたら申請者へお知らせし、承認者が一定期間返事を返さない場合もタイムアウトさせます。
この後でEntra IDへのゲスト招待処理を追加するので、タイムアウトと却下の場合は処理はここで終了です。
SPOリスト上で管理するステータスは下記のようなものを想定しています。
- 却下
- 入力内容不整合
- 承認待ち
- 承認待ち14日期限切れ
- 承認済み
- ゲスト
- ゲスト追加失敗
ゲスト追加はEntra ID コネクタではできない？？？
さて、早速ゲストとしてユーザー作成を・・・。と思ってEntra ID アクションを開いてみましたが、ゲストを選択する項目が無いことに気が付きました。（今さら？？）
そこで検索してみると、Qiitaでピッタリの記事の投稿を見つけました。
https://qiita.com/ChisatoMatsunami/items/0fbf1beb7ffd1ce8a721
ゲストについてはHTTPリクエストで追加する必要があるようです。
(Microsoft Learn)https://learn.microsoft.com/ja-jp/graph/api/invitation-post
サービスプリンシパルを作成する
サービスプリンシパルに馴染みが無い方のためにこの部分も解説します。ゲスト招待とサービスプリンシパルに関しては こちら の記事を参考にしました。
「サービスプリンシパル」に対して、普通のユーザーのことを「ユーザープリンシパル」と言ったりします。ユーザーには管理者とか一般ユーザーとか、その他人によってできることが決められていて、そのユーザーでサインインして利用します。
「サービスプリンシパル」は、アプリ用のIDとパスワードのようなものです。ここから先の作業は、ゲスト招待システムが招待機能を持つための専用IDとパスワード（シークレット）を作るような手続きです。
Entra IDのアプリ（サービスプリンシパル）登録
ここからの操作は、会社のシステム部署しか行えないケースが多いです。 https://portal.azure.com/ にアクセスして、Entra IDから「アプリの登録」>「＋新規登録」を行いますが、グレーアウトしているなどで追加できない、そもそもアクセスできないような場合には、会社のシステム部署にお願いをしましょう。
アプリケーション登録の名前は、任意で大丈夫です。組織によってこの命名規則が決まっていたりするかもしれません。サポートされているアカウントの種類については、シングルテナントで大丈夫だと思います。
APIアクセス許可の追加
アプリ登録ができたら、このアプリ（サービスプリンシパル）が、どんなことができるのかの権限範囲を決めてやります。今回の目的はゲスト招待ですので、その作業に必要な権限だけを追加します。
「管理」>「APIのアクセス許可」をクリックして、「＋アクセス許可の追加」をクリックしたら、「Microsoft Graph」>「アプリケーションの許可」を選択します。
「アクセス許可を選択する」ではMicrosoft Learnに書かれている最小権限である「User.Invite.All」を選択して先に進みます。
構成されたアクセス許可の一覧にUser.Invite.Allが追加されたら「〇〇に管理者の特権を与えます」をクリックします。これで、作成したサービスプリンシパルに外部ユーザーを招待する権限が与えられたことを意味します。
シークレットの取得
次に、作成したサービスプリンシパルを使うためのシークレットを作成します。パスワードと思えば良いです。「クライアントシークレット」を選択して「＋新しいクライアントシークレット」をクリックすると、名前と期間指定を求められます。適当で良いです。次へ進むと下記画面の「値」のところに表示されるのがシークレットです。「シークレットID」という欄の文字列ではないので注意しましょう。値はいちど他の画面に移動すると隠されて見えなくなるので、すぐコピーしておきます。
もしクライアントシークレットをコピーし忘れた場合は、削除してもう一度作り直せばよいです。
必要な情報３点セット
ここまでのアプリ登録作業の結果をPower AutomateのHTTP要求に追加していくのですが、必要な情報は３つあります。どのテナントの、どのアプリの、パスワードかがわかるために必要な情報３点です。
まず、作成したアプリ登録の画面で「概要」をクリックした際に表示されている以下の２箇所の値です。モザイクをかけている場所の値をコピーしておきます。それに加えて先程取得したシークレットの値です。システム部署にアプリ登録をお願いした場合には、最低限この３点を教えてくれるはずです。
- アプリケーション（クライアントID）
- ディレクトリ（テナント）
- 証明書とシークレットで取得したシークレトの値
テスト用のフローで実験してみる。
ひとまず、テスト用のクラウドフローを仮で作って、HTTPリクエストによってゲスト招待ができるのかを実験します。
URIに入力するのはMicrosoft Learnで指定されているGraph APIのエンドポイントにひっつけるので以下のとおり。方法には追加したいユーザーなどの情報を投げるので「POST」を選択します。
https://graph.microsoft.com/v1.0/invitations本文には、他テナントに所属するユーザーのメールアドレスを含んだ情報をJSON形式で書いておきます。ユーザーが招待されたあとにどこに飛ぶかをリダイレクトURLに指定されるのですが、とりあえずTeamsのURLでよいのではないでしょうか？
テナント、クライアントID、シークレットは先程の３点セット。ポイントが「対象ユーザー」なのですが、招待する人かと思ったら全然だめで、Graph APIのエンドポイントを入れるとうまく行くようです。この記事を見てようやくわかったところです。
本文には以下のように書きます。
{
"invitedUserEmailAddress": "test@example.com",
"inviteRedirectUrl": "https://teams.microsoft.com"
}
実行してみたら成功したっぽいです。
Microsoft 365 管理センターを開いてみると、ばっちりゲストとして追加されていました。
ゲスト招待システムにコピーして使う
テストフローで成功したので、HTTP要求のアクションをコピーして、本番にフローにコピーします。招待するメールアドレス部分を、トリガーから取得したゲストEmailの動的な値に差し替えます。
Microsoft 365 管理センターで先程のテストで追加したゲストを削除して、Formsの入力、承認プロセスを経てもうまく行くかテストしてみます。今回はメールからの承認をしてみます。
成功しました！ガッツポーズです。
ライセンスについて
ここまで実装して、当初Microsoft 365 E3のライセンス範囲での実装を目論んでいましたが、HTTP要求は残念ながらプレミアムライセンスです。プレミアムコネクタを使うには以下の３種類の戦略があります。
- クラウドフローを作成するユーザーにPower Automate Premium ライセンスを付与する
- クラウドフローを作成している環境（既定環境はNG）に、Power Automateを有効にした従量制課金の請求プランを割り当てる
- Power Automate プロセスライセンスをクラウドフロー自体に割り当てる（クラウドフローはソリューションの中にある必要あり）
このなかでは、１番のユーザーに割り当てるPremiumライセンスが月額2000円ちょっとなので、他の開発も行えることを考えるとお得かと。
２番は最近利用できるようになった方法で、フローの実行ごとに課金される仕組みです。価格は変わるかもしれませんが１フロー実行ごとに$0.6とのことです。
３番目のPower Automateプロセスは、従来Power Automate per flowと呼ばれていたものが、RPA利用ができるライセンスと合体したもの。価格はユーザーライセンスのPower Automate Premiumの10倍くらいするので、ゴリゴリ動くフロー向けです。
Power Platform開発者プラン
それでもプレミアムコネクターを使ったフローを作成するならば、無料で使える開発者プランがあります。
https://learn.microsoft.com/ja-jp/power-platform/developer/plan
このプランを使って開発環境で処理を作り、できたらソリューションをエクスポートして本番環境へインポートするというような使い方ができます。
まとめ
今回（その４）では、Entra IDにゲストを招待するキモの部分を実装しました。
当初はEntra IDのユーザー追加が使えるだろうと気楽に考えていましたが、ゲスト招待にはHTTPリクエストが必要でしたので、アプリ登録によるサービスプリンシパルの作成と、その使い方を紹介しました。
実はHTTPリクエストにはベアラートークンを取得してから渡さないとダメと思っていたのですが、HTTPアクション自体にEntra IDのサービスプリンシパルをそのまま使える機能が備わっていたので、１アクションで実行できるのが目から鱗でした。
次回（その５）では、ゲスト登録が失敗した場合の処理などの後処理を加えていきます。
こんな人が作ってます。
お仕事でPower BIやPower Automateクラウドフローを中心にちょっとした自動化などを行っています。
QiitaやこのブログではPower Automateの話題を中心に投稿を行っていますので、ぜひ「いいね」してくださると励みになります。