對應 ACL

為確保只有具備存取權的使用者能在搜尋結果中看到項目，您應從企業存放區為項目建立存取控制清單 (ACL) 索引。您必須為存放區的 ACL 建立模型，並在為存放區中的項目建立索引時加入這些 ACL。Content Connector SDK 提供豐富的 ACL 方法，足以模擬大多數存放區的 ACL。

建立 ACL

建立 ACL 的程序包含兩個步驟：

  1. 使用 ACL 類別中的靜態方法建立 Principal。
  2. 使用 Acl.Builder 類別，透過主體建構 ACL。

本文其餘內容將介紹一些您需要瞭解的概念，以便建立 ACL 模型，例如繼承和包含。

使用外部 ID 建立主體

Google Cloud Search 必須將使用者和群組解析為 Google 電子郵件地址。建立存放區項目的索引時，內容連接器可能沒有這些電子郵件地址。不過，Content Connector SDK 允許您使用任何外部 ID (授予使用者或群組資源庫項目存取權的 ID) 建立項目索引，而非電子郵件地址。使用 getUserPrincipal() 方法或 getGroupPrincpal() 方法建立含有外部 ID 的主體。ACL 類別中還有其他靜態方法，可用於建構 Principal 物件。

ACL 繼承

ACL 繼承是指根據項目 ACL 和繼承鏈 ACL 的組合結果，為特定項目和特定使用者授予授權。用來做出授權決策的規則取決於存放區和項目的屬性。

設定繼承

每個項目都可以有直接允許的主體和直接拒絕的主體，使用 setReaders() 和 setDeniedReaders() 方法指定。直接允許的主體是指 ACL 中識別的使用者，可直接存取特定項目。直接遭拒的主體是指 ACL 中識別為無權存取特定項目的使用者。

項目也可以使用 setInheritFrom() 方法，繼承間接允許的主體和間接拒絕的主體。間接允許的主體是指透過 ACL 沿用機制，間接存取特定項目的使用者。間接遭拒的主體是指透過 ACL 繼承，遭拒存取特定項目的使用者。

圖 1 顯示如何使用 setInheritFrom() 方法，繼承間接允許和間接拒絕的主體。

繪製項目之間的連結
圖 1. setInheritFrom() 方法。

圖 1 顯示這些存取控制項：

  • 使用者 1 是項目 A 的直接允許主體。
  • 使用者 2 是項目 B 的直接允許主體。
  • 項目 B 會沿用項目 A 的 ACL。

根據存取權控管，存取規則如下：

  • 使用者 1 不必明確指定為項目 B 的主體，即可成為項目 B 的間接允許主體；這是因為使用者 1 列為項目 A 的直接允許主體，而項目 B 會從項目 A 繼承 ACL，因此使用者 1 會繼承存取權。
  • 使用者 2 不是項目 A 的間接允許主體。

設定繼承類型

如果您使用 setInheritFrom() 方法設定繼承，則必須使用 setInheritanceType() 方法設定繼承類型。繼承類型會決定子項的 ACL 如何與父項的 ACL 合併。Acl.InheritanceType 實作三種繼承類型：

  • BOTH_PERMIT：將繼承類型設為 BOTH_PERMIT，只有在子項目的 ACL 和父項目的繼承項目 ACL 都允許使用者存取該項目時，才授予使用者存取權。

  • CHILD_OVERRIDE - 將沿用類型設為 CHILD_OVERRIDE，強制子項目的 ACL 優先於沿用的父項目 ACL (發生衝突時)。因此，如果父項目的 ACL 拒絕使用者以讀取者身分存取，但使用者有權以讀取者身分存取子項目，則仍可存取。反之，即使父項的 ACL 授予使用者存取權，如果使用者是子項的遭拒讀取者，就無法存取子項。

  • PARENT_OVERRIDE - 將繼承類型設為 PARENT_OVERRIDE，強制讓父項目的 ACL 優先於子項目的 ACL (如果兩者衝突)。因此，如果子項目的 ACL 拒絕使用者以讀取者身分存取，但使用者有權以讀取者身分存取父項目，則仍可存取子項目。反之，即使子項目的 ACL 授予使用者存取權，如果使用者是父項目的遭拒讀取者，也無法存取子項目。

