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

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

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

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

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

1. Создайте Principal , используя статические методы в классе ACL .
2. Используйте класс Acl.Builder для создания ACL с использованием принципала.

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

Создание участника с использованием внешнего идентификатора

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

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

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

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

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

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

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

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

Примечание. Если вы устанавливаете наследование с помощью метода setInheritFrom() , вам необходимо установить тип наследования с помощью метода setInheritanceType() . Информацию о типах наследования см. в разделе Установка типа наследования .

На рис. 1 показано, как метод setInheritFrom() используется для наследования косвенно разрешенных и косвенно запрещенных участников.

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

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

• Пользователь 1 — это прямой разрешенный принципал элемента A.
• Пользователь 2 — это прямой разрешенный принципал элемента B.
• Элемент B наследует ACL элемента A.

В зависимости от контроля доступа правила доступа следующие:

• Пользователь 1 не обязательно должен быть явно указан как участник элемента B, чтобы быть косвенным разрешенным участником элемента B; доступ наследуется, поскольку Пользователь 1 указан в качестве прямого разрешенного участника элемента A, а элемент B наследует свой ACL от элемента A.
• Пользователь 2 не является косвенным разрешенным участником для элемента A.

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

Если вы устанавливаете наследование с помощью метода setInheritFrom() , вы должны установить тип наследования с помощью метода setInheritanceType() . Тип наследования определяет, как ACL-список дочернего элемента сочетается со ACL-списком родительского элемента. Acl.InheritanceType реализует три типа наследования:

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

• CHILD_OVERRIDE — установите тип наследования CHILD_OVERRIDE , чтобы заставить ACL дочернего элемента иметь приоритет над ACL унаследованного родительского элемента , когда они конфликтуют. Таким образом, если ACL родительского элемента запрещает доступ пользователю как пользователю, которому запрещено читать, у пользователя все еще есть доступ, если у него есть доступ к дочернему элементу в качестве читателя. И наоборот, даже если ACL родительского элемента предоставляет доступ пользователю, у пользователя нет доступа, если ему запрещено читать дочерний элемент.

• PARENT_OVERRIDE — установите тип наследования PARENT_OVERRIDE , чтобы заставить ACL родительского элемента иметь приоритет над ACL дочернего элемента , когда они конфликтуют. Таким образом, если ACL дочернего элемента запрещает доступ пользователю как пользователю, которому запрещено читать, у пользователя все еще есть доступ, если у него есть доступ к родительскому элементу в качестве читателя. И наоборот, даже если список ACL дочернего элемента предоставляет пользователю доступ, у пользователя нет доступа, если ему запрещено читать родительский элемент.

При оценке цепочки наследования ACL порядок оценки может изменить результат решения об авторизации. Cloud Search обеспечивает сквозной порядок оценки для цепочек наследования ACL. В частности, решение ACL для цепочки начинается с оценки дочернего элемента и его родителей и может продвигаться вплоть до корневого родителя.

Например, если дочерний элемент имеет тип наследования CHILD_OVERRIDE и у пользователя есть доступ к дочернему элементу, Диску не нужно оценивать родительский элемент. Однако если у дочернего элемента есть PARENT_OVERRIDE или BOTH_PERMIT, Диск продолжает оценивать наследование дальше по цепочке.

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

При индексировании элемента вы можете пометить его как контейнер, используя метод setContainer() класса IndexingItemBuilder . Отношения «контейнер/контейнер» устанавливают физическую иерархию элементов и обеспечивают правильное удаление элементов. При удалении контейнера содержащиеся в нем элементы также удаляются.

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

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

• Пользователь 1 — это прямой разрешенный принципал элемента A.
• Пользователь 2 — это прямой разрешенный принципал элемента B.
• Пользователь 3 — это прямой разрешенный участник элемента C.
• Элемент C наследует ACL элемента A.
• Элемент B называет элемент A своим контейнером.
• Элемент C называет элемент B своим контейнером.

В зависимости от контроля доступа правила доступа следующие:

• Косвенный доступ осуществляется с помощью метода setInheritFrom() . Следовательно, пользователь 1 может получить доступ к элементу C, поскольку элемент C наследует ACL элемента A.
• Косвенный доступ не происходит из-за того, что элемент C содержится в элементе B. Следовательно, пользователь 2 не может получить доступ к элементу C.

Рисунок 2. Используемый метод setInheritFrom() .

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

Когда элемент успешно удален:

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

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

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

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

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

• Пользователь 1 — это прямой разрешенный принципал элемента A.
• Пользователь 2 — это прямой разрешенный принципал элемента D.
• Элемент D и элемент E наследуют ACL элемента A.
• Элемент D называет элемент A своим контейнером.
• Элементы A и E являются элементами корневого уровня, поскольку у них нет элемента-контейнера.

Удаляет каскад по ссылкам на контейнер. Когда элемент A удаляется:

• Все потомки ссылки setInheritFrom() теряют доступ для всех пользователей.
• Ни один пользователь не может получить доступ к элементу A.
• Пункт D неявно удаляется. Ни один пользователь не может получить доступ к элементу D.
• Элемент E не удаляется, поскольку удаление происходит только через ссылки на контейнеры.
• Элемент E становится недоступным, и ни один пользователь не сможет выполнить поиск элемента E.