Контроль доступа в Google Cloud Search основан на учетной записи Google пользователя. При индексировании контента все списки ACL для элементов должны соответствовать действительным идентификаторам пользователей или групп Google (адресам электронной почты).
Во многих случаях репозиторий не имеет прямых сведений об учетных записях Google. Вместо этого пользователи могут быть представлены локальными учетными записями или использовать федеративный вход с поставщиком удостоверений и идентификатором, отличным от адреса электронной почты пользователя, для идентификации каждой учетной записи. Этот идентификатор называется внешним идентификатором .
Источники удостоверений , созданные с помощью консоли администратора, помогают устранить этот разрыв между системами идентификации за счет:
- Определение настраиваемого пользовательского поля для хранения внешних идентификаторов. Поле используется для сопоставления внешних идентификаторов с учетной записью Google.
- Определите пространство имен для групп безопасности, управляемых репозиторием или поставщиком удостоверений .
Используйте источники идентификации, если:
- Репозиторию не известен основной адрес электронной почты пользователя в Google Workspace или Google Cloud Directory.
- В репозитории определены группы для контроля доступа, которые не соответствуют группам на основе электронной почты в Google Workspace.
Источники удостоверений повышают эффективность индексации за счет отделения индексации от сопоставления удостоверений. Такое разделение позволяет отложить поиск пользователя при создании списков управления доступом и индексировании элементов.
Пример развертывания
На рис. 1 показан пример развертывания, в котором предприятие использует как локальные, так и облачные репозитории. Каждый репозиторий использует свой тип внешнего идентификатора для ссылки на пользователей.
![Пример развертывания](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/identity-arch.png?authuser=5&hl=ru)
Репозиторий 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() для создания участников с использованием предоставленного внешнего идентификатора.
В следующем примере показано, как получить права доступа к файлу. Эти разрешения включают имя каждого пользователя, имеющего доступ к файлу.
В следующем фрагменте кода показано, как создать участников-владельцев с использованием внешнего идентификатора ( externalUserName
), хранящегося в атрибутах.
Наконец, в следующем фрагменте кода показано, как создать участников, которые будут читать файл.
Имея список читателей и владельцев, вы можете создать ACL:
Базовый 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 :
Создать групповой ACL
Чтобы создать групповой ACL, используйте метод getGroupPrincipal() для создания участника группы с использованием предоставленного внешнего идентификатора. Затем создайте ACL, используя класс Acl.Builder , следующим образом:
Разъемы идентификации
Хотя вы можете использовать внешние идентификаторы, не принадлежащие 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
, новая группа не предоставит доступ к элементу, пока элемент не будет переиндексирован.