如果您打算將 Cloud Identity 或 Google Workspace 與外部身分識別提供者 (IdP) 建立連結，但仍需整合現有的消費者帳戶，這份文件可協助您瞭解及評估聯盟與整合之間的互動關係。本文也會說明如何設定同盟，以免影響現有個人帳戶的合併作業。
聯盟與合併使用者帳戶之間的相互影響
在同盟設定中，您會將 Cloud Identity 或 Google Workspace 連線至外部授權來源，以便授權來源在 Cloud Identity 或 Google Workspace 中自動佈建使用者帳戶。
這些不變量通常適用於聯邦設定：
- 可靠來源是身分識別的唯一來源。
- Cloud Identity 或 Google Workspace 中沒有權威來源佈建的帳戶。
- SAML 識別資訊提供者不允許 Google 單一登入，除非權威來源已為身分佈建使用者帳戶。
雖然這些不變量反映了連結外部身分識別提供者 Google Cloud 的最佳做法，但如果您想遷移現有的個人帳戶，就會造成問題：
- 現有的個人帳戶並非來自權威來源。這些帳戶已存在，現在需要連結至授權來源所知的身分。
- 現有個人帳戶遷移至 Cloud Identity 或 Google Workspace 後，會成為未由授權來源佈建的使用者帳戶。權威來源必須辨識並「採用」這些遷移的帳戶。
- 現有個人帳戶的身分可能不為 SAML 身分識別資訊提供者所知，但仍須允許這些帳戶使用單一登入。
如要合併現有的個人帳戶，您必須暫時設定同盟，確保帳戶合併作業安全無虞。
確保帳戶合併作業不會影響聯盟
下表列出帳戶整併時，為確保聯盟安全無虞，您需要考量的要求。如果您打算使用外部 IdP，但仍需整合現有的消費者帳戶，請務必確保初始設定符合這些規定。完成現有消費者帳戶的遷移作業後，您就可以變更設定，因為屆時不再需要遵守相關規定。
| 需求 | 原因 |
|---|---|
| 允許使用消費者帳戶的身分進行單一登入 | 如要遷移個人帳戶，必須轉移帳戶。Cloud Identity 或 Google Workspace 管理員會啟動帳戶轉移程序，但必須由消費者帳戶擁有者同意轉移，才能完成轉移。管理員對同意聲明的表示時間沒有太多控制權，因此也無法完全掌控資料轉移時間。 擁有者表示同意並完成轉移後，所有後續登入作業都必須使用外部 IdP 進行單一登入。 如要確保單一登入作業順利完成 (無論轉移作業何時完成)，請確認外部 IdP 允許所有要遷移的消費端帳戶身分進行單一登入。 |
| 禁止為具有消費者帳戶的身分自動佈建使用者帳戶 | 如果您為已有個人帳戶的身分佈建使用者帳戶，就會建立衝突帳戶。如果帳戶有衝突，您就無法將個人帳戶、設定和任何相關聯的資料轉移至 Cloud Identity 或 Google Workspace。 許多外部 IdP 的預設行為是在 Cloud Identity 或 Google Workspace 中主動建立使用者帳戶。這種行為可能會意外建立衝突帳戶。 禁止為現有個人帳戶的身分自動佈建使用者帳戶，可避免無意間建立相衝突的帳戶，並確保個人帳戶能正確轉移。 |
如果您已找出外部 IdP 中沒有相符身分的個人帳戶，且認為這些帳戶合法，並想遷移至 Cloud Identity 或 Google Workspace，請務必確認聯盟設定不會影響您遷移這些個人帳戶。
| 需求 | 原因 |
|---|---|
| 避免刪除外部 IdP 中沒有相符身分的已遷移帳戶 | 如果 Cloud Identity 或 Google Workspace 中的使用者帳戶在外部 IdP 中沒有相符的身分，IdP 可能會將這個使用者帳戶視為孤立帳戶，並將其停權或刪除。 如果外部 IdP 停權或刪除已遷移的帳戶，但與外部 IdP 中的身分不符，您就能避免遺失與受影響帳戶相關的設定和資料，並確保可以手動比對帳戶。 |
確保 Microsoft Entra ID (原稱「Azure AD」) 聯盟安全無虞，可進行帳戶整併
如果您打算將 Cloud Identity 或 Google Workspace 與 Microsoft Entra ID (原稱「Azure AD」) 建立連結，可以使用 Google Workspace gallery 應用程式。
啟用佈建功能後，Microsoft Entra ID 會忽略 Cloud Identity 或 Google Workspace 中沒有對應項目的現有帳戶，因此一律會防止系統刪除已遷移的帳戶，但外部 IdP 中沒有相符的身分。
您還是必須確保完成下列事項，實際情況須視 gallery 應用程式的設定方式而定：
有多種方法可滿足這些需求。每個方法都各有優缺點。
方法 1：不設定佈建作業
在此方法中，您會設定 gallery 應用程式來處理單一登入，但是不會設定自動佈建使用者帳戶。如果不設定使用者帳戶佈建功能，系統就不會為具有消費者帳戶的身分自動佈建使用者帳戶。
如要允許使用個人帳戶的身分進行單一登入，請將應用程式指派給所有可能需要存取 Google 服務的身分，即使現有的個人帳戶仍需要遷移也沒關係。
如果使用者具備現有的消費者帳戶，則當使用者接受轉移要求時，即會自動建立對應的 Cloud Identity 或 Google Workspace 使用者帳戶，該使用者就能立即使用單一登入。
如果使用者沒有 Cloud Identity 或 Google Workspace 使用者帳戶，您必須手動建立帳戶。
雖然此方法符合需求，且設定最簡單，但卻伴隨著下列限制：在 Microsoft Entra ID 中變更任何屬性或將使用者停權的動作不會推送到 Cloud Identity 或 Google Workspace。
方法 2：採用手動指派的兩種應用程式
在此方法中，就算使用者不具備現有帳戶，您也不需要在 Google Workspace 或 Cloud Identity 中為使用者手動建立帳戶。此方法會使用兩種 gallery 應用程式，其中一種用於佈建作業，另一種則用於單一登入：
- 第一個應用程式專門用於佈建使用者和群組，而且已停用單一登入。您可以將使用者指派給此應用程式，藉此控管要將哪些帳戶佈建到 Cloud Identity 或 Google Workspace。
- 第二個應用程式專門用於單一登入，而且沒有權限佈建使用者。您可以將使用者指派給此應用程式，藉此控管允許哪些使用者登入。
使用兩種應用程式按照下列方式指派使用者：
- 將最終需要存取 Google 服務的所有身分指派給單一登入應用程式。請一併指派現有消費者帳戶的身分，允許消費者帳戶身分使用單一登入。
- 將身分指派給佈建應用程式時，請納入最終需要存取 Google 服務的身分，但排除所有已知有現有消費者帳戶的身分。這樣一來，您就能防止系統為個人帳戶的身分自動佈建使用者帳戶。
方法 3：停止建立使用者的兩種應用程式
設定佈建作業時，您必須授權 Microsoft Entra ID 使用 Cloud Identity 或 Google Workspace 帳戶存取 Cloud Identity 或 Google Workspace。一般而言，最好能夠針對此目的使用專屬的超級管理員帳戶，因為超級管理員帳戶不必執行單一登入 (也就是說，任何單一登入 (SSO) 設定都不適用於這些帳戶；超級管理員帳戶將繼續使用密碼進行登入)。
不過在這種情況下，您可以讓 Microsoft Entra ID 使用受到較多限制的帳戶來進行遷移，亦即不允許 Microsoft Entra ID 建立使用者的帳戶。如此一來，無論將哪些使用者指派給佈建應用程式，您都能有效地防止 Azure 自動為具有消費者帳戶的身分佈建使用者帳戶。
Cloud Identity 或 Google Workspace 中的受限制管理員使用者帳戶應僅具備下列權限：
- 機構單位 > 讀取
- 「使用者」>「讀取」
- 使用者 > 更新
- 群組
此方法的缺點是，如果使用者缺乏非代管帳戶，您就必須在 Cloud Identity 或 Google Workspace 中手動建立帳戶。
連結 Microsoft Entra ID：比較
下表是方法的摘要說明。
| 允許使用消費者帳戶的身分進行單一登入 | 禁止為具有消費者帳戶的身分自動佈建使用者帳戶 | 避免刪除外部 IdP 中沒有相符身分的已遷移帳戶 | 自動佈建新帳戶 | 自動更新已遷移帳戶 | |
|---|---|---|---|---|---|
| 方法 1：無須進行佈建作業 | ✅ | ✅ | ✅ | X | X |
| 方法 2：採用手動指派的兩種應用程式 | ✅ | 容易發生人為錯誤 | ✅ | ✅ | ✅ |
| 方法 3：停止建立使用者的兩種應用程式 | ✅ | ✅ | ✅ | X | ✅ |
確保帳戶的 Active Directory 同盟安全無虞
如果您打算將 Cloud Identity 或 Google Workspace 與 Active Directory 建立連結，可以使用 Google Cloud Directory Sync (GCDS) 和 Active Directory Federation Services (AD FS)。設定 GCDS 和 AD FS 時，請務必執行下列操作：
有多種方法可滿足這些需求。每個方法都各有優缺點。
方法 1：停用 GCDS
在此方法中，您會使用 AD FS 設定單一登入，但是要等到完成遷移非代管使用者帳戶之後，您才能啟用 GCDS。停用 GCDS 後，您將無法為具有個人帳戶的身分自動佈建使用者。
如要允許具有個人帳戶的身分進行單一登入，請在 AD FS 中建立自訂存取權控管政策，並指派所有可能需要存取 Google 服務的身分，即使現有的個人帳戶仍須遷移也一樣。
如果使用者具備現有的消費者帳戶，則當使用者接受轉移要求時，即會自動建立對應的 Cloud Identity 或 Google Workspace 使用者帳戶，使用自訂存取權控管政策，確保使用者可以立即使用單一登入。
如果使用者沒有 Cloud Identity 或 Google Workspace 使用者帳戶，您必須手動建立帳戶。
雖然此方法符合需求，且設定最簡單，但卻伴隨著下列限制：在 Active Directory 中變更任何屬性或將使用者停權的動作不會推送到 Cloud Identity 或 Google Workspace。
方法 2：透過 GCDS 手動指派
在此方法中，就算使用者不具備現有帳戶，您也不需要在 Cloud Identity 或 Google Workspace 中為使用者手動建立帳戶：
與方法 1 類似，您可以在 AD FS 中建立自訂存取權控管政策，並指派所有可能需要存取 Google 服務的身分，即使現有消費者帳戶仍須遷移，也能允許身分透過消費者帳戶單一登入。
在 Active Directory 中建立群組，反映您要自動佈建至 GCDS 的使用者帳戶。在成員清單中，加入最終需要存取 Google 服務的身分，但排除所有已知擁有現有個人帳戶的身分。
設定 GCDS，只為這個群組的成員身分佈建使用者帳戶。這樣一來，您就能防止系統為個人帳戶身分自動佈建使用者帳戶。
這種方法的主要限制是，您無法防止系統刪除外部 IdP 中沒有相符身分的已遷移帳戶。因此，只有在沒有任何消費者帳戶在外部 IdP 中沒有相符身分時，才適用這個方法。
方法 3：禁止 GCDS 建立使用者
設定佈建作業時，您必須授權 GCDS 存取 Cloud Identity 或 Google Workspace。一般而言，最好能夠針對此目的使用專屬的超級管理員帳戶，因為這類帳戶不必執行單一登入 (也就是說，任何單一登入 (SSO) 設定都不適用於這些帳戶；超級管理員帳戶將繼續使用密碼進行登入)。
不過在這種情況下，您可以讓 GCDS 使用受到較多限制的帳戶來進行遷移，亦即不允許 GCDS 建立使用者的帳戶。如此一來，您就能有效防止 GCDS 自動為具有個人帳戶的身分佈建使用者帳戶，並避免 GCDS 刪除外部 IdP 中沒有相符身分的已遷移帳戶。
Cloud Identity 或 Google Workspace 中的受限制管理員使用者帳戶應僅具備下列權限：
- 機構單位
- 「使用者」>「讀取」
- 使用者 > 更新
- [Groups] (群組)
- [Schema Management] (管理架構)
- 網域管理
此方法的缺點是，如果使用者缺乏非代管帳戶，您就必須在 Cloud Identity 或 Google Workspace 中手動建立帳戶。
連結 Active Directory：比較
下表是方法的摘要說明。
| 允許使用消費者帳戶的身分進行單一登入 | 禁止為具有消費者帳戶的身分自動佈建使用者帳戶 | 避免刪除外部 IdP 中沒有相符身分的已遷移帳戶 | 自動佈建新帳戶 | 自動更新已遷移帳戶 | |
|---|---|---|---|---|---|
| 方法 1：不設定佈建作業 | ✅ | ✅ | ✅ | X | X |
| 方法 2：透過 GCDS 手動指派 | ✅ | 容易發生人為錯誤 | X | ✅ | ✅ |
| 方法 3：禁止 GCDS 建立使用者 | ✅ | ✅ | ✅ | X | ✅ |
確保 Okta 聯盟安全無虞，可進行帳戶整併
如要將 Cloud Identity 或 Google Workspace 與 Okta 建立連結，可以使用 Okta 應用程式目錄中的 Google Workspace 應用程式。這個應用程式可以處理單一登入，以及在 Cloud Identity 或 Google Workspace 中佈建使用者和群組。
使用 Google Workspace 應用程式進行佈建時，Okta 會忽略 Cloud Identity 或 Google Workspace 中沒有對應項目的現有使用者，因此一律會防止刪除外部 IdP 中沒有相符身分的已遷移帳戶。
視 Okta 的設定方式而定，您仍須執行下列操作：
有多種方法可滿足這些需求。每個方法都各有優缺點。
方法 1：不設定佈建作業
在此方法中，您會設定 Google Workspace 應用程式來處理單一登入，但是完全沒有設定佈建作業。如果不設定使用者帳戶佈建功能，您可以避免為具有消費者帳戶的身分自動佈建使用者帳戶。
如要允許使用個人帳戶的身分進行單一登入，請將應用程式指派給所有可能需要存取 Google 服務的身分，即使現有的個人帳戶仍需要遷移也一樣。Google Workspace 或 Google Cloud 圖示會顯示於所有已指派給應用程式的身分識別的 Okta 首頁上。不過，除非 Google 端剛好有對應的使用者帳戶，否則登入會失敗。
如果使用者具備現有的消費者帳戶，則當使用者接受轉移要求時，即會自動建立對應的 Cloud Identity 或 Google Workspace 使用者帳戶，該使用者就能立即使用單一登入。
雖然此方法符合需求，且設定最簡單，但卻伴隨著下列限制：在 Okta 中變更任何屬性或將使用者停權的動作不會推送到 Cloud Identity 或 Google Workspace。此方法的另一項缺點是，您必須在 Cloud Identity 或 Google Workspace 中，為所有沒有現有個人帳戶的使用者手動建立帳戶。
方法 2：透過手動指派進行佈建
在此方法中，您會設定 Google Workspace 應用程式來處理單一登入和佈建作業，但只啟用下列佈建功能：
- 建立使用者
- 更新使用者屬性
- 停用使用者
將身分指派給應用程式時，請納入最終需要存取 Google 服務的身分，但排除所有已知有現有消費者帳戶的身分。這樣一來，您就能避免為個人帳戶身分自動佈建使用者帳戶。
使用者接受轉移要求後，請立即將使用者指派給應用程式，讓他們能夠使用單一登入，並存取 Google Workspace 或Google Cloud。
這個方法的缺點是，如果在指派過程中發生任何錯誤，即可能會立即產生衝突帳戶，因此這種方法比其他方法更具風險。
此方法的另一項缺點是會導致已遷移帳戶遭短暫鎖定。接受轉移要求後，使用者必須透過 Okta 執行任何後續登入的動作。除非您將使用者指派到 Okta 中的應用程式，否則嘗試進行單一登入作業都會失敗。
方法 3：停止建立使用者來進行佈建
在此方法中，您會設定 Google Workspace 來處理單一登入和佈建作業，但只啟用下列佈建功能：
- 更新使用者屬性
- 停用使用者
保持停用「建立使用者」選項，並將最終需要存取 Google 服務的所有身分指派給應用程式。請一併納入具有現有個人帳戶的身分，以便允許具有個人帳戶的身分使用單一登入。
如果禁止 Okta 建立帳戶，就能避免 Okta 為具有個人帳戶的身分自動佈建使用者帳戶。同時，如果使用者擁有對應的 Google 帳戶，此設定仍可讓 Okta 將屬性變更和使用者停權的動作推送到 Cloud Identity 或 Google Workspace。
如果身分沒有對應的 Cloud Identity 或 Google Workspace 使用者帳戶，Okta 可能會在 Okta 管理控制台中顯示錯誤訊息：
如果使用者具備現有的消費者帳戶，則當使用者接受轉移要求時，即會自動建立對應的 Cloud Identity 或 Google Workspace 使用者帳戶，且該使用者可立即使用單一登入。雖然使用者帳戶此時可以正常運作，但是 Okta 可能尚未在使用者的首頁上顯示圖示，反而持續在管理 UI 中顯示錯誤訊息。如要修正這個問題，請在 Okta 管理員資訊主頁中重試指派作業。
這個方法可防止 Okta 自動為具有個人帳戶的身分佈建使用者帳戶，但仍允許具有個人帳戶的身分使用單一登入。此外，與第二種方法相比，這種方法更不容易發生意外設定錯誤的情形。缺點之一是如果使用者沒有現有的消費者帳戶，您就必須在 Cloud Identity 或 Google Workspace 中手動建立使用者帳戶。
方法 4：採用手動指派的兩種應用程式
您可以使用兩種應用程式，其中一種用於佈建作業，另一種用於單一登入，藉此克服上述方法的一些缺點：
- 將 Google Workspace 應用程式的一個執行個體設定為僅處理佈建作業。 而不使用應用程式的單一登入功能。您可以將使用者指派給此應用程式，藉此控管要將哪些帳戶佈建到 Cloud Identity 或 Google Workspace。您可以啟用「Do not display application icon to users」(請勿向使用者顯示應用程式圖示) 選項，確保有效地在使用者端隱藏此應用程式。
- 將 Google Workspace 應用程式的其他執行個體設定為僅進行單一登入。您可以將使用者指派給此應用程式，藉此控管允許哪些使用者登入。
使用兩種應用程式按照下列方式指派使用者：
- 將最終需要存取 Google 服務的所有身分指派給單一登入應用程式。請一併指派現有消費者帳戶的身分，允許消費者帳戶身分使用單一登入。
將身分指派給佈建應用程式時，請納入最終需要存取 Google 服務的身分，但排除所有已知有現有消費者帳戶的身分。這樣一來，您就能防止系統為個人帳戶的身分自動佈建使用者帳戶。
每當使用者接受轉移要求時，請同時將使用者指派給應用程式。
連結 Okta：比較
下表是方法的摘要說明。
| 允許使用消費者帳戶的身分進行單一登入 | 禁止為具有消費者帳戶的身分自動佈建使用者帳戶 | 避免刪除外部 IdP 中沒有相符身分的已遷移帳戶 | 自動佈建新帳戶 | 自動更新已遷移帳戶 | |
|---|---|---|---|---|---|
| 方法 1：無須進行佈建作業 | ✅ | ✅ | ✅ | X | X |
| 方法 2：透過手動指派進行佈建 | X | 有風險 | ✅ | ✅ | ✅ |
| 方法 3：停止建立使用者來進行佈建 | ✅ | ✅ | ✅ | X | ✅ |
| 方法 4：採用手動指派的兩種應用程式 | ✅ | 有風險 | ✅ | ✅ | ✅ |
後續步驟
- 請參閱如何設定與 Active Directory 的同盟或Microsoft Entra ID。
- 首先請準備 Cloud Identity 或 Google Workspace 帳戶，然後開始啟用程序。