Решения на базе 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 инфраструктур управления данными, ориентированных на генерирование запросов, индексирование, кэширование и обеспечение безопасности.

Литература
  1. M. Wahl, T. Howes, S. Kille. Lightweight Directory Access Protocol (v3), IETF RFC 2251, Dec. 1997.
  2. 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.
  3. XLNT Software. Handling XML Documents Using Traditional Databases, Aug. 2002.
  4. P.J. Marron, G. Lausen. On Processing XML in LDAP. Proc. 27th Int?l Conf. Very Large Databases, ACM Press, 2001.
  5. C.R. Ey. Managing Content with Directory Servers, diploma thesis, Dept. Business Info. Systems, Karlsruhe Univ. of Applied Sciences, 2000.
  6. L. Ahmedi, G. Lausen. Ontology-Based Querying of Linked XML Documents. Proc. Semantic Web Workshop, 11th World Wide Web Conf., 2002.
  7. K.L.E. Law. XML on LDAP Network Database. Proc. IEEE Canadian Conf. Electrical and Computer Eng., IEEE Press, 2000.
  8. Isode. Comparative Performance Benchmarking of Isode M-Vault R10.1, white paper, Oct. 2003.
  9. E.J. Thornton, D.P. Mundy, D.W. Chadwick. A Comparative Performance Analysis of Seven LDAP Directories. Proc. Conf. Terena Networking, 2003.
  10. 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.
  11. W. Dixon et al. An Analysis of LDAP Performance Characteristics, tech. report TR-2002GRC154, GE GlobalResearch, 2002.
  12. X. Wang et al. Measurement and Analysis of LDAP Performance. Proc. Int?l Conf. Sigmetrics, ACM Press, 2000.
  13. S. Cluet, O. Kapitskaia, D. Srivastava. Using LDAP Directory Caches. Proc. Symp. Principles of Database Systems (PODS), ACM Press, 1999.
  14. 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.