自組織からゲスト参加できる外部組織を制限する（Entra ID・PP） ～運用編～
はじめに
設定編でEntra IDのテナント間アクセスで自組織からゲスト参加できる外部組織を制限しました。
しかし、コラボレーションする外部組織がどんどん増えると管理者の負荷も比例して高くなります。
というわけでユーザーさんにはPower Appsからコラボレーションしたい組織を申請してもらい、Power Automateで申請者の上司に承認リクエストを送りEntra IDのグループに申請者を自動で追加してもらいます。
プレミアムライセンスのアクションは使わずすべて標準機能で実現
注意事項
- コラボレーションする組織数が5000（SPOリストの検索上限値）を超えると正常に動作しない場合があります。
SPOリストの作成
今回は「セキュリティグループを管理するリスト」・「申請状況を可視化するリスト」を作成します。
列名は英語で作成し作成後に日本語に変更して大丈夫です。
※Power Platformで利用するときは列名は英語で作成するのが鉄板らしいです
SPOリストの作成
セキュリティグループを管理するリスト（List-Allow-Join-Organization-As-Guest）を作成します。
| 列名 | 型 | 備考 |
|---|---|---|
| タイトル（グループ名に変更） | ー | Entra IDのセキュリティグループ名 |
| objectGuid | 1行テキスト | セキュリティグループのGuid |
| DisplayEasyNameForUser | 1行テキスト | 申請者に表示する組織名 |
作成したList-Allow-Join-Organization-As-Guestリストにセキュリティグループの情報を記載しておきます。
ObjectGuidはEntra IDのセキュリティグループの概要のページから取得できます。
次に申請状況を可視化するリスト（List-Wait-For-Request-Of-Guest）を作成します。
| 列名 | 型 | 備考 |
|---|---|---|
| タイトル | ー | 申請者のメールアドレス |
| GroupName | 1行テキスト | Entra IDのセキュリティグループ名 |
| DisplayEasyNameForUser | 1行テキスト | 申請者に表示する組織名 |
| ObjectGuid | 1行テキスト | セキュリティグループのGuid |
| RequestReason | 1行テキスト | 申請者が入力した申請理由 |
| RequestStatus | 選択肢 | Wait for manager Approval、Wait for Systema admin Approval |
作成したList-Wait-For-Request-Of-Guestはレコードを追加しなくて大丈夫です。
Power Appsから入力された情報を一時的に保管してPower Automateで利用する用途です。
キャンバスアプリの作成
空のキャンバスアプリから作成します。
こんな感じでテキストラベルを追加します。 ※再利用しないので名前は任意
組織を検索するギャラリー（SPOリストのList-Allow-Join-Organization-As-Guest）を作成します。
完成形はこんな感じなのでイメージできる方は飛ばしてください。
組織を検索するギャラリーの作成
Welcome Excellent仕事術さんのこちらの記事を参考にギャラリーの一覧から組織を検索できるようにします。
テキスト入力（SearchOrganization）と虫眼鏡アイコンを追加します。
ギャラリー(ListOrganization)を追加し、データソースを「List-Allow-Join-Organization-As-Guest」にします。
レイアウトを[タイトル]、フィールドのTitleの値を「DisplayEaseNameForUser」にするとユーザーが分かりやすい組織名となります。
ギャラリー(ListOrganization)のItemsプロパティを以下の値にすると、DisplayEaseNameForUserの値で検索できます。
Filter('List-Allow-Join-Organization-As-Guest',StartsWith(DisplayEasyNameForUser,SearchOrganization.Text))
まだ管理者が設定を完了していない・リクエストがなかった組織はギャラリーには表示されないので、Formsかなにかでリクエストしてねとテキストラベルを追加します。（新規組織を追加するリクエストフローは今回は作成しません）
次に申請フォーム（SPOリストのList-Wait-For-Request-Of-Guest）を作成します。
完成形はこんな感じなのでイメージできる方は飛ばしてください。
申請フォームの作成
Office365ユーザーへの接続を追加し、AppのFormulasプロパティを以下の値にします。
SignInUser = User();
Manager = Office365ユーザー.ManagerV2(SignInUser.Email);
フォーム（RequestForm）を追加し以下のプロパティを変更します。
- データソース：List-Wait-For-Request-Of-Guest
- DefalutMode：FormMode.New ※新規
- OnSuccess：ResetForm(RequestForm)
フォーム（RequestForm）の「タイトル」カードのロックを解除しDataCardValueの以下のプロパティを変更するとユーザーのメールアドレスが表示されます。
- DisplayModeプロパティ：DisplayMode.View
- Defaultプロパティ：SignInUser.Email
しかし、「タイトル」：メールアドレスだと違和感があるので「タイトル」のDatacardKeyを選択しTextプロパティを"申請者"とします。
こんな感じで他のフォーム要素も変更します。
フォーム（RequestForm）の「DisplayEasyNameForUser」カードのロックを解除しDataCardValueの以下のプロパティを変更するとギャラリーで選んだ組織名が表示されます。
- DisplayModeプロパティ：DisplayMode.View
- Defaultプロパティ：ListOrganization.Selected.DisplayEasyNameForUser
しかし、「DisplayEasyNameForUser」：組織名だと違和感があるので「DisplayEasyNameForUser」のDatacardKeyを選択しTextプロパティを"組織名"とします。
フォーム（RequestForm）の「RequestReason」カードのロックを解除しDataCardValueの以下のプロパティを変更するとギャラリーで選んだ組織名が表示されます。
- Modeプロパティ：TextMode.MultiLine
しかし、「RequestReason」：組織名だと違和感があるので「RequestReason」のDatacardKeyを選択しTextプロパティを"申請理由"とします。
また、申請理由は必ず入力してほしいので「RequestReason」のカード全体を選択し、以下のプロパティを変更すると必須項目のアイコンが表示されます。
- Required：true
他の項目は非表示としますが、「GroupName」と「objectGuid」はSPOに情報を渡してあげたいのでそれぞれのDataCardValueのDefault値を入力しておきます。
- GroupName > DatacardValue > Default：ListOrganization.Selected.タイトル
- objectGuid > DatacardValue > Default：ListOrganization.Selected.objectGuid
カードのVisibleプロパティをfalseに変更します。
フォームの列を1列、フォントサイズを18、申請理由のテキスト入力の幅を広げます。
それっぽくなりました。
せっかく上司を変数Managerに格納したので、テキストラベルを2個追加し、片方のText値をManager.displayName& " " & Manager.mail にして承認者をわかりやすく表示します。
SPOリストに上司の列を追加しておけばPwoer Automateで取得する必要はなかったですね。
手戻り面倒でさぼりました
ボタンコントロールを追加しOnselectプロパティをSubmitForm(RequestForm)とします。
申請の確認画面をモーダルウィンドウで表示したり、申請理由が入力されていない時にエラーテキストを表示したり、申請成功画面に遷移したり、といった設定をいれるのもありかと思います。今回は省略します。
以上で最小限のPower Appsアプリの作成が完了しました。
Power Appsのアプリ画面で申請理由を入力し申請ボタンを押すとSPOリストの「List-Wait-For-Request-Of-Guest」にレコードが追加されます。
このレコードの更新をトリガーにPower Automateを作成します。
Power Automateでフローを作成
自動化されたクラウドフローから作成します。
全体像はこんな感じです。
フローを作成
トリガーでSPOの項目が作成されたときのトリガーを使います。
すでにグループに追加されていればこのフローは不要なためグループメンバーシップの確認（V2）アクションをで既存設定を確認します。
- ユーザーのIDまたはUPN：動的なコンテンツ > 項目が作成されたとき > タイトル
- Body/GroupIds：動的なコンテンツ > 項目が作成されたとき > objectGuid
グループメンバーシップの確認の戻り値の配列の要素数が0という条件を追加します。
length(outputs('グループ_メンバーシップの確認_(V2)')?['body/value'])
共通の処理を作ります。
SPOリスト「List-Wait-For-Request-Of-Guest」は申請状況を可視化するための一時的なレコード保存場所なので申請が完了した後はレコードを削除します。
次にFalseの場合、既にグループに申請者が割り当たっているのでユーザーにゲスト参加できますよとTeamsチャットを送付します。
次にTrueの場合のフローを作ります。
SPOリストの項目の更新でRequestStatusの値をWait for manager Approvalにします。
※多段承認フローの時に役立つかなと思いました。今回はあんまり役立ちません。
Office365ユーザーの上司の取得（V2）アクションで上司の情報を取得します。
※Power Appsでも取得できるのでPower Appsで取得してSPOリストに追加しておくとこのフローは不要です。後から気づきました。
上司の情報を取得できたので承認依頼を作成します。
承認依頼の結果で条件を分岐します。
差し戻し（False）だった場合、申請者に差し戻されたというTeamsチャットを送付します。
承認された場合のフローを作成します。
Entra IDのユーザーの取得アクションでユーザーのObjectGuidを取得します。
※Power Appsでも取得できるのでPower Appsで取得してSPOリストに追加しておくとこのフローは不要です。後から気づきました。（2回目）
Entra IDのユーザーをグループに追加アクションでユーザーをグループに追加します。
ここで少し脱線しますが、Excelで申請履歴を管理したい組織もあるかもしれません。
そこで事前にExcelで以下のようなテーブルを作成しておき、Excel Onlineの表に行を追加アクションで申請情報を追記できます。
最後に外部組織にゲスト参加できるようになったことを申請者にTeamsチャットを送付します。
フローを実行すると上司に承認リクエストがとんでいきます。
おわりに
今回はJapan EMS User Groupの勉強会の動画を見てPower PlatformでEntra IDの運用の自動化をやってみたいなということで取り組んでみました。
Discussion