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

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

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

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

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

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

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

Использование источников идентификации повышает эффективность за счет разделения индексирования и сопоставления идентификаторов. Это позволяет откладывать поиск пользователей при создании списков контроля доступа (ACL) и индексировании элементов.

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

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

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

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

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

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

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

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

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

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

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

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

Пользователь	Электронная почта	id1_identity	id2_identity
Энн	[e-mail]	example\ann	1001

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

Написание списков контроля доступа пользователей (ACL)

Используйте getUserPrincipal() или 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 . Идентификатор Ann id1_identity преобразуется в identitysources/id1_identity/users/example/ann . Это промежуточный идентификатор пользователя.

Более подробную информацию о моделировании списков контроля доступа (ACL) репозитория см. в разделе ACL .

Группы карт

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

Используйте 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).

Используйте getGroupPrincipal() для создания группового субъекта с внешним идентификатором, а затем постройте список контроля доступа (ACL):

FilePermissionSample.java

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

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

Идентификационные коннекторы

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

• Обновите профили пользователей вручную в консоли администратора (рекомендуется только для тестирования).
• Сопоставление идентификаторов с использованием API каталога .
• Создайте коннектор идентификации с помощью Identity Connector SDK.

Соединители идентификации сопоставляют внешние идентификаторы из корпоративных систем с внутренними системами Google. При создании источника идентификации необходимо также создать соединитель идентификации.

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

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

Для синхронизации учетных записей используйте метод update .

Переназначение идентификаторов

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

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