Мы уже писали о Directory Enabled Networks (DEN) и о конкретных реализациях служб управления каталогами ("Компьютерное Обозрение", № 4, 8, 9, 2000). Тогда особенно отмечались важность модели X.500 и совместимость таких служб с протоколом LDAP. В этой же статье сосредоточимся на двух вышеназванных спецификациях.
Служба управления каталогами — это гибкая специализированная распределенная база данных, разработанная для хранения информации об объектах в виде записей и ее предоставления широкому кругу приложений. Каждая запись содержит набор атрибутов, значения которых в соответствии со строго определенным синтаксисом отражают информацию об объектах. Отметим, что каталог хранит информацию, достаточно редко изменяющуюся, и оптимизирован для операций чтения. Вследствие этого службы управления каталогами не используют механизм отката (rollback), так как все операции изменения/удаления являются простыми одношаговыми процедурами.
Модель X.500
Разыскать нужную информацию об объекте — задача непростая, если она находится в большом количестве каталогов, которые не взаимодействуют друг с другом, или хранится в разных форматах. Желание создать глобальную справочную службу стало основным толчком для начала работ, которые завершились серией стандартов, принятых ITU (International Telecommunication Union) и ISO/IEC и известных под названием X.500.
X.500 — это группа спецификаций, названных так по имени основного документа X.500: Overview of concepts, models and services, и определяющих требования к глобальной распределенной службе каталогов. Другие документы из этой серии уточняют детали данного стандарта. Так, например, X.501 концентрируется на самой модели, X.509 — на схеме аутентификации и X.525 (последний в группе) — на вопросах репликации.
Ядро модели X.500 составляет распределенная база данных, содержащая информацию об объекте, такую, как его местонахождение в сети и ряд характеристик, именуемых атрибутами. Вся распределенная база данных называется информационной базой каталога (Directory Information Base — DIB), а ее компоненты — системными агентами каталога (Directory System Agent — DSA). Иерархическая структура хранилища данных (рис. 1) определяется информационным деревом каталога (Directory Information Tree — DIT), каждый элемент в структуре которого состоит из одного или более узлов — DSA Specific Entry (DSE). В одном DSA может храниться информация о нескольких организациях, и наоборот, информация об одной большой организации может храниться в нескольких DSA.
 |
| Рис. 1 |
Модель X.500 предусматривает для каталогов 17 основных классов объектов, таких, как Alias, Country, Locality, Organization, Organizational Unit, Person и т. д. Схема также детально описывает набор атрибутов объектов и их синтаксис. Она может быть расширена с помощью добавления классов, конкретизирующих и дополняющих классы-предшественники. Каждый объект имеет относительное отличительное имя (Relative Distinguised Name — RDN), которое является уникальным его идентификатором среди объектов того же уровня и содержится в атрибуте Common Name (cn). Глобальное уникальное имя объекта, или отличительное имя (Distinguised Name — DN), образуется с помощью объединения RDN от корня до самого объекта, например, отличительное имя объекта, содержащего информацию об авторе, может выглядеть примерно так: itc_drupal_cn=Hillarion Sheremetyev, ou=Kompyuternoye Obozreniye, o=ITC, c=UA.
DSA обмениваются информацией с помощью системного протокола каталогов (Directory System Protocol — DSP). Каждый DSA имеет интерфейс, называемый "точкой доступа", который DSP используют для взаимодействия между DSA. Клиенты запрашивают информацию из каталогов (DSA) с помощью протокола доступа к каталогам (Directory Access Protocol — DAP). Это протокол уровня приложений (application level), предназначенный для работы со стеком протоколов OSI. Создание запросов и обновление каталога выполняется с помощью пользовательского агента каталога (Directory User Agent — DUA).
Получив запрос от DUA, DSA должен дать ответ либо на основе собственной информации, либо запросить нужные данные у другого DSA, либо перенаправить DUA к DSA, содержащим их (рис. 2). Последнее обеспечивается с помощью механизма информационных ссылок (knowledge references, referral), который является важной частью модели, позволяющей обеспечить взаимную работу серверов, не нарушая при этом требований безопасности.
 |
