Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

Определение настраиваемого поля пользователя для хранения внешних идентификаторов. Поле используется для сопоставления внешних идентификаторов с учётной записью Google.
Определите пространство имен для групп безопасности, управляемых репозиторием или поставщиком удостоверений .

Используйте источники идентификации в следующих случаях:

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

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

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

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

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

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

Создать источник идентификации

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

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

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

Источник идентичности	свойство пользователя	внешний идентификатор
идентификатор1	id1_identity	sAMAccountName
id2	id2_identity	uid

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

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

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

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

Запись списков контроля доступа пользователей

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

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

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

identitysources/id1_identity/users/example/ann

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

Дополнительную информацию о моделировании списков ACL, используемых для репозитория, см. в разделе ACL .

Группы карт

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

Используйте API Cloud Identity Groups для создания группы и управления её членством. Чтобы связать группу с источником удостоверений, используйте имя ресурса источника удостоверений в качестве пространства имён группы.

В следующем фрагменте кода показано, как создать группу с помощью API Cloud Identity Groups :

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

Чтобы создать групповой список контроля доступа (ACL), используйте метод getGroupPrincipal() для создания принципала группы с использованием предоставленного внешнего идентификатора. Затем создайте ACL с помощью класса Acl.Builder следующим образом:

FilePermissionSample.java

Посмотреть на GitHub

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

Соединители идентичности

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

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

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

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

Синхронизация идентификационных данных с использованием REST API

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

Переосмысление идентичностей

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

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

Синхронизируйте различные системы идентификации Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

Создать источник идентификации

Запись списков контроля доступа пользователей

Группы карт

Создать групповой ACL

Соединители идентичности

Синхронизация идентификационных данных с использованием REST API

Переосмысление идентичностей

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