Динамические группы: принципы построения. Сравнение наложений dynlist и autogroup

Содержание

Принципы построения динамических списков и групп

Кроме статических списков и групп, OpenLDAP также может работать и с динамическими. Их поддержка реализована с помощью стандартного наложения dynlist.

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

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

Параметры такого дополнительного поискового запроса задаются в виде LDAP URI в одном из атрибутов записи динамической группы. Формат LDAP URI определён в RFC 4516, и тому, кто немного разбирается в параметрах поисковых запросов LDAP, составить такой URI не составит труда. Чтобы не быть голословными, мы разберём компоненты LDAP URI в одном из последующих примеров.

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

Как ни крути, именно возможность фильтрации записей при поиске делает LDAP таким привлекательным для системных администраторов. И в поставке OpenLDAP есть неофициальное наложение autogroup, позволяющее схожим по настройкам с dynlist образом автоматически поддерживать членство записей каталога в группах. Функционал наложения autogroup напоминает функционал другого наложения — memberof, только наоборот: в записи групп вносятся изменения, если претерпели определённые изменения записи-члены этих групп. То есть, если у записи-члена был убран признак принадлежности к определённой группе, то атрибут его членства будет удалён из этой группы. Если же запись в каталоге приобрела признак членства в какой-то группе, то в запись-группу будет добавлен соответствующий атрибут членства. При этом получающиеся группы уже нельзя назвать динамическими: их атрибуты членства статически находятся в каталоге, только ведутся автоматическим образом. Поэтому частенько среди администраторов такие группы называют "автогруппами" (в конце концов, это следует из названия самого наложения).

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

С точки зрения способа настройки, функционал наложения autogroup похож на dynlist (хотя, конечно, не столь богат, всё-таки наложение неофициальное). Поэтому мы сочли возможным рассмотреть динамические группы (и списки) и автогруппы в одном разделе.

Сравнение наложений dynlist и autogroup

Прежде чем рассматривать конкретные примеры настройки, сравним возможности наложений dynlist и autogroup, чтобы можно было сделать обоснованный выбор, какое из них использовать для решения той или иной задачи при работе с каталогом.

Функционалdynlistautogroup
Природа атрибутов членства в группе (атрибутов-пунктов списка)ДинамическиеСтатические, ведутся автоматически
Возможность применения поисковых фильтров для отбора записей на основе значений атрибутов членства (атрибутов-пунктов)НетДа
Поддержка записей-группДаДа
Поддержка записей-списковДаНет
Возможность переопределения исходного типа атрибута при построении спискаДаНет
Возможность переопределения авторизационной сущности при выполнении дополнительного поискового запросаДаНет
Возможность наложения дополнительных ограничений на отбор записей-кандидатов в члены группы (пункты списка)ДаНет
Встроенный функционал поддержания признака обратного членства в группе в записях-членахНетДа

Следует отметить ещё одну небольшую тонкость, связанную с динамической и статической природой атрибутов, поддерживаемых с помощью этих наложений. При использовании наложения dynlist дополнительная нагрузка на каталог создаётся при выполнении поисковых запросов (в виде вторичных поисковых запросов и обработки их результатов для каждой обслуживаемой записи с динамическим содержимым). Во время модификации записей каталога никакой дополнительной обработки не происходит. При использовании наложения autogroup ситуация обратная: поисковые запросы обрабатываются стандартным способом, а вся дополнительная нагрузка (вторичные поисковые запросы и, при необходимости, модификация записей-групп) происходит именно во время модификации потенциальных записей-членов групп в каталоге. И в том и в другом случае дополнительная нагрузка не будет слишком ощутимой, если, конечно, в каталоге не поддерживаются тысячи динамических или автогрупп.

О наборе схемы данных dyngroup

Во многих примерах настройки динамических групп, в том числе и в официальной man-странице наложения dynlist, для построения динамических записей используется объектный класс groupOfURLs, в один из атрибутов которого, — memberURL, — помещается LDAP URI для описания параметров вторичного поиска потенциальных записей-членов группы (списка). Определения этого объектного класса и типа атрибута входят в набор схемы данных dyngroup, включённого в стандартную поставку OpenLDAP. Хотя использование этого объектного класса и типа атрибута является общепринятой практикой, для работы рассматриваемых наложений они не требуются, поскольку, как мы покажем на примерах, динамические группы и списки можно строить и с другими классами и атрибутами. Так что вопрос подключения или неподключения набора схемы данных dyngroup оставляется на выбор администратора каталога.

Единственный случай, когда подключение этого набора схемы необходимо — настройка наложения dynlist с переопределением авторизационной сущности при выполнении вторичного поискового запроса. Наложение ищет в записи динамической группы конкретный атрибут dgIdentity, который, вместе с содержащим его вспомогательным объектным классом dgIdentityAux, входит в тот же набор схемы данных dyngroup.

Примеры использования наложений dynlist и autogroup

Поскольку вариантов настройки обоих наложений довольно много, рассмотреть их в рамках одного обзора не получится. Поэтому мы решили разобрать работу наложений на примерах. Сначала мы разберём "стандартные" варианты настройки наложений dynlist и autogroup для построения каталогов с динамическим содержимым, а затем — несколько нетривиальных конфигураций, в которых динамические объекты строятся на основе статических групп каталога.

Pro-LDAP.ru 2013-2019 г. Последнее изменение страницы — 28 декабря 2018 г. Вопросы и предложения принимаются на форуме проекта.