| Рис. 2 |
Спецификация X.500, принятая ITU-T в 1988 г., была встречена достаточно холодно в компьютерном мире, в основном потому, что использование OSI-модели делает реализацию этой службы очень громоздкой как для клиентов, так и для серверов. Нечеткости в определении механизма информационных ссылок привели также к тому, что различные воплощения X.500 оказались несовместимыми друг с другом.
Однако излишняя требовательность в сложившейся ситуации была неуместной. Первоначальная спецификация X.500 создала модель общего именного пространства (common namespace) и послужила основой для ряда экспериментальных проектов в крупных университетах и компаниях, самым известным из которых является NameFLOW-Paradise.
Стандарт X.500, обновленный в 1993 г., устранил неопределенности, связанные с информационными ссылками, репликацией (replication) и управлением доступа (access control). Именно на него обычно ссылаются и используют его в большинстве реализаций служб управления каталогами X.500. Эта и более поздние версии — X.500 (1996 г.) и X.500 (1997 г.) — послужили основой для создания LDAP-совместимых служб управления каталогами.
LDAP
Будучи полноценным протоколом уровня приложений, DAP создает значительную нагрузку на клиентскую систему, обусловленную необходимостью поддержки функций протоколов высших уровней. Эталонная модель OSI является, скорее, руководством к действию (или справочным пособием) и полностью не реализована ни в одном из современных стеков протоколов. С развитием Internet стек TCP/IP стал стандартом де-факто. Использование уже существующего стека протоколов позволило бы снизить требования прежде всего к клиентским системам и упростить механизм доступа к каталогам.
Именно такие рассуждения и послужили основой для работы в Мичиганском университете (University of Michigan, или Umich), которая привела к созданию упрощенного протокола доступа к каталогам (Lightweight Directory Access Protocol — LDAP), утвержденного впоследствии IETF. Использование TCP/IP позволило снять излишнюю нагрузку, генерируемую представительским (presentation) и сессионным (session) уровнями OSI. Будучи строго протоколом доступа к X.500-каталогам и не имея никакой дополнительной функциональности, LDAPv1 действительно предъявлял невысокие требования к клиентам. Такая узкая направленность протокола не удовлетворяла многих, и это повлекло за собой напряженную работу по созданию его дальнейших версий.
Если использование TCP/IP позволяет разгрузить клиентские машины, то нельзя ли также упростить требования к серверу службы управления каталогами? Именно таким желанием мотивировались усилия по созданию второй версии протокола. Спецификация LDAPv2 сделала ее не только своеобразным шлюзом, с помощью которого клиенты, использующие TCP/IP (в спецификации по LDAP говорится о любом транспортном протоколе), могут запрашивать информацию у X.500-серверов. Она позволила создавать автономные (stand-alone) серверы служб управления каталогами на основе стандартов LDAP. В связи с этим не стоит забывать о важности X.500: LDAP использует модель общего именного пространства, заимствованного оттуда, а не пытается заменить ее или внести коррективы. Совместимость с моделью X.500 является ключевым требованием LDAP.
Но работы по усовершенствованию этого протокола не прекратились после создания второй версии, да и вряд ли это скоро произойдет. LDAPv3 включает в себя всю функциональность предыдущей спецификации плюс возможность использования цифровых сертификатов (digital certificates) с LDAP, поиск по компонентам имени записи, лучшую интеграцию с X.500 (1993) и самостоятельными каталогами. LDAPv3 позволяет хранить информацию об атрибутах объектов в виде символьных значений (ASCII) и в бинарном формате, фотографий в формате JPEG/JFIF и оцифрованных по алгоритму u-law звуков, URL и ключей PGP. Иными словами, такой каталог может хранить информацию об организациях, подразделениях, людях, принтерах, документах — любых объектах, встречающихся в реальной жизни. Протокол базируется на механизме простой аутентификации и безопасности (Simple Authentication and Security Layer — SASL), поддерживает аутентификацию с помощью Kerberos v4 и разрешает использование TSL (следующая версия SSL) для обеспечения безопасности передачи информации. Важно отметить, что экспорт/импорт данных осуществляется с помощью файлов в формате LDIF (LDAP Data Interchange Format).
Значительная работа была проделана по интеграции LDAP и World Wide Web. LDAP определяет специальный формат URL, позволяющий автоматически отфильтровывать большие каталоги и имеющий синтаксис (вымышленный URL):
ldap://ldap.ldapserver.ua/o=ITC,c=UA? postalAddress?one
Такой запрос должен отфильтровать только почтовые адреса организаций, находящихся в Украине и имеющих название ITC.
В настоящее время ведутся работы по дальнейшему расширению (extensions) функциональности LDAP. Основными направлениями в этой области являются управление доступом и аутентификация, сортировка и постраничная загрузка результатов поиска, динамические каталоги, схема и механизм поддержания ссылок (что пока проблематично с LDAP, но не с DAP), обнаружение LDAP-серверов, мультимастерная репликация и интерфейс прикладного программирования (API), используемый c LDAP. Также идет работа по созданию механизма обмена данными в MIME-формате или, скорее всего, в формате vCard, применяемом компанией Verisit.
Множество фирм решили использовать LDAP со своими продуктами. Так, Netscape Communications намерена сделать LDAP не только основным протоколом для станций-клиентов, но и для серверов. Еще в 1996 г. более 40 компаний и учреждений заявили о своей поддержке LDAP, среди них AT&T, IBM, Hewlett-Packard, Novell и, разумеется, Мичиганский университет. Сейчас этот список значительно больше, так как LDAP-совместимость является ключевой для DEN.
Проблемы и альтернативы
LDAP и X.500 идеально подходят для создания приложений типа "Белые страницы" (White pages). В то же время существуют проблемы, связанные с использованием LDAP и X.500 для разработки приложений типа "Желтые страницы" (Yellow pages). Для реализации последних можно построить поддерево в каталоге, содержащее информацию о разделах, или произвести глубокий поиск по всем серверам (например, организаций, выпускающих автозапчасти). В первом случае структура DIT становится запутанной, а во втором — генерируются колоссальный трафик и нагрузка на сервер, связанные с поддержанием механизма ссылок. В некоторых странах Европы такой тотальный поиск запрещен законом.
На создание приложений типа "Желтые страницы" нацелен протокол Whois++. Полномасштабное его описание выходит за рамки данной статьи. Отметим лишь, что Whois++ основан на технологии баз данных и использует сеть индексных серверов, хранящих ссылки на основные серверы, содержащие каталоги. Такая модель ускоряет поиск нужной информации, но может порождать круговые ссылки, разрешением которых должна заниматься клиентская система. IETF ведет разработки по созданию упрощенного протокола доступа к каталогам SOLO, а также общего протокола обмена индексной информацией (Common Indexing Protocol — CIP). Несмотря на существующие проблемы, основное достоинство LDAP в том, что его приняла компьютерная общественность.