組織GoogleアカウントのEntra ID federationを検証してみました
こんにちは。SKYこと関谷です。
「短編で行きます！」と言っておきながら、今回はいきなり志向を変えて、 検証シリーズ をお届けしたいと思います。前回とは異なり長文となりますが、お付き合いくださいませ。
はじめに
私は普段、ChromebooksやChromeブラウザを多く扱う機会があります。
それらを起点に組織管理のGoogleアカウント（Google Cloud Identity、Google Workspace、Entra ID等の周辺認証基盤）周りに関わることもよくあります。
高セキュリティな環境実現のためにChromebooks(ChromeOS端末)やChromeブラウザを導入するというご要望をよく聞きます。その際に組織管理のGoogleアカウントを使う必要があるが、すでにMicrosoftさんのEntra IDと連携しているシステムがあり、認証基盤（Entra ID）を変えると影響が大きいため、Entra IDで認証をしながら、Googleの組織管理アカウントを利用したいという要件が多いのです。
こういった要件は、私の周りでは基本的なことではあるのですが、ここで詰まるとその先の本質的なところへ進めない状況も目にします。
少しでもそういった敷居を下げるために、組織Googleアカウント（Google WorkspaceやGoogle Cloud Identityで管理されるGoogleアカウント）をEntra IDとフェデレーションする（Entra IDをIdPとしたSP initiated）といったシーンを背景にした検証という形式で、その設定内容を解説していきたいと思います。
冒頭では、フェデレーションは曖昧．．．という方向けにフェデレーション関連の基本のキも添えます。
基本は大丈夫！とりあえず、設定手順を見たいという方はこちらからご参照ください。
キーワード
- Google Cloud Identity
- Google Workspace
- Microsoft Entra ID（旧 Azure AD）のユーザー プロビジョニングとシングル サインオン
- Google Cloud と Microsoft Entra ID（旧 Azure AD）を連携する
せっかくなので基本のキ
シングルサインオン
皆さんはどのような認証方式を使われていますか？
複数のシステム個々でＩＤを持ち、個々で認証されるものもまだまだ多く残っているかと思いますが、最近主流といえば 「シングルサインオン」 ですよね？
私の言葉でごく簡単に説明を記載するなら、
- １か所で認証したら
- 対象のサービスの利用許可を与える（＝利用可能とする）
といった概念だと私は捉えています。
こういった概念のおかげで、例えば、毎朝のログオン地獄から解放されます。
その他の利点としてわかりやすいところとしては、下記のようなものが考えられます。
- 利用者がいくつもIDを覚える必要がなくなる
- システム管理者もID管理運用の負荷が下がる
- 認証の方法（ID/PASS、生体認証、ワンタイムパスワード、セキュリティキー、パスキー等）が統一され迷いずらくなる
- 認証基盤のセキュリティ対策が１か所で済む
フェデレーション（連携）
シングルサインオンを実現する技術方式は複数存在します。私が比較的聞く方式を上げると下記のようなものです。
- フェデレーション（連携）方式
- エージェント方式
- リバースプロキシ方式
この中でも最近使われる組織が多いGoogle WorkspaceやMicrosoft365といったSaaS系クラウドサービスを利用する際に主流なのが、フェデレーション（連携、federation）方式です。
こちらも簡単に記載するなら、下記のような方式になります。
- １つ認証基盤で認証したら 通行証 が発行される
- 上記の 通行証 を提示して事前提携済みのサービス利用が可能
フェデレーション方式で多く利用される（標準規格）プロトコルは下記のようなものがあります。
- SAML (Security Assertion Markup Language)
- OAuth 2.0
- OpenID Connect
- WS-Federation (Web Services Federation)
- SCIM (System for Cross-domain Identity Management)
現在領域関係せず広く利用されている方式は、上から３つでしょうか。
その中でも、組織のGoogleアカウントをEntra IDで認証するというシーンでは、SAMLが使われています。
そこで、本執筆では、SAMLでのフェデレーションを検証していきます。
本検証の目標（何が確認出来たら検証成功とするか）
Googleアカウント認証をEntra IDをIdPとしたSAML連携（フェデレーション）方式の確認とSSO（シングルサインオン）が成功することを確認します。
２つのケース目標を設定します。
目標①
EntraIDとGoogleのアカウントドメインが異なるケースでのSSO成功
EntraID(IdP): sekiya.biz Google: a.sekiya.biz
目標②
EntraIDとGoogleのアカウントドメインが同じケースでのSSO成功
EntraID(IdP): a.sekiya.biz Google: a.sekiya.biz
検証環境の前提
検証環境前提（全体概要）
本書検証では、Googleの組織アカウント(Google Workspace/Cloud Identityで管理、以降 "Googleアカウント" と呼ぶ)をSAMLプロトコルを使ったフェデレーション（連携）方式でEntra ID Free版にて認証する方法を記載します。
下図は、本書検証を進める上での前提環境を記載していますので、本書検証手順を進める前に予めご用意をお願いします。
別途ドメイン取得とそのサブドメイン発行をされていることは必要ですが、Google WorkspaceならびにEntra ID(Azure)環境のライセンスは30日間の検証版でお試しいただけます。
検証環境前提（Entra ID）
独自ドメインの登録
- Azure Portal内Entra ID: 管理 > カスタムドメイン名
- カスタムドメインの追加 をクリック
独自ドメイン1と2共に追加済 ※目標①の検証だけなら1のみでOK
検証用ユーザの登録
Entra IDへ下記２つのユーザアカウントを追加
- Azure Portal内Entra ID: 管理 > ユーザー
- ＋新しいユーザー をクリック
- 下記アカウントを作成
- user0@sekiya.biz: 目標①検証用
-
user1@a.sekiya.biz: 目標②検証用 ※目標①の検証だけなら不要
検証環境前提（Google）
独自ドメインの登録
- Google Admin Console内: アカウント > ドメイン > ドメインの管理
- 独自ドメイン2をプライマリとして追加済
検証用ユーザの登録
Google(Google Workspace or Cloud Identity)へ下記２つのユーザアカウントを追加
- Google Admin Console内: ディレクトリ > ユーザー
- 新しいユーザ―の追加 をクリック
- すべての組織部門のユーザーを選択
- user0@a.sekiya.biz: 目標①検証用
-
user1@a.sekiya.biz: 目標②検証用 ※目標①の検証だけなら不要
検証追加設定手順
それでは、前提とした検証環境へフェデレーションのための追加設定を実施していきます。
全体の流れとしては、下記の順番で操作するコンソールが変わりますので、予めご認識ください。
1. Google Admin Console
2. Entra ID
3. Google Admin Console
検証追加設定手順（Google Admin Console）1
- Google Admin Consoleへ特権管理者にてログオンする。
- 左メニューから 三本線アイコン > 「セキュリティ」 > 「認証」 > サードパーティの IdPによるSSO をクリック
- 「サードパーティの SSO プロファイル」項から 「SAMLプロファイルを追加」 をクリック
- 「SSOプロファイル名」に 「
Entra ID」 (任意名)と入力し、 「保存」 をクリック
- 「サードパーティの SSO プロファイル」項から追加した 「Entra ID」 をクリック
- 下記情報を保管する（後程使います）
- エンティティID → SP情報①
- ACSのURL → SP情報②
検証追加設定手順（Entra ID）
-
Azure Portal内へ管理者でログオンして、Entra IDへ移動。
-
左メニューから 「管理」 > 「エンタープライズアプリケーション」 をクリック
-
上段のメニューから 「新しいアプリケーション」 をクリック
-
上段の検索窓に「
Google Cloud」と入力して検索し、 「Google Cloud / G Suite Connector by Microsoft」 をクリック
-
右ペインの名前に「
Google Cloud」(任意名)と入力して、 「作成」 をクリック
-
「2.シングル サインオンの設定」 をクリック
-
「SAML」 をクリック
-
①「基本的な SAML 構成」の右上方 「編集」 をクリック
-
「識別子 (エンティティ ID)」の既定となっている行へ SP情報① を入力、「応答 URL」の既定となっている行へ SP情報② を入力
-
「サインオン URL」へ下記を入力
https://www.google.com/a/{Googleプライマリドメイン}/ServiceLogin?continue=https://console.cloud.google.com/
-
「ログアウト URL」へ「
https://accounts.google.com/Logout」を入力し、左上方の 「保存」 をクリックしてから、右上方の 「×」 をクリック
-
②「属性とクレーム」右方の 「編集」 をクリック
ここから 20. までは、目標①の検証を実施する場合のみ必要です。目標②の検証だけを目的とする場合は、 21. から実施してください。
-
「一意のユーザー識別子(名前 ID)」 をクリック
-
ソースで「変換」を選択
-
変換で「RegexReplace()」を選択し、属性名で「user.userprincipalname」を選択
-
正規表現パターンで「
(?'username'^.*?)(?i)(\@{Entra ID アカウントドメイン})$」を入力
- 置換パターンで 「
{username}@{Googleアカウントドメイン} 」 を入力
- 正規表現の入力をテストへ「
user@{Entra ID アカウントドメイン} 」を入力して、 「テストを実行」 をクリック
テスト変換後の結果が「user@{Google アカウントドメイン} 」となっていることを確認
左下方 「追加」 をクリック
-
追加の要求下のクレームの１つの右の 「・・・」 をクリックして、 「削除」 をクリック
-
クレームの削除ダイアログで、 「OK」 をクリック
検証②だけの場合はここから
-
前ページと同様にして、その他の追加の要求を削除する。
-
追加の要求下のクレームがすべて削除されていることを確認して、右上の 「×」 をクリック
-
③「SAML証明書」項の「証明書（Base64）」右の 「ダウンロード」 をクリックして、証明書ファイルを保管しておく。これを IdP情報③ とします。（後程、利用します）
-
「Google Cloud のセットアップ」項で、下記情報の右にある □アイコン をクリックして、それぞれ保管しておく。これらをそれぞれ下記とします。（後程、利用します）
Microsoft Entra識別子→IdP情報①
ログインURL→IdP情報②
-
左メニューの「管理」 > 「プロパティ」 をクリック
-
「ユーザーのサインインが有効になっていますか？」で「はい」を選択
-
「割り当てが必要ですか？」で「いいえ」を選択
- 「左上方」の「保存」をクリック
検証追加設定手順（Google Admin Console）2
-
Google Admin Consoleへ特権管理者にてログオンする。
-
左メニューから三本線アイコン >「セキュリティ」 > 「認証」 > サードパーティのIdPによるSSO をクリック
-
「サードパーティの SSO プロファイル」項から 「Entra ID」 をクリック
-
「IdPの詳細」項右上にある ペンマーク をクリック
-
「IdPの詳細」項内にて、下記のように入力
「IdP エンティティ ID」へ IdP情報①
「ログインページの URL」へ IdP情報②
「ログアウトページの URL」へ（固定値）
https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0
「パスワード変更用 URL」へ（固定値）https://account.activedirectory.windowsazure.com/changepassword.aspx
「確認用の証明書」下の「証明書をアップロード」をクリックして、ファイル選択ダイアログで、 IdP情報③ で保管した（証明書）ファイルを選択する。
-
「保存」 をクリック
-
確認用の証明書が登録されたことを確認して、左上方の 「<-戻る」 をクリック
-
「SSOプロファイルの割り当ての管理」項にて、 「管理」 をクリック
-
左ペイン「組織部門」下の（ルート）組織を選択
Entra IDへの連携を特定の組織部門に限定する場合は、対象の組織部門を選択する
- 「SSOプロファイルの割り当ての管理」下で「別のSSOプロファイル」を選択
SSOプロファイルを選択で「Entra ID - SAML」を選択
左下方の「保存」をクリック
右上の「∧」をクリック
検証①（目標①の検証成功確認）
目標①の検証を行うにあたって、利用するアカウントは、下記のようになります。それぞれのアカウントドメインが異なるケースです。
| アカウント作成先 | アカウント |
|---|---|
| user0@a.sekiya.biz | |
| Entra ID | user0@sekiya.biz |
想定遷移は下記のようになり、Googleアカウントのパスワード入力はありませんが、Googleアカウントでログオンが出来る想定です。
Googleログオン画面
▼
Entra IDログオン画面
▼
Entra IDログオン完了
▼
Googleへ遷移
▼
Googleアカウントでログオン完了
-
Chromeブラウザのシークレットウィンドウで
https://www.google.com/へアクセス -
右上方の 「ログイン」 ボタンをクリック
-
検証①確認用のGoogleアカウント（user0@a.sekiya.biz）を入力し、「次へ」 クリック
-
Microsoftのログオン画面へ遷移したら、検証①確認用のEntra IDアカウント（user0@sekiya.biz）を入力し、「次へ」 クリック
-
検証①確認用のEntra IDアカウント（user0@sekiya.biz）のパスワードを入力して、「Sign in」 クリック
-
Google検索画面右上方のユーザアイコンをクリックし、開いたダイアログ内でログインしているGoogleアカウントが検証①確認用Googleアカウント（user0@a.sekiya.biz）であることを確認
-
途中エラーもなく、フェデレーションで無事ログオンすることが出来ました。
検証①が成功することを確認できました。
検証②（目標②の検証成功確認）
目標①の検証を行うにあたって、利用するアカウントは、下記のようになります。双方まったく同じアカウント名のケースです。
| アカウント作成先 | アカウント |
|---|---|
| user1@a.sekiya.biz | |
| Entra ID | user1@a.sekiya.biz |
想定遷移は検証①と同様です。
-
Chromeブラウザのシークレットウィンドウで
https://www.google.com/へアクセス -
右上方の 「ログイン」 ボタンをクリック
-
検証②確認用のGoogleアカウント（user1@a.sekiya.biz）を入力し、「次へ」 クリック
-
Microsoftのログオン画面へ遷移したら、検証②確認用のEntra IDアカウント（user1@a.sekiya.biz）を入力し、「次へ」 クリック
-
検証②確認用のEntra IDアカウント（user1@a.sekiya.biz）のパスワードを入力して、「Sign in」 クリック
-
Google検索画面右上方のユーザアイコンをクリックし、開いたダイアログ内でログインしているGoogleアカウントが検証②確認用Googleアカウント（user1@a.sekiya.biz）であることを確認
-
途中エラーもなく、フェデレーションで無事ログオンすることが出来ました。
検証②が成功することを確認できました。
検証結果
見て頂いたように、本検証の結果は以下となり、想定通りの動作となり、どちらのケースも成功となりました。
| 目標 | 検証結果 |
|---|---|
| ① | 成功 |
| ② | 成功 |
まとめ
検証結果から、本投稿の設定内容で目標①、②共に満たせることが確認できました。
この投稿内容は、あくまで基本的な内容ですので、Google Cloud公式のヘルプと流れは変わりません。
本検証の中で一番理解してほしいポイントは、SAMLでのフェデレーション設定を行う上で、両サービスのアカウント同士を紐づける情報は何か（Googleはメールアドレス、Entra IDは多くはUserPrincipalName）ということでしょう。覚えておいてください。
また、今回は分量の問題もあり、ユーザアカウントは、GoogleとEntra IDで予め作成しておくこととしていました。
実際の運用では、組織管理のGoogleアカウントやグループの自動作成機能（プロビジョニング）を行うことも要件となる場合があります。これは、別の機会で執筆しようかと思っています。
さいごに
今回の検証では、Google Cloud Identity（組織管理のGoogleアカウント管理システム）とEntra IDを触っていきました。
（経験が多いというのはもちろんありますが）やはり何回触っても、自分には、Googleの方がシンプルでしっくりきます。わかりやすいことが一番だと思います。
今回は、基本的な内容を実施してみましたが、あらためて、Google Cloudの良いところを認識できました。
これからも、Google Cloud IAMとの連携周りや２段階認証など、ID周りについても発信していきます。
長文にもかかわらず、最後までお読み頂き、ありがとうございました。
それではまた！
Discussion