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

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

Создать ACL

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

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

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

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

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

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

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

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

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

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

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

Рисование связей между предметами
Рисунок 1. Метод setInheritFrom() .

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

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

Правила доступа, основанные на контроле доступа, таковы:

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

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

Если наследование устанавливается с помощью метода 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.