Google Cloud Search 的存取權控管取決於使用者的 Google 帳戶。 建立內容索引時,項目的所有 ACL 都必須解析為有效的 Google 使用者,或 群組 ID (電子郵件地址)。
在多數情況下,存放區對於 Google 帳戶。而是以本機帳戶代表使用者 透過識別資訊提供者和 ID 以及其他身分登入 而非使用者電子郵件地址,以便識別各個帳戶。這個 ID 稱為 。
您可以使用管理控制台建立識別資訊來源,藉此消弭落差 身分識別系統的優點:
- 定義自訂使用者欄位 儲存外部 ID這個欄位是用來將外部 ID 解析為 Google 讓他們使用服務帳戶
- 定義安全性群組的命名空間 由存放區管理 識別資訊提供者
如符合下列任一情況,請使用識別資訊來源:
- 存放區不知道 登入 Google Workspace 或 Google Cloud Directory 時的使用者
- 存放區定義了無法對應的存取權控管群組 再套用至 Google Workspace 中的電子郵件群組。
識別資訊來源分離索引來提高索引效率 來自識別資訊對應流程這樣分離,您就能延後查詢使用者 這部分需要在建立 ACL 和索引項目時啟用
部署範例
圖 1 顯示了內部部署和雲端的部署範例 存放區是由企業使用每個存放區都使用不同的類型 用來參照使用者的外部 ID
![部署範例](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/identity-arch.png?authuser=6&hl=zh-tw)
存放區 1 使用所宣告的電子郵件地址識別使用者 SAML。由於 存放區 1 知道 Google Workspace 或 Cloud Directory (不需要識別資訊來源)。
存放區 2 直接與地端部署目錄整合
透過 sAMAccountName
屬性識別使用者。因為存放區 2
使用 sAMAccountName
屬性做為外部 ID,識別資訊來源則是
。
建立識別資訊來源
如果您需要識別資訊來源,請參閱「在 Cloud Search 中對應使用者身分」一文。
您必須先建立識別資訊來源,才能建立內容連接器,原因如下:
您需要識別資訊來源 ID,才能建立 ACL 和索引資料。如先前所述
先前建立識別資訊來源時,也會
自訂使用者屬性
複製到 Cloud Directory 中請使用這個屬性記錄各個
存放區中的使用者屬性採用
慣例 IDENTITY_SOURCE_ID_identity
。
下表顯示兩個識別資訊來源,一個用於保存 SAM 帳戶名稱 (sAMAccountName) 做為外部 ID,另一個則用於將使用者 ID (uid) 做為外部 ID。
識別資訊來源 | 使用者屬性 | 外部 ID |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
請為每個可能用到的外部 ID 建立識別資訊來源 代表企業中的一個使用者
下表顯示一個 Google 帳戶和兩個外部 ID 的使用者 (id1_identity 和 id2_identity) 及其值出現在 Cloud Directory 中:
使用者 | 電子郵件 | id1_identity | id2_identity |
---|---|---|---|
小安 | ann@example.com | 範例\ann | 1001 |
您可以使用三種不同的 ID 來參照同一位使用者 (Google 電子郵件、sAMAccountName 和 uid) 建立索引的 ACL。
寫入使用者 ACL
使用 getUserPrincpal() 方法,或 getGroupPrincipal() 使用提供的外部 ID 建立主體的方法。
以下範例說明如何擷取檔案權限。這些 權限包含擁有檔案存取權的使用者名稱。
下列程式碼片段說明如何建立具備擁有者身分的主體
使用儲存在屬性中的外部 ID (externalUserName
)。
最後,下列程式碼片段顯示如何建立 檔案的讀取者
取得讀取者和擁有者清單後,即可建立 ACL:
基礎 REST API 會使用模式
identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
為 ID 和 ID回顧先前的表格
如果您使用 Ann 的 id1_identity
(SAMAccountName) 建立 ACL,則 ID 會
會解析為:
identitysources/id1_identity/users/example/ann
整個 ID 稱為使用者的中繼 ID 因為這樣可以連結外部 ID 和儲存的 Google ID 取得相關協助
如要進一步瞭解如何建立用於存放區的 ACL 模型,請參閱 ACL。
對應群組
識別資訊來源也可以做為 ACL 中使用的群組的命名空間。你可以 請使用這項命名空間功能,建立和對應用於確保安全的群組 僅供存放區使用,或屬於存放區本機。
使用 Cloud Identity Groups API 建立群組並管理成員。如要將群組與 識別資訊來源,請使用識別資訊來源資源名稱做為群組命名空間。
下列程式碼片段顯示如何使用 Cloud Identity Groups API:
建立群組 ACL
如要建立群組 ACL,請使用 getGroupPrincipal() 方法,使用提供的外部 ID 建立群組主體。接著建構 您可以使用 Acl.Builder 類別如下:
識別資訊連接器
雖然可以使用外部的非 Google ID 建立 ACL 和索引項目, 使用者必須將外部 ID 解析為 Google Cloud Directory 中的 ID。有三種方式可以確保 Cloud Directory 知道使用者的 Google ID 和外部 ID:
- 透過管理控制台手動更新個別使用者設定檔 這項程序僅建議用於使用少數使用者個人資料進行測試和原型設計。
- 使用 Directory API 將外部 ID 對應至 Google ID。 我們建議使用 Identity Connector SDK 的使用者完成這項程序。
- 建立識別資訊連接器 方法是使用 Identity Connector SDK。 這個 SDK 簡化了使用 Directory API 對應 ID 的過程。
識別資訊連接器是用於對應企業外部 ID 的程式 身分 (使用者和群組) 與 Google 所使用的內部 Google 身分 Cloud Search如需建立識別資訊來源,您必須 建立識別資訊連接器。
Google Cloud Directory Sync (GCDS) 已 識別資訊連接器範例。這個識別資訊連接器對應至使用者 將群組資訊從 Microsoft Active Directory 傳送至 Cloud Directory 在使用者屬性中,可能代表他們在其他系統中的身分。
使用 REST API 同步處理身分
使用 update
方法,透過 REST API 同步處理身分。
重新對應身分
將某個項目的身分重新對應至其他身分後,您必須為項目重新建立索引 以保留新的身分例如:
- 當您嘗試移除使用者的對應關係,或將該對應關係重新對應至其他使用者時, 除非您重新建立索引,否則系統仍會保留原始對應關係。
- 如果您刪除項目 ACL 中的對應群組,然後建立
具有相同「
groupKey
」的新群組,新群組不會提供使用者 項目,直到項目重新建立索引為止。