評估 ACL 繼承鏈時，評估順序可能會改變授權決策的結果。Cloud Search 會依從葉節點到根節點的順序，評估 ACL 繼承鏈。具體來說，鏈結的 ACL 決策會從評估子項及其父項開始，並一路進展到根父項。

舉例來說，如果子項具有 CHILD_OVERRIDE 繼承類型，且使用者有權存取子項，則 Google 雲端硬碟不需要評估父項。不過，如果孩子擁有 PARENT_OVERRIDE 或 BOTH_PERMIT，Google 雲端硬碟會繼續評估鏈結中更上層的繼承權。

隔離和刪除項目

為項目建立索引時，您可以使用 IndexingItemBuilder 類別的 setContainer() 方法，將項目標示為容器。容器/被含物件關係會建立項目的實體階層，並確保項目能正確刪除。刪除容器時，系統也會一併刪除容器中的項目。

包含關係完全獨立於 ACL 繼承規則。 舉例來說，檔案系統中的檔案可以包含在資料夾中以利刪除，但會從其他資料夾繼承 ACL。刪除資料夾不會刪除繼承其 ACL 的項目，除非這些項目也位於該資料夾的包含階層中。

圖 2 顯示這些存取控制項：

  • 使用者 1 是項目 A 的直接允許主體。
  • 使用者 2 是項目 B 的直接允許主體。
  • 使用者 3 是項目 C 的直接允許主體。
  • 項目 C 會沿用項目 A 的 ACL。
  • 項目 B 將項目 A 命名為容器。
  • 項目 C 將項目 B 命名為容器。

根據存取權控管，存取規則如下：

  • 間接存取來自 setInheritFrom() 方法。因此，使用者 1 可以存取項目 C，因為項目 C 繼承了項目 A 的 ACL。
  • 間接存取「不」來自項目 B 包含項目 C。因此使用者 2 無法存取項目 C。
繪製項目之間的連結
圖 2. 使用的 setInheritFrom() 方法。

將 ACL 繼承與容器階層分開，可讓您模擬許多不同的現有結構。

成功刪除項目後：

  • 如果項目包含已刪除的項目，就會無法搜尋，並排定從 Google 的資料來源中刪除。
  • 使用 setInheritFrom() 方法指定刪除項目後，該項目就無法再搜尋。

如果資源使用 setInheritFrom() 方法刪除項目，但未透過 setContainer() 設定容器，或其包含階層不含任何已刪除的項目，該項目及其資料仍會保留在 Google 的資料來源中。您必須負責刪除該項目。

圖 3 顯示項目階層的刪除作業範例。

繪製項目之間的連結
圖 3. 刪除項目和 ACL 繼承。

圖 3 顯示這些存取控制項：

  • 使用者 1 是項目 A 的直接允許主體。
  • 使用者 2 是項目 D 的直接允許主體。
  • 項目 D 和項目 E 都會沿用項目 A 的 ACL。
  • 項目 D 將項目 A 命名為容器。
  • 項目 A 和 E 是根層級項目，因為沒有容器項目。

系統會透過容器參照，以連鎖方式刪除項目。刪除項目 A 時：

  • 所有使用者都無法存取 setInheritFrom() 參照的所有子項。
  • 任何使用者都無法存取項目 A。
  • 項目 D 會隱含刪除。沒有任何使用者可以存取項目 D。
  • 項目 E 不會刪除，因為刪除作業只會透過容器參照層疊。
  • 項目 E 無法存取，使用者也無法搜尋項目 E。