Глава 6. Наложение OpenLDAP dynlist

Наложение dynlist позволяет конкретному атрибуту конкретного объектного класса (оба указываются в параметрах наложения) дополнять результаты операции поиска при их возвращении. То есть, когда запись (DN) с явно заданным адресом, либо полученная в результате поиска, содержит указанный объектный класс, то в ответ на поисковый запрос будут возвращены результаты другого поискового запроса по URL, определённому в указанном атрибуте этой записи. Самое распространённое применение данной функции - то, что называют динамическими группами (Dynamic Groups). В отличие от статических групп, определяемых с помощью объектного класса groupOfMembers, динамические группы обычно создаются с помощью объектного класса groupOfURLs с параметром поиска, определённом в атрибуте memberURL, содержащем стандартные поисковые URL LDAP. Динамические группы - нестандартная (не определённая в RFC), но получившая широкую реализацию возможность LDAP. Динамические группы могут использоваться опосредствованно для нахождения специфических подмножеств DIT, либо непосредственно для создания групп, которым затем могут быть назначены полномочия и права на доступ (с помощью директив access to).

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

Конфигурация

В OpenLDAP dynlist реализован в виде наложения. Его конфигурация приведена в следующем фрагменте slapd.conf:

...
# подключение требуемого для dynlist набора схемы dyngroup
include dyngroup.schema
...
# требуется, если наложение было собрано динамически
# указание без полного пути требует определения директивы modulepath
# если модули не находятся в стандартном расположении PATH
loadmodule dynlist.la
# ИЛИ
loadmodule dynlist.so
...
database bdb
suffix "dc=example,dc=com"
...
# устанавливаем dynlist только для данного DIT
# это наложение можно также поместить в раздел глобальных настроек,
# в этом случае оно будет применяться ко всем DIT
overlay dynlist
dynlist-attrset dyn-objc [URI] url-attr [[map-dn:]member-attr]
...
# другие директивы overlay
# или следующая директива database

Далее следует описание каждого параметра директивы dynlist-attrset:

dyn-objc

Обязательный параметр. Определяет объектный класс, который будет использоваться для запуска процесса динамического расширения. Обычно это объектный класс groupOfURLs. При использовании данного объектного класса в DIT создаются записи в такой форме:

# создание групповой записи dyngroup

dn: cn=dyngroup,ou=groups,dc=example,dc=com
objectclass: groupOfURLs
cn: dyngroup
memberURL: ldap:///ou=people,dc=example,dc=com?cn,sn?one?(ou=it*)

В данном случае, когда при операции поиска встречается DN cn=dyngroup,ou=groups,dc=example,dc=com, это вызывает на сервере LDAP срабатывание функции динамической группы.

URI

Описание скоро будет.

url-attr

Обязательный параметр. Определяет атрибут записи, в котором содержится поисковый URL. Если в записи есть объектный класс, указанный в параметре dyn-objc, то будет вызвана операция поиска по URL, хранящемуся в этом атрибуте, и результаты этого поиска будут возвращены обратно в запись. При использовании с объектным классом groupOfURLs этим атрибутом обычно является memberURL. Вот пример такого атрибута memberURL:


memberURL: ldap:///ou=people,dc=example,dc=com?cn,sn?one?(ou=it*)

В данном случае указанный поисковый LDAP URL создаст поисковый запрос на локальном сервере (это следует из синтаксиса ///) с базой поиска ou=people,dc=example,dc=com только по записям на один уровень ниже (one), возвращающий атрибуты cn и sn любых записей, в которых атрибут ou (organizationalUnitName) начинается с "it", либо содержит только "it" (поиск без учёта регистра символов). Члены данной группы (которые будут возвращены в результате поиска) могут затем использоваться для получения каких-либо привилегий при помощи директив access to (или атрибутов olcAccess в случае cn=config).

Этот пример иллюстрирует использование локального поиска, но это не единственный вариант. Вот корректный LDAP URL для удалённого сервера:


memberURL: ldap://ldap.example.net/ou=people,dc=example,dc=com?cn,sn?one?(ou=it*)

В зависимости от скорости передачи и объёмов возвращаемых данных, в результате подобного поиска могут возникнуть значительные задержки времени при обслуживании.

map-dn

Описание скоро будет.

member-attr

Необязательный параметр. Если member-attr присутствует, поведение динамической группы будет отличаться. В этом случае поисковый запрос вернёт DN всех записей, удовлетворивших критериям поиска, в указанный атрибут (который должен присутствовать в записи, содержащей объектный класс "срабатывания", и тип которого должен быть distinguishedName). Если объектный класс "срабатывания" - groupOfURLs, то в нём есть два атрибута, позволяющих хранить DN: owner и seeAlso. Когда в определении dynlist-attrset используется member-attr, список возвращаемых атрибутов в поисковом LDAP URL должен быть пустым. Следующие фрагменты демонстрируют использование этого типа конфигурации:


# фрагмент slapd.conf
...
overlay dynlist
dynlist-attrset groupOfURLs memberURL owner
...

# создание групповой записи dyngroup

dn: cn=dyngroup,ou=groups,dc=example,dc=com
objectclass: groupOfURLs
cn: dyngroup
# пустой список атрибутов в поисковом URL
memberURL: ldap:///ou=people,dc=example,dc=com??one?(ou=it*)

В данном случае DN всех записей, удовлетворяющих критериям поиска, будут возвращены в атрибут owner.



Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!

Copyright © 1994 - 2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 21 октября 2015 г.
Переведено участниками проекта Pro-LDAP.ru в 2012 г.