Решения на базе LDAP поставляются компаниями IBM Tivoli, Novell, Sun Microsystems, Oracle, Microsoft и др. Растущая популярность этой технологии объясняется как ее гибкостью, так и совместимостью с существующими приложениями.
Сервис каталогов — это оснащенный средствами поиска репозитарий, в котором наделенные соответствующими полномочиями пользователи и службы могут находить информацию о людях, компьютерах, сетевых устройствах и приложениях. Потребность в получении информации, особенно по каналам Internet, постоянно растет, поэтому в последнее десятилетие сервисы каталогов получили широкое распространение и многие распределенные приложения имеют такие службы.
Облегченный протокол доступа к каталогам [1] представляет собой открытый промышленный стандарт, получающий все более широкое распространение как метод доступа к каталогам. Как явствует из его названия, LDAP является облегченной версией протокола доступа к каталогам Directory Access Protocol и прямым потомком «тяжеловеса» X.500, наиболее известного протокола управления каталогами. В LDAP и в X.500 применяются сходные структуры представления данных, но эти протоколы имеют ряд фундаментальных различий [2].
- LDAP использует стек протоколов TCP/IP, тогда как X.500 — стек OSI.
- Правила кодировки элементов протокола LDAP не столь сложны, как у протокола X.500.
- Серверы LDAP реализуют ссылочный механизм (referral mechanism). Если такой сервер не в состоянии предоставить запрашиваемую клиентом информацию, он предоставляет ему URL альтернативного сервера LDAP, содержащего искомые данные. Сервер X.500 действует иначе: он разыскивает отсутствующие данные собственными средствами и предоставляет их клиенту без ссылки на сервер, на котором были взяты эти данные.
Многие поставщики программных средств обеспечивают их совместимость с LDAP, поскольку этот протокол отличается гибкостью и интегрируется со все большим числом программ извлечения данных и управления ими.
Технология LDAP
На рынке имеется множество серверов на базе LDAP — от общедоступных серверов гигантского масштаба, таких как BigFoot и Infospace, до небольших LDAP-серверов, предназначенных для рабочих групп. Промежуточное положение занимают серверы каталогов, установленные и особым образом сконфигурированные во многих университетах и на предприятиях. Их назначение — предоставлять информацию о профессорско-преподавательском составе, служащих и студентах в формате, совместимом с почтовым сервисом данной организации, с системой аутентификации и методами управления доступом к приложениям и ресурсам.
Список общедоступных интерфейсов каталогов имеется в общеевропейской исследовательской сети DANTE (Delivery of Advanced Network Technology to Europe). В таблице 1 представлены наиболее известные из Web-сервисов, использующих LDAP, и перечислены функциональные возможности, полученные при интеграции LDAP с существующими приложениями обработки данных (электронная почта, передача файлов, видеоконференции и т.д.). В почтовой службе, к примеру, типичная LDAP-запись может содержать такие атрибуты, как mailLocalAddress, mailHost, UserCertificate (содержит сертификат пользователя в двоичном формате), ipLoginPort и ipLoginHost (для тех случаев, когда пользователь устанавливает соединение по коммутируемым линиям).
Таблица 1. Наиболее известные Web-сервисы, использующие LDAP
Архитектура LDAP
Функционирование LDAP основывается на модели клиент-сервер. С помощью протокола LDAP, который выполняется поверх стека TCP/IP, клиенты LDAP извлекают данные из базы данных сервера каталога. Клиенты LDAP либо напрямую контролируются сервером с установленными на нем средствами LDAP, либо управляются LDAP-совместимыми приложениями. На рис. 1 представлены основные элементы архитектуры LDAP.
![]() |
Рис. 1. Инфраструктура LDAP. Устройства и серверы с помощью протокола LDAP обращаются к данным, хранимым в базе данных LDAP-серверов |
Важнейшую роль в архитектуре LDAP играют два компонента. Это LDAP-совместимая база данных, или каталог, и формат представления данных, основывающийся на языке XML.
Каталог LDAP
LDAP-каталоги — это базы данных, структурированные по принципу иерархических информационных деревьев, которые описывают представляемые ими организации. На рис. 2 приведен пример иерархической структуры, состоящей из трех уровней. Каждая запись LDAP идентифицируется с помощью отличительного имени (distinguished name, DN), которое декларирует свою позицию в иерархии. Структура данной иерархии представляет собой информационное дерево каталога (directory information tree, DIT), которое «вырастает» из корня (RootDN).
![]() |
Рис 2. Пример иерархической структуры стандарта LDAP. Каждая запись LDAP идентифицируется отличительным именем, которое свидетельствует о позиции данной записи в иерархии |
В базовой системе обозначений LDAP символы dc обозначают компонент домена (domain component), символы ou — организационную единицу (organizational unit), а символы uid — идентификатор пользователя (user id). Так, корень RootDN, описывающего некую базирующуюся в Греции организацию информационного дерева каталога с данными о пользователях, выглядел бы как dc=organization-name, dc=gr, а отличительное имя DN записи уполномоченного пользователя формулировалось бы так: uid=avakali, ou=people, dc=organization-name, dc=gr.
Представление данных и их структура. В реляционных СУБД структуру данных определяют пользователи; в каталогах LDAP фиксированная базовая схема управляет иерархией каталога. Кроме того, если объекты LDAP вложены в иерархические структуры, то объекты реляционных баз данных связаны друг с другом посредством первичного и внешнего ключей, соединяющих элементы данных. Наконец, типы данных LDAP отличаются гибкостью и расширяемостью.
Организация запросов и транзакций. В реляционных СУБД процессор запросов чувствителен к отношениям между объектами базы данных, тогда как в каталогах LDAP соответствующие отношения отбрасываются в процессе обработки запроса. Кроме того, запросы LDAP могут различаться по тому уровню на дереве, с которого начинается поиск (запрос-ответ). К примеру, мы можем иметь запросы двух типов:
Запрос 1:
ldapsearch -h localhost -b
«dc=organization-name, dc=gr»
«uid=avakali»
Запрос 2:
ldapsearch -h localhost -b
«ou=people, dc=organization-name, dc=gr»
«businesscategory=Assistant Professor»
Параметр -h определяет выполняющую поиск главную машину, а параметр -b указывает на уровень иерархии, на котором будет начинаться поиск. Таким образом, первый запрос указывает на запись пользователя с идентификатором uid=avakali (поиск начнется с узла, имеющего отличительное имя «dc=organization-name, dc=gr»), а второй — на все записи с атрибутом «businesscategory=AssistantProfessor» (поиск начнется с узла с именем «ou=people, dc=organization-name, dc=gr»).
Операционные выгоды и затраты. В реляционных базах данных важнейшее значение имеет быстродействие при записи транзакций и считывании, тогда как каталоги LDAP используются в основном для считывания данных. Кроме того:
- серверы LDAP, как правило, просты в установке и в обслуживании;
- каталоги LDAP могут быть весьма распределенными, а реляционные базы данных, как правило, отличаются высокой степенью централизации;
- серверы LDAP могут тиражировать некоторые или все хранимые на них данные с помощью встроенных и легко конфигурируемых средств репликации. Многие поставщики СУРБД считают такие средства «дополнительными» и соответственно берут за них дополнительную плату. Наконец, если реляционные базы данных исправно отображают сложные взаимоотношения объектов, то в каталогах LDAP трудно отобразить какие-либо отношения между объектами, помимо иерархических.
XML и настройка каталогов LDAP
XML — общепринятый стандарт представления данных в среде Web. Поскольку службы каталогов получили широкое распространение и интегрированы с множеством Web-приложений, в них часто используются мощные гибкие средства языка XML. Современные серверы LDAP не совместимы с XML, но эти технологии весьма близки по структуре.
Язык разметки для служб каталогов Directory Services Markup Language (DSML, xml.coverpages.org/dsml.html) — новая технология представления содержащейся в каталоге информации на языке XML. Она призвана сыграть роль своеобразного моста, соединяющего сервисы каталогов и XML-совместимые приложения. DSML описывает содержимое служб каталогов различных производителей с помощью синтаксиса XML и тем самым обеспечивает возможность взаимодействия между ними.
Направив запрос на сервер Web-приложений, на котором выполняется сервис DSML, XML-совместимое приложение может считывать информацию из каталога. DSML определяется с помощью описания содержимого документа (document content description, DCD), где указываются правила и факторы, ограничивающие структуру, а также контент документов XML. На рис. 3 представлена типичная транзакция, в ходе которой сервис DSML преобразует записи LDAP в DSML.
![]() |
Рис. 3. Транзакция, модифицированная в соответствии со спецификацией Directory Services Markup Language. Служба DSML преобразует записи LDAP в формат DSML для XML-совместимых приложений |
При обращении к содержимому каталогов средствами языка XML возникают новые требования к методам хранения и извлечения данных. Разработан ряд предложений по реализации эффективных методов хранения и извлечения данных на базе технологии LDAP. Некоторые методы управления [3, 4] предполагают установление соответствий между узлами объектной модели документов XML и записями LDAP. Такие процессы базируются на объектных процессорах, которые устанавливают соответствия между объектами XML и объектами LDAP. С этой целью они определяют новые классы объектов LDAP (для которых будут устанавливаться соответствующие узлы, элементы и атрибуты XML). Другой подход предполагает установление соответствий между узлами XML DOM и записями LDAP с помощью определений классов объектов LDAP для узлов XML [5].
Благодаря сходству структур некоторые модули могут транслировать запросы XPath в запросы LDAP. Точнее говоря, исследователи предложили модель запроса, базирующуюся на алгоритме оценки. Последний преобразует любой запрос XPath в серию запросов LDAP, которые решают задачу, сформулированную в исходном запросе [4]. Еще одна идея состоит в том, чтобы пользователи формулировали запросы Xpath, которые компонент XML2LDAP будет преобразовывать в формат LDAP, а затем компонент LDAP2XML будет преобразовывать полученный результат из формата LDAP в формат XML. Транслировать данные LDAP в формат XML может и синтаксический анализатор XML [7].
Практическое использование LDAP
Разработчики уже давно указывают на необходимость создания стандарта каталога промышленного уровня, и эта потребность становится все более настоятельной ввиду появления многочисленных (и постоянно развивающихся) приложений, функционирующих в среде Directory Enabled Network (DEN). К ним, в частности, относятся приложения, взаимодействующие с существующими сетевыми устройствами, файлы системной конфигурации, средства организации видеоконференций и т.д.
Авторов спецификации DEN интересовала прежде всего возможность создания мощной расширяемой инфраструктуры, способной моделировать различные элементы сети и службы для обеспечения удобного хранения и извлечения информации из LDAP-каталогов и хранилищ данных.
Реализации LDAP
В таблице 2 отражены основные функциональные возможности основных серверов LDAP. Все шесть рассматриваемых серверов (кроме OpenLDAP) обеспечивают тиражирование с несколькими ведущими серверами. В ходе такой операции два первичных LDAP-сервера, предоставляющих для тиражирования изменения в своем содержимом, могут принимать обновления, синхронизировать их друг с другом и обновлять содержимое всех LDAP-серверов, на которые передаются тиражируемые данные. Последние, в свою очередь, могут направлять двум ведущим серверам запросы на обновление.
Таблица 2. Основные функциональные возможности серверов LDAP
Созданный корпорацией IBM интерфейс Standalone LDAP HTTP API (Slaphapi) позволяет выводить полученные данные в виде текста в формате HTML или DSML и обращаться к каталогам LDAP по протоколу HTTP. Кроме того, в IBM разработали инструментальное средство XML Data Mediator (прежнее название XML Integrator), предназначенное для двунаправленного преобразования данных (таких, как реляционные данные или данные LDAP) между XML и структурированными форматами.
Разработанный в Sun Microsystems интерфейс Java naming and directory interface API совместим с языком DSML (developer. java.sun.com/developer/earlyAccess/jndi).
Microsoft оснащает средствами DSML сервис Active Directory. Кроме того, она работает над механизмом отображения данных каталога в структуре DOM, к которой можно обращаться с помощью XPath.
LDAP Processor представляет собой процессор, выполняющий запросы LDAP, транслирующий полученные результаты в фрагмент XML-текста и вставляющий данный фрагмент в исходный документ. LDAPHTTP транслирует данные XML в формат LDAP. Шлюз XMLDAP — это созданное в соответствии со стандартами решение, позволяющее разработчикам представлять данные каталога LDAP в иных форматах.
Благодаря столь мощной поддержке стандарта потенциальные клиенты LDAP имеют широкие возможности выбора.
Выбор сервера LDAP
Требования по времени. В ходе типичных тестов сопоставляется время выполнения серверами LDAP операций считывания данных, а также их поиска, записи и загрузки. Для повышения надежности результатов база данных загружается более одного раза. Некоторые исследователи испытывали приложения с высокими требованиями к времени выполнения [8-10], другие анализировали время отклика на запрос в сочетании с совокупной полосой пропускания и задержкой [11, 12].
Связывание информации. При LDAP-взаимодействиях роль операций связывания исключительно велика. Направляя сведения для аутентификации клиента, эти операции инициируют установление соединений сервером LDAP. Метрики, относящиеся к операциям связывания (включая время отклика, число запросов на связывание и ошибок связывания), могут существенно задерживать выполнение LDAP-операции. Время отклика при связывании зависит от метода аутентификации [12].
Функциональность поиска. Этот критерий включает в себя запросы на поиск и ошибки, среднее число и размеры результатов поиска, время отклика при поиске и текущие операции поиска. Время отклика при поиске зависит от нескольких факторов, в том числе от фильтрации запросов, от места в иерархической структуре данных точки начала поиска, от числа внесенных в запрос атрибутов и того, включены ли в запрос индексированные атрибуты. Многие организации, работающие с LDAP-серверами, регулярно собирают статистические данные по операциям поиска, что позволяет им отслеживать эксплуатационные характеристики серверов. К таким организациям относятся, например, Университет Вермонта и Университет Торонто.
Управление кэш-памятью. Этот показатель важен потому, что для уменьшения времени отклика серверы каталогов используют кэши каталогов. Исследователи изучили идею использования LDAP-кэшей и предложили алгоритм снижения времени отклика [13]. Метрики управления кэш-памятью составляются путем сопоставления числа плодотворных обращений к кэш-памяти и общего числа запросов к кэшу каталога; в кэш-службах LDAP пользователи обычно определяют размер кэша.
Интенсивность обменов данными. Эта характеристика определяется числом переданных байтов и отправленных записей в ходе обменов между сервером LDAP и его клиентами. Интенсивность обменов данными зависит от разных метрик, таких как запросы на соединения, текущие соединения, средняя длина соединения и средний размер результатов поиска. Для мониторинга интенсивности обменов, особенно когда речь идет об отображении состояния в масштабе почти реального времени, администраторы LDAP-серверов могут пользоваться различными инструментами [14], например средством Mirabai-LDAP Metrics.
Эволюция LDAP: что дальше?
В ходе эволюции LDAP станут решаться вопросы сближения со службами каталогов X.500, что будет способствовать созданию глобального каталога Internet. Метакаталоги, которые управляют интеграцией и потоками данных между серверами каталогов, — еще один шаг к объединению серверов X.500 и LDAP. Многие поставщики продуктов стандарта LDAP, в том числе Sun, Novell и Microsoft, реализуют в них средства для создания метакаталогов, и, похоже, в этом проявляется тенденция развития приложений на базе LDAP.
Управление LDAP-данными, и в первую очередь, методы их хранения и извлечения, можно было бы значительно усовершенствовать за счет соответствующей интеграции стандартов XML и LDAP.
Современные тенденции развития LDAP свидетельствуют о высокой вероятности того, что эта спецификация будет принята в качестве стандарта для развернутых в Internet инфраструктур управления данными, ориентированных на генерирование запросов, индексирование, кэширование и обеспечение безопасности.
Литература
- M. Wahl, T. Howes, S. Kille. Lightweight Directory Access Protocol (v3), IETF RFC 2251, Dec. 1997.
- T.A. Howes. The Lightweight Directory Access Protocol: X.500 Lite, tech. report TR-95-8, Center for Information Technology Integration, Univ. of Michigan, 1995.
- XLNT Software. Handling XML Documents Using Traditional Databases, Aug. 2002.
- P.J. Marron, G. Lausen. On Processing XML in LDAP. Proc. 27th Int?l Conf. Very Large Databases, ACM Press, 2001.
- C.R. Ey. Managing Content with Directory Servers, diploma thesis, Dept. Business Info. Systems, Karlsruhe Univ. of Applied Sciences, 2000.
- L. Ahmedi, G. Lausen. Ontology-Based Querying of Linked XML Documents. Proc. Semantic Web Workshop, 11th World Wide Web Conf., 2002.
- K.L.E. Law. XML on LDAP Network Database. Proc. IEEE Canadian Conf. Electrical and Computer Eng., IEEE Press, 2000.
- Isode. Comparative Performance Benchmarking of Isode M-Vault R10.1, white paper, Oct. 2003.
- E.J. Thornton, D.P. Mundy, D.W. Chadwick. A Comparative Performance Analysis of Seven LDAP Directories. Proc. Conf. Terena Networking, 2003.
- N. Klasen. Directory Services for Linux, in Comparison with Novell NDS and Microsoft Active Directory, master?s thesis, Dept. computer Science, RWTH Aachen Univ., 2001.
- W. Dixon et al. An Analysis of LDAP Performance Characteristics, tech. report TR-2002GRC154, GE GlobalResearch, 2002.
- X. Wang et al. Measurement and Analysis of LDAP Performance. Proc. Int?l Conf. Sigmetrics, ACM Press, 2000.
- S. Cluet, O. Kapitskaia, D. Srivastava. Using LDAP Directory Caches. Proc. Symp. Principles of Database Systems (PODS), ACM Press, 1999.
- J. Hanck, J. Pingenot. LDAP Product Research Results, Computing and Network Services, Kansas State Univ., Apr. 2002.
Вассилики Коуцоникола (vkoutson@csd.auth.gr) — аспирант университета Аристотеля, Афина Вакали (atavakali@csd.auth.gr) — доцент университета Аристотеля (Фессалоники, Греция).
Vassiliki Koutsonikola, Athena Vakali, LDAP: Framework, Practices, and Trends,. IEEE Internet Computing, September/October 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.