Сопоставить ACL

Чтобы гарантировать, что только пользователи, имеющие доступ к элементу, смогут видеть его в результатах поиска, индексируйте элементы с использованием их списков контроля доступа (ACL) из корпоративного репозитория. Необходимо смоделировать списки ACL репозитория и включить их при индексировании элементов. SDK Content Connector предоставляет методы для моделирования списков ACL большинства репозиториев.

Примечание: SDK Content Connector поддерживает списки контроля доступа (ACL) для одного домена, но не для нескольких доменов. Вы не можете предоставлять доступ пользователям и группам за пределами вашей организации. Списки контроля доступа, ссылающиеся на пользователей или группы за пределами вашей организации, не имеют никакого эффекта.

Создайте список контроля доступа (ACL).

Создание списка контроля доступа (ACL) — это двухэтапный процесс:

1. Создайте Principal с помощью статических методов в классе ACL .
2. Используйте класс Acl.Builder для построения списка контроля доступа (ACL) на основе субъекта.

В этом документе рассматриваются концепции моделирования и создания списков контроля доступа (ACL), такие как наследование и включение.

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

Для работы Google Cloud Search требуется, чтобы пользователи и группы указывали на адреса электронной почты Google. При индексировании элементов репозитория коннекторы контента могут не иметь этих адресов электронной почты. Однако SDK коннекторов контента позволяет использовать внешний идентификатор (идентификатор, предоставляющий пользователю или группе доступ к элементам репозитория) вместо адреса электронной почты для индексации элемента. Используйте метод getUserPrincipal или getGroupPrincipal для создания субъектов, содержащих внешние идентификаторы. Класс ACL включает в себя несколько других статических методов для создания объектов Principal .

Примечание: Пользователи не видят результаты поиска, пока их внешний идентификатор не синхронизируется с их учетной записью Google. Вы можете использовать коннектор идентификации для синхронизации внешних идентификаторов пользователей или групп с адресом электронной почты Google. Для получения дополнительной информации см. раздел «Создание коннектора идентификации» .

После изменения идентификатора элемента необходимо выполнить повторную индексацию элементов, чтобы новый идентификатор вступил в силу. Для получения дополнительной информации см. раздел «Изменение идентификаторов» .

наследование ACL

Наследование ACL относится к авторизации для конкретного элемента и пользователя на основе объединенных ACL элемента и его цепочки наследования. Правила принятия решения об авторизации зависят от репозитория и свойств элемента.

Наследование по набору

Для каждого элемента могут быть указаны прямые разрешенные и прямые запрещенные субъекты , которые задаются с помощью методов setReaders и setDeniedReaders . Прямой разрешенный субъект — это пользователь, указанный в списке контроля доступа (ACL) как имеющий прямой доступ к элементу. Прямой запрещенный субъект — это пользователь, указанный в списке контроля доступа (ACL) как не имеющий доступа к элементу.

Элемент также может наследовать косвенные разрешенные и косвенные запрещенные субъекты с помощью метода setInheritFrom . Косвенный разрешенный субъект имеет косвенный доступ к элементу через наследование ACL. Косвенный запрещенный субъект имеет запрещенный доступ через наследование.

Примечание: Если вы задаете тип наследования с помощью метода setInheritFrom , необходимо также задать тип наследования с помощью метода setInheritanceType . Информацию о типах наследования см. в разделе «Задача типа наследования» .

На рисунке 1 показано, как использовать метод setInheritFrom для наследования принципов.

Рисунок 1. Метод setInheritFrom .

На рисунке 1 представлены следующие элементы управления доступом:

• Пользователь 1 является прямым разрешенным субъектом пункта А.
• Пользователь 2 является прямым разрешенным субъектом пункта B.
• Элемент B наследует права доступа (ACL) элемента A.

Исходя из этих настроек, правила доступа следующие:

• Пользователь 1 является косвенным разрешенным субъектом пункта B, не указанным явно; доступ наследуется от пункта A.
• Пользователь 2 не является косвенным допустимым субъектом пункта А.

Установить тип наследования

Если вы задаете наследование с помощью метода setInheritFrom , необходимо задать тип наследования с помощью метода setInheritanceType . Тип наследования определяет, как дочерний ACL взаимодействует с родительским ACL. Объект Acl.InheritanceType реализует три типа:

• BOTH_PERMIT - Предоставлять доступ только в том случае, если это разрешено как дочерним, так и родительским списками контроля доступа (ACL).
• CHILD_OVERRIDE — В случае конфликта ACL дочернего элемента имеет приоритет над ACL родительского элемента. Пользователь может получить доступ к дочернему элементу, даже если родительский элемент запрещает это, или ему может быть отказано в доступе к дочернему элементу, даже если родительский элемент разрешает это.
• PARENT_OVERRIDE — В случае конфликта список контроля доступа родительского класса имеет приоритет над списком контроля доступа дочернего класса.

Cloud Search оценивает цепочки наследования ACL от листа до корня. Оценка начинается с дочернего элемента и его родителей и может продолжаться до корневого родителя.

Например, если дочерний процесс использует CHILD_OVERRIDE , и у пользователя есть доступ, Cloud Search не нужно оценивать родительский процесс. Однако, если дочерний процесс использует PARENT_OVERRIDE или BOTH_PERMIT , Cloud Search продолжает оценку вышестоящих процессов.

Сдерживание и удаление элементов

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

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

На рисунке 2 представлены следующие элементы управления доступом:

• Пользователь 1 является прямым разрешенным субъектом пункта А.
• Пользователь 2 является прямым разрешенным субъектом пункта B.
• Пользователь 3 является прямым разрешенным субъектом пункта C.
• Элемент C наследует права доступа (ACL) элемента A.
• В пункте B в качестве контейнера указан пункт A.
• В пункте C в качестве контейнера указан пункт B.

Исходя из этих настроек, правила доступа следующие:

• Косвенный доступ осуществляется через метод setInheritFrom . Пользователь 1 может получить доступ к элементу C, поскольку он наследует от элемента A.
• Косвенный доступ не обеспечивается изоляцией. Пользователь 2 не может получить доступ к элементу C.

Рисунок 2. Метод setInheritFrom в действии.

Разделение наследования ACL и включения позволяет моделировать множество структур.

При удалении элемента:

• Любой элемент, содержащий удаленный элемент, становится недоступным для поиска и планируется к удалению.
• Любой элемент, в котором в setInheritFrom указан удаленный элемент, становится недоступным для поиска.

Если ресурс использует setInheritFrom для удаленного элемента, но для него не задан контейнер или его иерархия не содержит удаленных элементов, элемент остается в источнике данных. Вы несете ответственность за его удаление.

На рисунке 3 показан пример удаления элементов в иерархии.

Рисунок 3. Удаление элемента и наследование ACL.

На рисунке 3 представлены следующие элементы управления доступом:

• Пользователь 1 является прямым разрешенным субъектом пункта А.
• Пользователь 2 является прямым разрешенным субъектом пункта D.
• Элементы D и E наследуют свойства от элемента A.
• В пункте D в качестве контейнера указан пункт A.
• Элементы A и E являются элементами корневого уровня.

Удаление происходит последовательно через ссылки на контейнеры. При удалении элемента A:

• Все потомки ссылки setInheritFrom теряют доступ.
• Пользователи больше не могут получить доступ к элементу А.
• Элемент D автоматически удаляется и становится недоступным.
• Элемент E не удаляется, но становится недоступным и не поддается поиску.