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

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

在許多情況下，存放區不會直接瞭解 Google 帳戶。而是代表使用者，或使用者透過身分識別提供者進行同盟登入。電子郵件地址以外的這類識別資訊稱為外部 ID。

透過管理控制台建立的識別資訊來源可彌合身分識別系統之間的差距，方法如下：

定義自訂使用者欄位，用於儲存外部 ID。這個欄位會將外部 ID 解析為 Google 帳戶。
為存放區或身分識別提供者管理的安全性群組定義命名空間。

在下列情況下使用身分識別來源：

存放區不知道使用者在 Google Workspace 或 Google Cloud Directory 中的主要電子郵件地址。
存放區定義的存取權控管群組，與 Google Workspace 中以電子郵件為依據的群組不符。

識別資訊來源可將索引編製與身分對應作業分離，進而提升效率。這樣您就能在建立 ACL 和為項目建立索引時，延後使用者查詢作業。

部署範例

圖 1 顯示企業同時使用地端和雲端存放區。兩者使用的外部 ID 類型不同。

存放區 1 會使用 SAML 依電子郵件地址識別使用者。由於這項服務知道 Google Workspace 或 Cloud Directory 中的主要電子郵件地址，因此不需要身分來源。

存放區 2 會與地端目錄整合，並透過 sAMAccountName 識別使用者。由於系統會將這個屬性做為外部 ID，因此需要身分識別來源。

建立識別資訊來源

如需識別資訊來源，請參閱「在 Cloud Search 中對應使用者識別資訊」。

請先建立身分來源，再建立內容連線器；您需要身分來源 ID 才能建立存取控制清單和索引資料。建立身分來源時，系統也會在 Cloud Directory 中建立自訂使用者屬性，用來儲存外部 ID。屬性名稱採用 IDENTITY_SOURCE_ID_identity 慣例。

下表顯示兩個身分來源：一個用於 SAM 帳戶名稱，另一個用於使用者 ID (uid)。

識別資訊來源	使用者屬性	外部 ID
`id1`	`id1_identity`	`sAMAccountName`
`id2`	`id2_identity`	`uid`

為企業使用的每種外部 ID 建立身分來源。

下表顯示在 Cloud Directory 中，擁有 Google 帳戶和兩個外部 ID 的使用者：

使用者	電子郵件	`id1_identity`	`id2_identity`
小安	`ann@example.com`	`example\ann`	`1001`

為建立索引的 ACL 時，您可以使用任一 ID 參照同一位使用者。

寫入使用者 ACL

使用 getUserPrincipal() 或 getGroupPrincipal() ，透過外部 ID 建立主體。

這個範例會擷取檔案權限，包括有權存取的使用者：

FilePermissionSample.java

前往 GitHub 查看

/**
 * 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();
  // ...
}

這個程式碼片段會使用 externalUserName 屬性為擁有者建立主體：

FilePermissionSample.java

前往 GitHub 查看

// 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

前往 GitHub 查看

// 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

前往 GitHub 查看

// 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。安安的 id1_identity 會解析為 identitysources/id1_identity/users/example/ann。這是使用者的中繼 ID。

如要進一步瞭解如何建立存放區 ACL 模型，請參閱「ACL」。

地圖群組

身分來源也會做為存取控管清單 (ACL) 群組的命名空間。您可以使用這個選項建立及對應僅用於安全或本機的群組，或對應至存放區。

使用 Cloud Identity Groups API 建立群組及管理成員。使用身分來源名稱做為命名空間，將群組與身分來源建立關聯。

這個程式碼片段會建立群組：

CreateGroupCommand.java

前往 GitHub 查看

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

使用 getGroupPrincipal() 建立具有外部 ID 的群組主體，然後建構 ACL：

FilePermissionSample.java

前往 GitHub 查看

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

身分連接器

外部 ID 解析為雲端目錄中的 Google ID 後，使用者才能在搜尋結果中看到項目。您可以透過下列三種方式確保這點：

在管理控制台中手動更新使用者設定檔 (僅建議用於測試)。
使用 Directory API 對應地圖 ID。
使用 Identity Connector SDK 建立身分識別連接器。

身分連結器會將企業身分中的外部 ID 對應至內部 Google 身分。如果您建立識別資訊來源，也必須建立識別資訊連接器。

Google Cloud Directory Sync (GCDS) 就是識別資訊連接器。並將 Active Directory 中的使用者和群組資訊對應至 Cloud Directory。

使用 REST API 同步處理身分

使用 update 方法同步處理身分。

重新對應身分

重新對應身分後，您必須重新為項目建立索引，變更才會生效。

如果移除或變更使用者對應，原始對應會保留到重新建立索引為止。
如果您刪除對應的群組，並建立具有相同 groupKey 的新群組，則必須重新建立索引，才能授予存取權。

同步處理不同識別資訊系統 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

部署範例

建立識別資訊來源

寫入使用者 ACL

地圖群組

建立群組 ACL

身分連接器

使用 REST API 同步處理身分

重新對應身分

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