Синхронизируйте различные системы идентификации

Контроль доступа в Google Cloud Search основан на учетной записи Google пользователя. При индексировании контента все списки ACL для элементов должны соответствовать действительным идентификаторам пользователей или групп Google (адресам электронной почты).

Во многих случаях репозиторий не имеет прямых сведений об учетных записях Google. Вместо этого пользователи могут быть представлены локальными учетными записями или использовать федеративный вход с поставщиком удостоверений и идентификатором, отличным от адреса электронной почты пользователя, для идентификации каждой учетной записи. Этот идентификатор называется внешним идентификатором .

Источники удостоверений , созданные с помощью консоли администратора, помогают устранить этот разрыв между системами идентификации за счет:

Используйте источники идентификации, если:

  • Репозиторию не известен основной адрес электронной почты пользователя в Google Workspace или Google Cloud Directory.
  • В репозитории определены группы для контроля доступа, которые не соответствуют группам на основе электронной почты в Google Workspace.

Источники удостоверений повышают эффективность индексации за счет отделения индексации от сопоставления удостоверений. Такое разделение позволяет отложить поиск пользователя при создании списков управления доступом и индексировании элементов.

Пример развертывания

На рис. 1 показан пример развертывания, в котором предприятие использует как локальные, так и облачные репозитории. Каждый репозиторий использует свой тип внешнего идентификатора для ссылки на пользователей.

Пример развертывания
Рисунок 1. Пример корпоративного развертывания с различными типами удостоверений.

Репозиторий 1 идентифицирует пользователя по адресу электронной почты, указанному с помощью SAML . Поскольку репозиторию 1 известен основной адрес электронной почты пользователя в Google Workspace или Cloud Directory, источник удостоверения не требуется.

Репозиторий 2 напрямую интегрируется с локальным каталогом и идентифицирует пользователя по атрибуту sAMAccountName . Поскольку репозиторий 2 использует атрибут sAMAccountName в качестве внешнего идентификатора, необходим источник удостоверений.

Создайте источник удостоверений

Если вам требуется источник удостоверений, см. раздел Сопоставление удостоверений пользователей в Cloud Search .

Перед созданием соединителя контента необходимо создать источник удостоверений, поскольку идентификатор источника удостоверений понадобится для создания списков управления доступом и индексирования данных. Как упоминалось ранее, при создании источника удостоверений также создается настраиваемое свойство пользователя в Cloud Directory. Используйте это свойство для записи внешнего идентификатора каждого пользователя в вашем репозитории. Свойство названо с использованием соглашения IDENTITY_SOURCE_ID _identity .

В следующей таблице показаны два источника удостоверений: один для хранения имен учетных записей SAM (sAMAccountName) в качестве внешних идентификаторов, а другой для хранения идентификаторов пользователей (uid) в качестве внешних идентификаторов.

Источник личности свойство пользователя внешний идентификатор
идентификатор1 id1_identity имя_самаккаунта
идентификатор2 id2_identity жидкость

Создайте источник идентификации для каждого возможного внешнего идентификатора, который используется для ссылки на пользователя на вашем предприятии.

В следующей таблице показано, как пользователь с учетной записью Google и двумя внешними идентификаторами (id1_identity и id2_identity) и их значения отображаются в Cloud Directory:

пользователь электронная почта id1_identity id2_identity
Энн ann@example.com пример\анн 1001

Вы можете ссылаться на одного и того же пользователя, используя три разных идентификатора (электронная почта Google, sAMAccountName и uid) при формировании списков ACL для индексации.

Запись пользовательских ACL

Используйте метод getUserPrincpal() или метод getGroupPrincipal() для создания участников с использованием предоставленного внешнего идентификатора.

В следующем примере показано, как получить права доступа к файлу. Эти разрешения включают имя каждого пользователя, имеющего доступ к файлу.

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

В следующем фрагменте кода показано, как создать участников-владельцев с использованием внешнего идентификатора ( 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 в качестве идентификатора при создании участников. Возвращаясь к предыдущим таблицам, если вы создадите ACL с id1_identity Анны (SAMAccountName), идентификатор будет разрешен:

identitysources/id1_identity/users/example/ann

Весь этот идентификатор называется промежуточным идентификатором пользователя, поскольку он обеспечивает мост между внешним идентификатором и идентификаторами Google, хранящимися в Cloud Directory.

Дополнительную информацию о моделировании списков 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() для создания участника группы с использованием предоставленного внешнего идентификатора. Затем создайте ACL, используя класс 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, для создания списков управления доступом и индексирования элементов, пользователи не смогут видеть элементы при поиске, пока их внешние идентификаторы не преобразуются в идентификатор Google в Cloud Directory. Существует три способа убедиться, что Cloud Directory знает как идентификатор Google, так и внешние идентификаторы пользователя:

  • Обновите каждый отдельный профиль пользователя вручную через консоль администратора. Этот процесс рекомендуется только для тестирования и создания прототипов с использованием нескольких профилей пользователей.
  • Сопоставьте внешние идентификаторы с идентификаторами Google с помощью Directory API . Этот процесс рекомендуется тем, кто не может использовать SDK Identity Connector.
  • Создайте соединитель удостоверений с помощью SDK Identity Connector . Этот SDK упрощает использование API каталога для сопоставления идентификаторов.

Соединители удостоверений – это программы, используемые для сопоставления внешних идентификаторов корпоративных удостоверений (пользователей и групп) с внутренними удостоверениями Google, используемыми Google Cloud Search. Если вам необходимо создать источник удостоверений, необходимо создать соединитель удостоверений.

Google Cloud Directory Sync (GCDS) — это пример соединителя удостоверений. Этот соединитель удостоверений сопоставляет информацию о пользователях и группах из Active Directory Microsoft в Cloud Directory вместе с атрибутами пользователя, которые могут представлять их личность в других системах.

Синхронизация удостоверений с помощью REST API

Используйте метод update для синхронизации удостоверений с помощью REST API.

Переназначение личностей

После переназначения идентификатора элемента на другой идентификатор необходимо переиндексировать элементы, чтобы новый идентификатор закрепился. Например,

  • если вы попытаетесь удалить сопоставление у пользователя или переназначить его другому пользователю, исходное сопоставление все равно сохранится до тех пор, пока вы не переиндексируете его.
  • Если вы удалите сопоставленную группу, которая присутствует в ACL элемента, а затем создадите новую группу с тем же groupKey , новая группа не предоставит доступ к элементу, пока элемент не будет переиндексирован.