外部身分

本文將說明如何使用外部身分識別資訊搭配 Identity-Aware Proxy (IAP),而非 Google 帳戶。

總覽

IAP 會控管應用程式和資源的存取權。這項服務會利用使用者身分和要求的內容,判斷是否應授予使用者存取權。IAP 是 Chrome Enterprise 進階版的構件,這項企業安全解決方案可讓員工在無需使用 VPN 的情況下,從不受信任的網路順利工作。

根據預設,IAP 會使用 Google 身分和 IAM。您可以改用 Identity Platform,透過多種外部身分識別資訊提供者驗證使用者,例如:

  • 電子郵件地址/密碼
  • OAuth (Google、Facebook、Twitter、GitHub、Microsoft 等)
  • SAML
  • OIDC
  • 電話號碼
  • 自訂
  • 匿名

如果應用程式已使用外部驗證系統,且將使用者遷移至 Google 帳戶不切實際,這項功能就很實用。

多用戶群架構

Identity Platform 多用戶群架構原本是為 B2B 情境而設計,也就是一家公司向其他公司銷售服務的情況。在這種情況下,開發人員通常會想要將使用者群體區隔為獨立的資源池。這些孤島稱為租戶

請參考下方虛構的關係圖:

多租戶階層

在這個範例中,Acme 是汽車製造商 (代理商),使用 Identity Platform 為經銷商 (租用戶) 提供服務。這些經銷商會向客戶、員工和承包商提供服務。雖然製造商擁有這項服務,但每家經銷商都可以使用自己的一組識別資訊提供者進行驗證。使用者工作階段和資料的範圍會依租用戶而定,因此如果使用者與多個經銷商有關係,每個關係都會個別處理。

視用途而定,您可以透過多種方式建構租用戶階層。

沒有租戶

只有在需要隔離資源時,才需要多租戶架構。並非所有應用程式都需要符合這項規定。舉例來說,如果您只有一個 App Engine 應用程式,且想封鎖網路外所有使用者的存取權,就不需要使用多租戶功能。根據預設,Identity Platform 會依專案個別儲存及驗證使用者,因此在這種情況下不需要額外設定。

另一個例子是擁有多個子公司的集團。即使每個子公司都有自己的受管理驗證系統 (使用 OIDC 或 SAML),所有員工可能都會享有相同的高階福利,例如醫療保健、休假和薪資。在這種情況下,只要在專案層級進行驗證即可。

每項資源一個租用戶

根據預設,非租戶 Identity Platform 權杖在專案層級有效。理論上,這表示使用者可以透過一個 IAP 資源進行驗證,然後使用憑證存取同一專案中的其他服務。這會造成安全性風險。

為避免權杖外洩,請為每個 IAP 指派專屬的租用戶,以便將各個 IAP 隔離。在租用戶專屬情境中鑄造的權杖,僅適用於該特定租用戶。如果使用者嘗試存取使用其他租用戶的其他 IAP 資源,系統會要求他們再次進行驗證。

每個資源有多個租用戶

單一 IAP 資源可以與多個租用戶建立關聯。

當使用者存取資源時,您可以透過多種方式決定要使用的租用戶。舉例來說,您可以先提示使用者輸入電子郵件地址,然後以程式輔助方式找出與電子郵件網域相符的租用戶。或者,您可以顯示列出所有有效租戶的 UI,並要求使用者選擇一個。

使用者可同時屬於多個租用戶,且存取權限各有不同。雖然您無法使用 IAM 管理外部身分的存取權控管,但 IAP 產生的 JSON Web Token 會攜帶 Identity Platform ID 權杖的宣告,應用程式可以根據這些宣告篩選存取權。

多租戶架構的例子是員工福利公司,他們有許多客戶共用單一網站入口網站。使用者造訪入口網站時,會先選取自己的公司 (租用戶),然後使用公司憑證,透過雇主使用的供應商進行驗證。

後續步驟