同步處理不同識別資訊系統

Google Cloud Search 的存取權控管取決於使用者的 Google 帳戶。 建立內容索引時,項目的所有 ACL 都必須解析為有效的 Google 使用者,或 群組 ID (電子郵件地址)。

在多數情況下,存放區對於 Google 帳戶。而是以本機帳戶代表使用者 透過識別資訊提供者和 ID 以及其他身分登入 而非使用者電子郵件地址,以便識別各個帳戶。這個 ID 稱為

您可以使用管理控制台建立識別資訊來源,藉此消弭落差 身分識別系統的優點:

如符合下列任一情況,請使用識別資訊來源:

  • 存放區不知道 登入 Google Workspace 或 Google Cloud Directory 時的使用者
  • 存放區定義了無法對應的存取權控管群組 再套用至 Google Workspace 中的電子郵件群組。

識別資訊來源分離索引來提高索引效率 來自識別資訊對應流程這樣分離,您就能延後查詢使用者 這部分需要在建立 ACL 和索引項目時啟用

部署範例

圖 1 顯示了內部部署和雲端的部署範例 存放區是由企業使用每個存放區都使用不同的類型 用來參照使用者的外部 ID

部署範例
圖 1. 含有不同 身分類型

存放區 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 建立主體的方法。

以下範例說明如何擷取檔案權限。這些 權限包含擁有檔案存取權的使用者名稱。

FilePermissionSample.java
/**
 * Sample for mapping permissions from a source repository to Cloud Search
 * ACLs. In this example, POSIX file permissions are used a the source
 * permissions.
 *
 * @return Acl
 * @throws IOException if unable to read file permissions
 */
static Acl mapPosixFilePermissionToCloudSearchAcl(Path pathToFile) throws IOException {
  // Id of the identity source for external user/group IDs. Shown here,
  // but may be omitted in the SDK as it is automatically applied
  // based on the `api.identitySourceId` configuration parameter.
  String identitySourceId = "abcdef12345";

  // Retrieve the file system permissions for the item being indexed.
  PosixFileAttributeView attributeView = Files.getFileAttributeView(
      pathToFile,
      PosixFileAttributeView.class,
      LinkOption.NOFOLLOW_LINKS);

  if (attributeView == null) {
    // Can't read, return empty ACl
    return new Acl.Builder().build();
  }

  PosixFileAttributes attrs = attributeView.readAttributes();
  // ...
}

下列程式碼片段說明如何建立具備擁有者身分的主體 使用儲存在屬性中的外部 ID (externalUserName)。

FilePermissionSample.java
// Owner, for search quality.
// Note that for principals the name is not the primary
// email address in Cloud Directory, but the local ID defined
// by the OS. Users and groups must be referred to by their
// external ID and mapped via an identity source.
List<Principal> owners = Collections.singletonList(
    Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId)
);

最後,下列程式碼片段顯示如何建立 檔案的讀取者

FilePermissionSample.java
// List of users to grant access to
List<Principal> readers = new ArrayList<>();

// Add owner, group, others to readers list if permissions
// exist. For this example, other is mapped to everyone
// in the organization.
Set<PosixFilePermission> permissions = attrs.permissions();
if (permissions.contains(PosixFilePermission.OWNER_READ)) {
  readers.add(Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId));
}
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}
if (permissions.contains(PosixFilePermission.OTHERS_READ)) {
  Principal everyone = Acl.getCustomerPrincipal();
  readers.add(everyone);
}

取得讀取者和擁有者清單後,即可建立 ACL:

FilePermissionSample.java
// Build the Cloud Search ACL. Note that inheritance of permissions
// from parents is omitted. See `setInheritFrom()` and `setInheritanceType()`
// methods on the builder if required by your implementation.
Acl acl = new Acl.Builder()
    .setReaders(readers)
    .setOwners(owners)
    .build();

基礎 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

CreateGroupCommand.java
String namespace = "identitysources/" + idSource;
Group group = new Group()
    .setGroupKey(new EntityKey().setNamespace(namespace).setId(groupId))
    .setDescription("Demo group")
    .setDisplayName(groupName)
    .setLabels(Collections.singletonMap("system/groups/external", ""))
    .setParent(namespace);
try {
  CloudIdentity service = Utils.buildCloudIdentityService();
  Operation createOperation = service.groups().create(group).execute();

  if (createOperation.getDone()) {
    // Note: The response contains the data for a Group object, but as
    // individual fields. To convert to a Group instance, either populate
    // the fields individually or serialize & deserialize to/from JSON.
    //
    // Example:
    // String json = service.getJsonFactory().toString(response);
    // Group createdGroup =  service.getObjectParser()
    //     .parseAndClose(new StringReader(json), Group.class);
    System.out.printf("Group: %s\n",
        createOperation.getResponse().toString());
  } else {
    // Handle case where operation not yet complete, poll for
    // completion. API is currently synchronous and all operations return
    // as completed.
    // ...
  }
} catch (Exception e) {
  System.err.printf("Unable to create group: %s", e.getMessage());
  e.printStackTrace(System.err);
}

建立群組 ACL

如要建立群組 ACL,請使用 getGroupPrincipal() 方法,使用提供的外部 ID 建立群組主體。接著建構 您可以使用 Acl.Builder 類別如下:

FilePermissionSample.java
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

識別資訊連接器

雖然可以使用外部的非 Google ID 建立 ACL 和索引項目, 使用者必須將外部 ID 解析為 Google Cloud Directory 中的 ID。有三種方式可以確保 Cloud Directory 知道使用者的 Google ID 和外部 ID:

識別資訊連接器是用於對應企業外部 ID 的程式 身分 (使用者和群組) 與 Google 所使用的內部 Google 身分 Cloud Search如需建立識別資訊來源,您必須 建立識別資訊連接器。

Google Cloud Directory Sync (GCDS) 已 識別資訊連接器範例。這個識別資訊連接器對應至使用者 將群組資訊從 Microsoft Active Directory 傳送至 Cloud Directory 在使用者屬性中,可能代表他們在其他系統中的身分。

使用 REST API 同步處理身分

使用 update 方法,透過 REST API 同步處理身分。

重新對應身分

將某個項目的身分重新對應至其他身分後,您必須為項目重新建立索引 以保留新的身分例如:

  • 當您嘗試移除使用者的對應關係,或將該對應關係重新對應至其他使用者時, 除非您重新建立索引,否則系統仍會保留原始對應關係。
  • 如果您刪除項目 ACL 中的對應群組,然後建立 具有相同「groupKey」的新群組,新群組不會提供使用者 項目,直到項目重新建立索引為止。