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

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

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

在許多情況下,存放區不會直接掌握 Google 帳戶的相關資訊。反之,使用者可能會以本機帳戶表示,或使用身分識別登入和 ID (使用者電子郵件地址除外) 來代表每個帳戶。這個 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 中建立識別資訊來源也會建立自訂使用者屬性。使用這個屬性來記錄存放區中每位使用者的外部 ID。屬性使用慣例

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

使用 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。返回先前的資料表,如果您使用 Ann's id1_identity (SAMAccountName) 建立 ACL,ID 會解析為:

identitysources/id1_identity/users/example/ann

整個 ID 稱為使用者的中繼 ID,因為這個 ID 會在外部 ID 與儲存在 Cloud Directory 儲存的 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 類別建構 ACL,如下所示:

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 解析為 Cloud Directory 中的 Google ID,否則使用者不會看到搜尋中的項目。您可以透過三種方式,確保 Cloud Directory 能掌握使用者的 Google ID 和外部 ID:

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

Google Cloud Directory Sync (GCDS) 是身分連接器的範例。這個身分連接器會將使用者和群組資訊從 Microsoft' 的 Active Directory 對應至 Cloud Directory,以及可能在其他系統中代表的使用者屬性。

使用 REST API 同步處理身分

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

重新對應識別資訊

將項目的身分重新對應到其他身分後,您必須重新將項目重新編入索引,才能保留新身分。例如:

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