對應 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 (將存放區項目存取權授予使用者或群組，而非電子郵件地址) 來為項目建立索引，而非透過電子郵件地址。請使用 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 的間接允許主體；系統會沿用存取權，因為使用者 1 列為項目 A 的直接允許主體，而項目 B 繼承項目 A 的 ACL。
  • 使用者 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 繼承類型，且使用者有權存取子項，則雲端硬碟無需評估父項。但是，如果子項有 PARENT_OVERRIDE 或 BOTH_PERMIT，雲端硬碟會持續評估鏈結的上層項目。

遏制和刪除項目

為項目建立索引時，您可以使用 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。