本文介紹幾種常見的架構，可做為管理公司身分的參考。企業身分管理有兩項核心原則：
身分認證的可靠來源，也就是您用來為員工建立、管理及刪除身分的唯一系統。授權來源系統中管理的 ID 可能會傳播至其他系統。
中央身分識別提供者 (IdP) 是唯一的驗證系統，可為員工提供跨應用程式的單一登入體驗。
使用 Google Cloud 或其他 Google 服務時，您必須決定要將哪個系統做為身分識別提供者，以及要將哪個系統做為權威來源。
將 Google 設為 IdP
使用 Cloud Identity 進階版或 Google Workspace，即可將 Google 設為主要 IdP。Google 提供多種現成整合功能，適用於熱門的第三方應用程式。您也可以使用 SAML、OAuth 和 OpenID Connect 等標準通訊協定，整合自訂應用程式。
Google 做為 IdP 和授權來源
您可以將 Cloud Identity 進階版或 Google Workspace 同時做為 IdP 和授權來源，如下圖所示。
- 您使用 Cloud Identity 進階版或 Google Workspace 管理使用者和群組。
- 所有 Google 服務都使用 Cloud Identity 進階版或 Google Workspace 做為 IdP。
- 將企業應用程式和其他 SaaS 服務設定為使用 Google 做為 IdP。
使用者體驗
在這種設定中，員工的登入使用者體驗如下：
- 員工要求受保護的資源或存取公司應用程式時，系統會將他們重新導向至 Google 登入畫面，並提示他們輸入電子郵件地址和密碼。
- 如果啟用兩步驟驗證，系統會提示員工提供第二重驗證，例如 USB 金鑰或驗證碼。
- 員工通過驗證後，系統會將他們重新導向回受保護的資源。
優點
使用 Google 做為 IdP 和授權來源具有下列優點：
這個架構的使用時機
建議您在下列情況下使用 Google 做為 IdP 和授權來源：
- 您已使用 Google Workspace 做為協作和生產力解決方案。
- 您沒有現有的內部部署基礎架構或 IdP 需要整合，或是想將其與 Google 上的所有資源 (在 Google Cloud、Google Ads 等) 分開。 Google Cloud
- 您不需要與人力資源資訊系統 (HRIS) 整合，即可管理身分。
以 Google 做為 IdP，並以 HRIS 做為授權來源
如果您使用人力資源資訊系統 (HRIS) 管理員工的入職和離職程序，仍可將 Google 設為 IdP。Cloud Identity 和 Google Workspace 提供 API，可讓 HRIS 和其他系統控管使用者和群組的管理作業，如下圖所示。
- 您可以使用現有的人資資訊系統管理使用者和群組 (選用)。HRIS 仍是身分管理的單一可靠資料來源，並會自動為 Cloud Identity 或 Google Workspace 佈建使用者。
- 所有 Google 服務都使用 Cloud Identity 進階版或 Google Workspace 做為 IdP。
- 將企業應用程式和其他 SaaS 服務設定為使用 Google 做為 IdP。
使用者體驗
對員工而言，登入使用者體驗等同於使用 Google 做為 IdP 和授權來源。
優點
使用 Google 做為 IdP 和授權來源具有下列優點：
這個架構的使用時機
在下列情況下，建議您使用 Google 做為 IdP，並以 HRIS 做為權威來源：
- 您現有的 HRIS 或其他系統可做為身分識別的權威來源。
- 您已使用 Google Workspace 做為協作和生產力解決方案。
- 您沒有現有的內部部署基礎架構或 IdP，因此不必整合，也不想與 Google 資源保持區隔。
使用外部 IdP
如果貴機構已使用 IdP (例如 Active Directory、Azure AD、ForgeRock、Okta 或 Ping Identity)，則可透過聯盟整合 Google Cloud 這個外部 IdP。
將 Cloud Identity 或 Google Workspace 帳戶與外部 IdP 連結後，員工就能使用現有身分和憑證登入 Google 服務，例如 Google Cloud、Google Marketing Platform 和 Google Ads。
外部 IDaaS 做為 IdP 和授權來源
如果您使用身分即服務 (IDaaS) 提供者，例如 ForgeRock、Okta 或 Ping Identity，則可以按照下圖所示設定同盟。
- Cloud Identity 或 Google Workspace 會將您的 IDaaS 做為單一登入的 IdP。
- IDaaS 會自動為 Cloud Identity 或 Google Workspace 佈建使用者和群組。
- 現有的企業應用程式和其他 SaaS 服務可繼續將 IDaaS 做為 IdP。
如要進一步瞭解如何連結 Cloud Identity 或 Google Workspace 與 Okta，請參閱「Okta 使用者佈建和單一登入」。
使用者體驗
員工登入時會看到以下畫面：
- 員工要求存取受保護的資源時，系統會將他們重新導向至 Google 登入畫面，並提示輸入電子郵件地址。
- Google 登入會將您重新導向至 IDaaS 的登入頁面。
- 使用 IDaaS 進行驗證。視 IDaaS 而定，您可能需要提供第二重驗證因素，例如驗證碼。
- 驗證完成後，系統會將您重新導向回受保護的資源。
優點
使用外部 IDaaS 做為 IdP 和授權來源具有下列優點：
- 為員工啟用單一登入體驗，讓他們能存取 Google 服務，以及與 IDaaS 整合的其他應用程式。
- 如果您將 IDaaS 設為需要多重驗證，該設定會自動套用到 Google Cloud。
- 您不需要將密碼或其他憑證同步處理到 Google。
- 您可以使用 Cloud Identity 免費版。
這個架構的使用時機
在下列情況下，建議使用外部 IDaaS 做為 IdP 和授權來源：
- 您已使用 ForgeRock、Okta 或 Ping Identity 等 IDaaS 提供者做為 IdP。
最佳做法
請參閱連結外部身分識別資訊提供者的最佳做法 Google Cloud 。
將 Active Directory 設為 IdP 和授權來源
如果您使用 Active Directory 做為身分管理的單一可靠資料來源，可以按照下圖設定同盟。
- 您可以使用 Google Cloud Directory Sync (GCDS)，自動從 Active Directory 佈建使用者和群組，供 Cloud Identity 或 Google Workspace 使用。Google Cloud Directory Sync 是 Google 免費提供的工具，可實作同步處理程序，並在 Google Cloud 或內部部署環境中執行。同步處理是單向的，因此 Active Directory 仍是可靠來源。
- Cloud Identity 或 Google Workspace 使用 Active Directory 同盟服務 (AD FS) 進行單一登入。
- 現有的企業應用程式和其他 SaaS 服務可以繼續使用 AD FS 做為 IdP。
至於這種模式的變化形式，您也可以將 Active Directory Lightweight Directory Services (AD LDS) 或另外的 LDAP 目錄，與 AD FS 或其他符合 SAML 規範的 IdP 搭配使用。
如要進一步瞭解這個方法，請參閱「與 Active Directory 聯合 Google Cloud 」一文。
使用者體驗
- 要求受保護的資源時，員工會重新導向至 Google 登入畫面，並提示輸入電子郵件地址。
- Google 登入會將員工重新導向至 AD FS 的登入頁面。
- 根據 AD FS 的設定，登入畫面可能會提示員工輸入 Active Directory 使用者名稱和密碼。或者，AD FS 可能會嘗試根據員工的 Windows 登入資訊自動登入。
- AD FS 驗證員工身分後，系統會將他們重新導向回受保護的資源。
優點
使用 Active Directory 做為 IdP 和授權來源具有下列優點：
- 為員工啟用單一登入體驗，讓他們在 Google 服務和內部部署環境中都能使用。
- 如果您將 AD FS 設為需要多重驗證，該設定會自動套用到 Google Cloud。
- 您不需要將密碼或其他憑證同步處理到 Google。
- 您可以使用 Cloud Identity 免費版。
- GCDS 使用的 API 可公開存取，因此不需要在內部部署網路與 Google Cloud之間建立混合式連線。
這個架構的使用時機
建議您在下列情況下，將 Active Directory 做為 IdP 和授權來源：
- 您有現有的 Active Directory 基礎架構。
- 您希望為 Windows 使用者提供流暢的登入體驗。
最佳做法
請考慮以下最佳做法：
- Active Directory 和 Cloud Identity 使用不同的邏輯結構。請務必瞭解兩者的差異之處，並評估哪種對應網域、身分和群組的方法最適合您的情況。詳情請參閱連結 Active Directory 的指南 Google Cloud 。
- 除了同步處理使用者之外，也請同步處理群組。您可以透過這種方法來設定 IAM，以在 Active Directory 中使用群組成員資格，控管誰可以存取Google Cloud中的哪些資源。
- 部署並公開 AD FS，讓企業使用者可以存取這項服務，但公開程度請勿超過必要之範圍。雖然企業使用者必須能存取 AD FS，但不需要透過 Cloud Identity 或 Google Workspace，或部署在 Google Cloud上的任何應用程式來連線到 AD FS。
- 考慮在 AD FS 中啟用整合式 Windows 驗證 (IWA)，以允許使用者依據其 Windows 登入資訊自動登入。
- 如果 AD FS 無法使用，使用者可能無法使用Google Cloud 控制台或任何其他使用 Google 做為 IdP 的資源。因此，請務必部署 AD FS 和 AD FS 所依賴的網域控制站並調整規模，來滿足您的可用性目標。
如果您使用 Google Cloud 來確保業務持續性，那麼倚賴內部部署 AD FS 可能會破壞使用Google Cloud 做為獨立部署複本的本意。在這種情況下，請考慮在 Google Cloud上部署所有相關系統的備用資源，方法如下：
- 將現有 Active Directory 網域延伸至 Google Cloud ，並將 GCDS 部署到Google Cloud上執行。
- 在 Google Cloud上執行專用 AD FS 伺服器，這些伺服器使用在Google Cloud上執行的 Active Directory 網域控制站。
- 設定 Cloud Identity 使用部署在 Google Cloud 上的 AD FS 伺服器以進行單一登入。
詳情請參閱「連結外部身分識別提供者的最佳做法 Google Cloud 」。
Azure AD 做為 IdP，Active Directory 做為授權來源
如果您是 Microsoft Office 365 或 Azure 客戶，可能已將內部部署 Active Directory 連線至 Azure AD。如果所有可能需要存取 Google Cloud 的使用者帳戶都已同步處理至 Azure AD，您可以將 Cloud Identity 與 Azure AD 連結，重複使用這項整合功能，如下圖所示。
- 您可以使用 Azure AD，將使用者和群組自動佈建至 Cloud Identity 或 Google Workspace。Azure AD 本身可能與內部部署的 Active Directory 整合。
- Cloud Identity 或 Google Workspace 使用 Azure AD 進行單一登入。
- 現有的企業應用程式和其他 SaaS 服務可繼續使用 Azure AD 做為 IdP。
如要進一步瞭解這個方法，請參閱與 Azure Active Directory 聯合 Google Cloud 一文。
使用者體驗
- 員工要求存取受保護的資源時，系統會將他們重新導向至 Google 登入畫面，並提示輸入電子郵件地址。
- Google 登入會將他們重新導向至 AD FS 的登入頁面。
- 根據內部部署 Active Directory 連線到 Azure AD 的方式，Azure AD 可能會提示使用者輸入使用者名稱和密碼，或將他們重新導向至內部部署 AD FS。
- 員工通過 Azure AD 驗證後，系統會將他們重新導向回受保護的資源。
優點
以 Azure AD 做為 IdP，並以 Active Directory 做為授權來源，有以下幾項優點：
- 為員工啟用單一登入體驗，並將這項體驗擴展至 Google 服務、Azure 和內部部署環境。
- 如果您將 Azure AD 設為需要多重驗證，該設定會自動套用到 Google Cloud。
- 您不必安裝任何額外的內部部署軟體。
- 如果內部部署 Active Directory 使用多個網域或樹系，而您已設好自訂 Azure AD Connect 設定，將這個結構對應至 Azure AD 用戶群，則可以利用這項整合作業。
- 您不需要將密碼或其他憑證同步處理到 Google。
- 您可以使用 Cloud Identity 免費版。
- 您可以使用 Google Cloud 控制台做為 Office 365 入口網站的圖塊。
- Azure AD 使用的 API 可公開存取，因此不需要在 Azure 與 Google Cloud之間建立混合式連線。
這個架構的使用時機
在下列情況下，建議使用 Azure AD 做為 IdP，並以 Active Directory 做為授權來源：
- 您已使用 Azure AD，並將其與現有的 Active Directory 基礎架構整合。
- 您希望為 Azure 和 Google Cloud的使用者提供流暢的登入體驗。
最佳做法
請遵循以下最佳做法：
- Azure AD 和 Cloud Identity 使用不同的邏輯結構，因此請務必瞭解兩者的差異之處。請評估哪種對應網域、身分和群組的方法最適合您的情況。如需更多詳細資訊，請參閱「連結 Google Cloud Azure AD」。
- 除了同步處理使用者之外，也請同步處理群組。您可以透過這種方法來設定 IAM，以在 Azure AD 中使用群組成員資格來控制誰可以存取Google Cloud中的哪些資源。
- 如果您使用 Google Cloud 來確保業務持續性，那麼倚賴 Azure AD 進行驗證可能會破壞使用Google Cloud 做為獨立部署複本的本意。
詳情請參閱「連結外部身分識別提供者的最佳做法 Google Cloud 」。
後續步驟
- 進一步瞭解如何與 Active Directory 建立同盟。
- 瞭解如何設定與 Azure AD 的同盟。
- 請參閱規劃帳戶和機構的最佳做法，以及連結 Google Cloud 外部身分識別提供者的最佳做法。