使用員工身分聯盟驗證 Looker (Google Cloud Core) 使用者

透過員工身分聯盟，您可以使用外部識別資訊提供者 (IdP) 驗證使用者和使用者群組，讓他們存取 Looker (Google Cloud Core) 執行個體。透過員工身分聯盟，貴組織的使用者可以透過單一登入 (SSO) 存取 Looker (Google Cloud Core)，您不必為每位使用者佈建或同步處理 Google 帳戶 (Cloud Identity 或 Google Workspace 帳戶)。

員工身分聯盟支援使用 OpenID Connect (OIDC) 或 SAML 2.0 的外部 IdP，例如 Microsoft Entra ID (舊稱 Azure AD)、Okta、PingIdentity 等。

功能預先發布期間，僅支援使用公開安全連線的 Looker (Google Cloud Core) 執行個體。

員工身分聯盟如何與 Looker (Google Cloud Core) 搭配運作

為 Looker (Google Cloud Core) 執行個體設定員工身分聯盟時，系統會執行下列程序：

  1. 驗證：使用者前往 Looker (Google Cloud Core) 執行個體網址。如果啟用「Bypass login page」(略過登入頁面) 設定，系統會自動將使用者重新導向至 Google Cloud 登入入口網站 (https://auth.cloud.google/authorize)，再將使用者重新導向至外部 IdP 進行驗證。
  2. 權杖交換：使用者透過 IdP 驗證後，IdP 會將驗證宣告傳回 Google Cloud Security Token Service (STS)。STS 會將斷言交換為聯合存取權杖和 ID 權杖。
  3. 授權：Looker (Google Cloud Core) 會驗證聯合主體是否具備執行個體的必要 Identity and Access Management (IAM) 權限 (looker.instances.login)。
  4. 佈建和角色指派：Looker (Google Cloud Core) 會在使用者首次登入時建立使用者帳戶 (JIT 即時建立帳戶)，並根據從 IdP 收到的宣告，套用群組對應角色和使用者屬性。

事前準備

為 Looker (Google Cloud Core) 設定員工身分聯盟前，請確認您具備下列角色和設定：

必要的 IAM 角色

如要設定 Workforce Identity Federation 並建立 Looker (Google Cloud Core) 執行個體，您必須具備下列角色：

必要 API

在 Google Cloud 專案中啟用下列 API：

步驟 1：設定員工身分集區和提供者

員工身分集區和提供者是在 Google Cloud組織層級建立，而非專案層級。

如要設定員工身分集區和提供者，請完成下列步驟：

  1. 按照「設定員工身分聯盟」說明文件頁面的指示，建立員工身分集區。
  2. 為 OIDC 或 SAML 2.0 IdP 建立員工身分集區提供者：
    • 如果是 OIDC 提供者，請參閱「設定 OIDC 員工身分聯盟」。
    • 如果是 SAML 提供者，請參閱「設定 SAML 2.0 員工身分聯盟」。
    • 在建立供應商時，請立即定義下列屬性對應：
      • 電子郵件：將 IdP 的電子郵件宣告對應至 google.email。這項對應是識別使用者必要的資訊，如果缺少這項對應，驗證就會失敗。
      • 姓名：將 IdP 的名字和姓氏聲明對應至 attribute.given_name (名字) 和 attribute.family_name (姓氏)。這些對應必須存在，才能填入 Looker 使用者個人資料；如果缺少這些對應，驗證就會失敗。

  3. 您也可以視需要設定下列屬性對應：

    • 群組：將 IdP 的群組要求 (例如 assertion.groups) 對應至 google.groups。如果您打算啟用群組鏡像功能，並將 IdP 群組對應至 Looker 角色，就必須進行這項對應。如果是 OIDC 提供者，請確保提供者設定也要求 groups 範圍 (如果 IdP 需要) (請參閱「設定員工身分聯盟」瞭解 IdP 特定需求)。
    • 自訂屬性：將自訂 IdP 聲明對應至 attribute.<attribute_name>。您可以在 Looker (Google Cloud Core) 中使用這些對應屬性，將資料庫連線參數化，並套用資料列層級的資料存取權篩選器。

設定延長工作階段長度和背景同步功能

如要支援不中斷的瀏覽器工作階段、長時間執行的排定傳送作業、使用者 API 金鑰存取權，以及連接器整合，請完成下列步驟：

  1. 在工作團隊集區提供者上設定背景屬性同步處理，讓 Google Cloud 定期在背景重新整理使用者屬性和群組成員資格：
    • OIDC 提供者：使用 offline_access 範圍設定 OIDC 授權碼流程 (使用更新權杖定期更新使用者屬性和群組成員資格)，或設定 SCIM 2.0 佈建。如果使用者所屬的群組數量過多，超過 OIDC 權杖大小限制，請設定 SCIM 2.0 佈建，將群組成員資格同步至 Google Cloud。
    • 如果是 SAML 提供者：在工作團隊集區提供者上設定 SCIM 2.0 佈建。由於 SAML 斷言本身不提供更新權杖，因此必須使用 SCIM 2.0，才能啟用離線排程傳送和快訊。

  2. 使用 Access Context Manager 雲端繫結，為員工集區設定延長工作階段長度政策，並將政策設為 90 天 (7,776,000 秒)。

    這項政策會將工作階段持續時間上限和更新權杖效期設為 90 天。如果未設定延長工作階段長度政策，或設定的時間較短，則工作團隊集區更新權杖的效期會優先於 Looker 的工作階段持續時間設定，導致瀏覽器工作階段、離線排程、使用者 API 金鑰和連結的應用程式在更新權杖到期時，需要重新驗證。

步驟 2：將 IAM 權限授予工作團隊主體

如要允許工作團隊使用者登入 Looker (Google Cloud Core) 執行個體，請將 Looker 執行個體使用者 (roles/looker.instanceUser) 或 Looker 管理員 (roles/looker.admin) IAM 角色授予工作團隊主體或群組。

您可以使用下列主體 ID，將角色授予個別使用者、整個群組或工作團隊集區中的所有主體：

  • 單一工作團隊使用者： 

    principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_ID

  • 工作團隊群組： 

    principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID

  • 工作團隊集區中的所有主體： 

    principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/*

如要進一步瞭解如何指派 IAM 角色，請參閱「 使用 IAM 控管 Looker (Google Cloud Core) 存取權」說明文件頁面。

步驟 3：選取 Workforce Identity Federation 做為主要驗證方式

建立新的 Looker (Google Cloud Core) 執行個體或編輯現有執行個體時，您可以選取員工身分聯盟做為主要驗證方式。

建立執行個體期間

建立新的 Looker (Google Cloud Core) 執行個體時，您可以選取員工身分聯盟做為主要驗證方式：

主控台

  1. 前往 Google Cloud 控制台的「Looker (Google Cloud core)」頁面。

    前往「Looker (Google Cloud Core)」

  2. 點選「建立執行個體」。
  3. 如需如何完成執行個體名稱、區域和版本設定，請參閱這篇說明文件，瞭解如何建立使用Private Service Connect 連線或私人服務存取連線的執行個體。
  4. 在「驗證」部分，選取「員工身分聯盟 (SAML/OIDC)」做為主要驗證方式。
  5. 點選「建立」。

如要將 OAuth 設為次要驗證方式，請在建立執行個體後編輯執行個體設定。

編輯現有執行個體時

如果您已有 Looker (Google Cloud Core) 執行個體，可以編輯執行個體設定，選取員工身分聯盟做為主要驗證方式，或將 OAuth 設為次要驗證方式：

主控台

  1. 在 Google Cloud 控制台中，前往「Looker (Google Cloud core)」頁面。

    前往 Looker (Google Cloud Core)

  2. 按一下要編輯的執行個體名稱。
  3. 在執行個體的「Details」(詳細資料) 分頁中，按一下「Edit」(編輯)。
  4. 在「Authentication」(驗證) 部分，選取「Workforce Identity Federation (SAML/OIDC)」(員工身分聯盟 (SAML/OIDC)) 做為主要驗證方式。
  5. (選用) 如要允許 OAuth 做為次要驗證方式，請啟用「Enable Secondary OAuth」(啟用次要 OAuth) 切換鈕。
  6. 按一下 [儲存]。

步驟 4：在 Looker 設定員工身分

建立 Looker (Google Cloud Core) 執行個體後，管理員可以在 Looker 管理面板的「Workforce authentication」(員工身分驗證) 頁面中，設定使用者屬性對應、群組鏡像和登入選項。

  1. 使用具備管理員 Looker 角色的帳戶，登入 Looker (Google Cloud Core) 執行個體。
  2. 在左側導覽選單中，依序選取「Admin」(管理) >「Authentication」(驗證) >「Workforce Identity」(員工身分)。
  3. 請按照下列各節說明進行設定。

如要進一步瞭解下列設定，請參閱員工驗證頁面說明文件。

合併使用者帳戶

在「使用以下項目合併使用者」欄位中，選取使用者首次透過員工身分聯盟登入時，要合併現有使用者帳戶的驗證系統。

支援合併的系統包括：

  • Google
  • SAML
  • OIDC

略過登入頁面

「略過登入頁面」選項可控管未經驗證的使用者是否會自動重新導向至企業單一登入 (SSO) 入口網站：

  • 已啟用 (預設)：使用者前往執行個體網址時，系統會自動將他們重新導向至 IdP 登入畫面，不會顯示 Looker 登入頁面。
  • 停用：使用者會看到 Looker 登入頁面，並可選擇可用的驗證選項。

按一下「儲存設定」套用設定。

使用者屬性對應

將 IdP 聲明中的聲明對應至 Looker 使用者屬性。 使用者屬性有多種用途，例如參數化資料庫連線，以及套用資料列層級安全性篩選器。

  • 在「Attribute Mapping」(屬性對應) 部分，將 Google 員工屬性對應至相應的 Looker 使用者屬性 (例如將 attribute.department 對應至 Looker 中的 department 使用者屬性)。

群組和角色

您可以透過群組鏡像或預設角色指派管理使用者角色：

  • 從 IdP 鏡像群組：啟用這項設定後，Looker (Google Cloud Core) 會建立 Looker 群組，鏡像 IdP 權杖斷言中傳遞的群組。
    • 在「群組對應」表格中，將外部 IdP 群組名稱對應至 Looker 群組，並指派適當的 Looker 角色 (例如檢視者、使用者或開發人員)。
  • 預設新使用者角色：如果未使用群組鏡像功能，或使用者不符合條件，請指定新使用者首次登入時授予的預設角色。
  • 預設新使用者群組：如果未使用群組鏡像功能，或該功能與使用者不符，請指定要指派給新使用者的預設群組。

工作階段管理和權杖效期

Looker (Google Cloud Core) 中的使用者工作階段和權杖，受員工身分集區政策中設定的工作階段時間長度和重新整理權杖效期規範 (例如延長工作階段時間長度政策)：

  • 瀏覽器工作階段：使用持續性工作階段時，Looker 工作階段持續時間設定最多可支援 30 天的工作階段。不過，如果工作團隊身分集區的更新權杖效期，短於 Looker 中設定的工作階段持續時間，則以工作團隊身分集區的更新權杖效期為準。如果更新權杖過期，使用者必須重新登入。建議您在延長工作階段長度政策中，將更新權杖效期設為 90 天。
  • 排定傳送和快訊 (離線工作)：只要排程擁有者具備有效的 IdP 權杖，背景工作就會執行。如果排程或快訊建立者超過 90 天未登入執行個體 (或您在工作人員集區工作階段政策中設定的時長)，系統就會讓他們的離線工作階段過期，並暫停該使用者擁有的排定傳送作業或快訊。如要繼續執行已暫停的排程或快訊，擁有者必須登入執行個體，或由管理員指派排程擁有權。
  • Looker OAuth 伺服器和連接器：使用 Looker OAuth 伺服器的整合服務 (例如數據分析、連結試算表和第三方連接器) 會使用 30 天的更新權杖 (或數據分析中不會過期的更新權杖)。如果工作人員集區工作階段的持續時間設為少於 90 天，工作階段持續時間到期時，使用者可能需要重新向 Looker 驗證。
  • 使用者 API 金鑰：由使用者 API 金鑰產生的 API 存取權杖有效期限為 1 小時，且需要有效的使用者 IdP 工作階段。如果使用者的 IdP 工作階段過期 (每 90 天或根據員工集區工作階段時間長度)，使用者必須重新登入執行個體，才能繼續使用 API 金鑰。
  • 服務帳戶 API 金鑰：服務帳戶 API 存取權杖不受工作人員集區工作階段政策影響。

後續步驟