Журнал "Мир Internet" http://www.iworld.ru/

#5 (68) май 2002 http://www.iworld.ru/magazine/index.phtml?do=show_number&m=94701987

X.500 На пути к информационному раю

РљРѕРіРґР°-то давным-давно, еще РІ прошлом веке, было сделано изобретение, изменившее РјРёСЂ. И РёРјСЏ ему – "почта РїРѕ RFC822". Изобретение это было оценено РїРѕ достоинству Рё тут же отнесено Рє разряду жизненно необходимых. РќРѕ как водится, РІСЃРєРѕСЂРµ нашлись люди, посмевшие утверждать, что можно было сделать почту Рё получше, Рё даже придумали СЃРІРѕСЋ версию стандарта для системы обработки почты, получившую название X.400. "РњРёСЂ Internet" уже писал РЅР° эту тему. РќРѕ, Рє сожалению, РІ силу объективных Рё субъективных причин судить Рѕ достоинствах Рё недостатках этого стандарта РґРѕ СЃРёС… РїРѕСЂ может лишь небольшая часть интернет-сообщества.
Однако в этой статье речь пойдет о другом. Появление на свет X.400 ознаменовало собой начало истории другого изобретения, которое имеет все шансы изменить мир еще раз...
Дмитрий Рожков

Проблема

Самый главный недостаток систем обработки почты РЅР° РѕСЃРЅРѕРІРµ X.400, который сразу бросается РІ глаза, – это РІРёРґ адреса электронной почты. Р’РѕС‚ его пример:

cn=Dmitry Rojkov, prmd=Piter, admd=ATT, c=RU

Сложно не согласиться с утверждением, что адрес вида rojkov@piter.com запоминается гораздо лучше. Однако проблема подсказывает решение. Тем более что им давно пользуются телефонные компании: стоит ли утруждать свою память заучиванием любых мало-мальски полезных телефонов, если все телефонные номера можно свести в единый справочник, который всегда под рукой и где все имена абонентов телефонной сети для простоты поиска сгруппированы по месту жительства и упорядочены по алфавиту. Причем запись об абоненте может кроме номера телефона содержать и другие полезные сведения.

Очевидно, что подобный справочник был Р±С‹ весьма полезен Рё для пользователей электронной почты. Стандарт (Р° точнее, рекомендации Международного телекоммуникационного СЃРѕСЋР·Р° – ITU), описывающий работу электронного справочника, получил название X.500. Этот стандарт появился, конечно же, РЅРµ РЅР° пустом месте – Сѓ него есть предшественники, опыт использования которых был учтен РІ С…РѕРґРµ разработки. Среди РЅРёС… важное место занимает протокол finger, РїСЂРё помощи которого пользователи РћРЎ Unix получают информацию РґСЂСѓРі Рѕ РґСЂСѓРіРµ.

Finger

Чтобы воспользоваться услугами finger-сервера, надо всего лишь вызвать из командной строки программу-клиент и передать ей в качестве параметра имя сервера, на котором зарегистрирован интересующий пользователь, и имя его системного аккаунта:

$ finger rojkov@castle.piter-press.ru

В ответ получим что-то наподобие:

Login name: rojkov	In real life: Dmitry Rojkov
Directory: /home/rojkov	Shell: /bin/sh
On since: Mar 12 10:39:42	4 hours 52 minutes idle time
Plan: Today I'll be available till 17:00
Home: 555-1234

Для небольшой программы это достаточно информативный ответ РІ СѓРґРѕР±РЅРѕРј формате. Впрочем, удобством формата вывода РІСЃРµ достоинства finger Рё ограничиваются, РІСЃРµ остальное – недостатки: РІРѕ-первых, finger реализован далеко РЅРµ РІРѕ всех РћРЎ; РІРѕ-вторых, информация Рѕ пользователе привязана Рє конкретному серверу: СЃ РѕРґРЅРѕР№ стороны, нужно знать, РЅР° каком именно сервере зарегистрирован интересующий пользователь, СЃ РґСЂСѓРіРѕР№ – самому пользователю необходимо следить Р·Р° тем, чтобы информация Рѕ нем была согласованной РЅР° всех серверах, РіРґРµ РѕРЅ зарегистрирован. РљСЂРѕРјРµ того, нет возможности выполнить РїРѕРёСЃРє всех пользователей, чей домашний телефон начинается, допустим, РЅР° 333.

Whois

Другим примером справочника может служить утилита whois, к помощи которой чаще всего прибегают системные администраторы, чтобы определить, какой организации принадлежит тот или иной IP-адрес или доменное имя. Набрав в командной строке

$ whois piter.com

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

• название организации, зарегистрировавшей домен;
• название организации или РёРјСЏ персоны, которой РѕРЅ принадлежит;
• физический адрес владельца домена;
• электронные адреса для контакта СЃ владельцем Рё С‚. Рґ.

Сам сервер базы данных находится в Калифорнии и доступен всему миру через Интернет. Его адрес фиксирован, и поэтому нет нужды указывать его в параметрах утилиты whois (хотя такая возможность имеется). База данных поддерживается организацией с длинным названием Defence Data Network Network Information Center (DDN NIC) или просто NIC.

Существование сервиса whois стало возможным благодаря тому, что РІ руках NIC сосредоточен весь контроль над выдачей свободных IP-адресов Рё выдача адреса увязана СЃ регистрацией этого события РІ базе данных. Таким образом, централизованное ведение базы данных избавляет whois РѕС‚ недостатков, присущих finger: запись РѕР± объекте существует РІ РѕРґРЅРѕРј экземпляре, Р° потому противоречивость результатов запросов РѕР± РѕРґРЅРѕРј Рё том же объекте исключена. РљСЂРѕРјРµ того, РїРѕРёСЃРє информации можно вести РїРѕ нескольким критериям: IP-адрес, доменное РёРјСЏ, РёРјСЏ владельца Рё С‚. Рґ. Однако следствием централизации, наряду СЃ достоинствами, являются Рё недостатки. Объем централизованной базы данных центрального сервера имеет технологические пределы, РїСЂРё достижении которых время отклика РІ период пиковых нагрузок РЅР° базу может значительно увеличиться. Еще неприятнее, что РёР·-Р·Р° неисправности сервера или канала подключения Рє Сети доступ Рє службе может полностью пропадать. Очевидным требованием Рє глобальному справочнику, призванным исключить РїРѕРґРѕР±РЅСѓСЋ ситуацию, является наличие распределенной архитектуры, РІ результате чего информация, СЃ РѕРґРЅРѕР№ стороны, организована РІ единую структуру, Р° СЃ РґСЂСѓРіРѕР№ – распределена РЅР° РјРЅРѕРіРёС… серверах РїРѕ всему РјРёСЂСѓ, Рё выход РёР· строя РѕРґРЅРѕРіРѕ РёР· РЅРёС… РЅРµ РїСЂРёРІРѕРґРёС‚ Рє недоступности сервиса РІ целом.

DNS

Примером распределенного справочника является служба доменных имен DNS, РѕСЃРЅРѕРІРЅРѕРµ предназначение которой – хранить информацию Рѕ соответствии IP-адресов доменным именам Рё наоборот, Р° также множество РґСЂСѓРіРёС… полезных сведений, например адреса сервера почтового обмена для домена. Для повышения надежности Рё производительности РІ системе активно используется кэширование, репликация данных СЃ первичных серверов РЅР° вторичные Рё делегирование обязанностей РїРѕ обслуживанию доменов нижних уровней РґСЂСѓРіРёРј серверам.

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

Требования

Таким образом, предшествующий опыт позволил сформулировать требования, предъявляемые к идеальному справочнику. Он должен иметь:

• децентрализованное управление; каждый сервер отвечает только Р·Р° СЃРІРѕСЋ локальную часть базы справочника, чтобы обновление данных Рё сопровождение можно было выполнять немедленно;
• мощные возможности РїРѕРёСЃРєР°, дающие пользователям возможность создавать запросы произвольной степени сложности;
• единое глобальное пространство имен РїРѕ аналогии СЃ DNS;
• структурированный информационный каркас, допускающий локальные расширения;
• стандартный интерфейс, единый протокол доступа. Приложения, нуждающиеся РІ ресурсах справочника, должны производить запросы, используя стандартизированный протокол, одинаковый для всех платформ.

Всем этим требованиям как раз и отвечают системы, построенные по стандарту X.500. Во второй части статьи мы кратко рассмотрим принципы работы систем X.500, которые с этого момента будем называть Справочником2 с заглавной буквы, обозначая тем самым их глобальный характер.

Схема Справочника

Р’СЃСЏ информация, хранящаяся РІ Справочнике, представлена РІ РІРёРґРµ записей. Запись – это отображение РІ Справочнике объекта реального РјРёСЂР°: страны, организации, подразделения, персоны Рё С‚. Рґ. Каждый такой объект характеризуется свойствами, то есть атрибутами, которые РјРѕРіСѓС‚ принимать значения согласно определенному для каждого атрибута синтаксису. Например, для номера телефона может быть задан синтаксис ddd-dd-dd, РіРґРµ d – цифра РѕС‚ 0 РґРѕ 9. Некоторые атрибуты РјРѕРіСѓС‚ быть обязательными для объекта (например, фамилия для персоны), РґСЂСѓРіРёРµ – факультативными (допустим, РёРјСЏ СЃСѓРїСЂСѓРіР°).

Однотипные объекты объединены РІ классы объектов или, точнее, инстанцируются3 РѕС‚ РѕРґРЅРѕРіРѕ класса объектов. Классы объектов организованы РІ иерархию. Создавая новый класс РЅР° РѕСЃРЅРѕРІРµ уже имеющегося, можно расширить состав его атрибутов. РќР° вершине иерархии находится базовый класс, Р° РїРѕРґ РЅРёРј – его классы-потомки, наследующие атрибуты Сѓ классов-предков. Тем, кто изучал РѕСЃРЅРѕРІС‹ объектно-ориентированного дизайна, РІСЃРµ это должно быть хорошо знакомо (СЂРёСЃ. 1).

Рис.1 Пример иерархии классов (RFC1309)

Формальное определение иерархии классов объектов, атрибутов Рё РёС… синтаксиса называется схемой Справочника. Схема как раз Рё является тем самым структурированным информационным каркасом, который допускает локальные расширения. Р’ принципе, любой системный администратор может составлять собственные схемы РїРѕРґ СЃРІРѕРё нужды, однако, если РјС‹ хотим получить действительно глобальную информационную службу, необходима унификация схем. Именно эта потребность вызвала появление РЅР° свет документов, определяющих стандартные схемы. Например, схема, служащая для поддержки функционирования самой службы X.500, определена РІ рекомендациях X.521, схема для поддержки почты X.400 описана РІ X.402. РљСЂРѕРјРµ того, РІ документе RFC1274 определены еще РґРІРµ схемы, весьма полезные для глобального Справочника, – COSINE Рё Internet X.500, Р° также четко описан механизм изменения существующих Рё добавления новых стандартных схем, РєРѕРіРґР° РІ этом назревает необходимость.

Дерево записей

Р’СЃСЏ полезная информация, хранящаяся РІ Справочнике, образует информационную базу Справочника – DIB (Directory Information Base), которая организована РІ РІРёРґРµ иерархического справочного информационного дерева – DIT (Directory Information Tree). DIT – это ключевой элемент РІ понимании работы Справочника X.500, поэтому рассмотрим его подробней.

Каждая запись Справочника занимает определенное положение РІ DIT. Записи, Сѓ которых нет подчиненных записей, – это листья дерева. Листьями чаще всего оказываются записи Рѕ людях. Р’СЃРµ остальные записи – это узлы дерева. Нижние узлы дерева подчинены вышестоящим, Р° самые верхние подчинены РѕРґРЅРѕРјСѓ-единственному узлу, называемому корнем. Р’ целом иерархия записей очень напоминает организацию файлов РІ файловой системе: корневой каталог, подкаталоги Рё находящиеся внутри РЅРёС… файлы.

Каждая запись дерева содержит атрибут, который РїРѕ совместительству является относительным уникальным именем записи – RDN (Relative Distinguished Name)4. Таким атрибутом, как правило, является РёРјСЏ объекта или его уникальный идентификатор. Уникальность этого имени "относительна" РІ масштабе всего Справочника, поскольку РЅР° разных ветвях DIT РјРѕРіСѓС‚ оказаться записи СЃ одинаковыми RDN, РїРѕРґРѕР±РЅРѕ тому, как РІ разных подкаталогах РѕРґРЅРѕР№ файловой системы РјРѕРіСѓС‚ оказаться файлы СЃ одинаковыми именами. И так же, как путь Рє файлу определяет его полное уникальное РёРјСЏ РІ пределах файловой системы, последовательность RDN-записей РЅР° пути РѕС‚ РєРѕСЂРЅСЏ РґРѕ нужной записи образует уникальное РёРјСЏ (DN) этой записи (СЂРёСЃ. 2).

Рис.2 Фрагмент иерархии DIT

Стандарт X.500 допускает использование псевдонимов, когда два различных DN указывают на одну и ту же запись. Пользователи Unix заметят, что это очень похоже на использование файлов-ссылок. Вот таким образом DIT создает глобальное пространство имен, имеющее много общего с DNS и способное в перспективе заменить его.

Схема Справочника вместе СЃ пространством имен (иерархией именованных записей) образуют информационную модель службы X.500. Однако для построения рабочей системы требуется реализация еще РґРІСѓС… механизмов: модели каталогов Рё модели безопасности. Модель безопасности служит для того, чтобы возвращаемая Справочником информация была достоверной, Р° доступ Рє ней был разграничен. Модель каталогов описывает, как хранящаяся РІ логически едином Справочнике информация распределяется РїРѕ разным физическим серверам Рё СЃ помощью каких протоколов эти серверы общаются РґСЂСѓРі СЃ РґСЂСѓРіРѕРј Рё предоставляют информацию клиентскому РџРћ. Подробнее РѕР± этих моделях рассказывается РІРѕ врезке. Нам же сейчас важно знать, что РІ РѕСЃРЅРѕРІРµ модели каталогов службы X.500 лежит сложный Рё РіСЂРѕРјРѕР·РґРєРёР№ протокол – протокол DAP (Directory Access Protocol). Рђ клиенты для доступа Рє информации Справочника РјРѕРіСѓС‚ использовать его упрощенный вариант – LDAP (Lightweight Directory Access Protocol).

Применение

Теперь настало время сказать о применении Справочника. Как уже упоминалось, записи о персонах кроме имени могут содержать множество атрибутов: телефон, адрес электронной почты и др. Причем совсем не обязательно, чтобы электронный адрес был в формате X.400. Обычный RFC822-совместимый "e-mail" тоже имеет право находиться в Справочнике.

Кроме того, X.500 был задуман не только ради организации службы "белых страниц", но также и для организации инфраструктуры управления открытыми ключами. Несмотря на то что алгоритмы шифрования с открытым ключом и электронной подписи разработаны уже давно, люди недостаточно активно пользуются ими для частной и деловой переписки. Все дело в трудностях, связанных с обменом открытыми ключами. А между тем, открытый ключ также может являться атрибутом любой записи в Справочнике наряду с адресом электронной почты, фотографией и названием любимого напитка. Появляется принципиальная возможность сделать шифрование личной почты прозрачным для пользователей и окружить тайну переписки таким барьером, который был бы непреодолим даже для спецслужб, а автоматическое удаление неавторизованных, анонимных писем может стать мощным оружием против столь ненавистного спама.

Перспективы

Возможности применения Справочника X.500 не ограничиваются лишь поддержкой почтовых систем, для чего он был изначально разработан. Описанный в RFC1430 стратегический план развития справочного сервиса включает хранение и реализацию поиска любых полезных ресурсов (принтеры, сетевое оборудование и т. д.), хранение конфигурационной информации, организацию ее в высокоуровневые справочники для поддержки управления инфраструктурой Интернета, хранение информации о местонахождении статей в информационных архивах. А в далекой перспективе планируется создание электронного варианта пока еще бумажного каталога "Желтые страницы", но уже в мировом масштабе и с возможностью для фирм самостоятельно редактировать устаревшие данные. Вся эта радужная картина способна вскружить голову любому человеку, чья повседневная жизнь так или иначе связана с Интернетом. Однако, как это часто бывает, реальность вносит свои коррективы.

Так, например, до сих пор не появилось достаточно быстрой и надежной реализации протокола DAP для стека TCP/IP и вряд ли появится, поскольку X.500 DAP не создавался для этого стека, и для его работы требуется дополнительное ПО сопряжения5. Впрочем, появление LDAP версии 3 дает надежду, что необходимость в DAP отпадет, так как аутентификация, шифрование, целостность данных и их репликация будут поддерживаться LDAP, который как раз и создавался для работы в TCP/IP.

Другим сдерживающим фактором является то, что для построения РЅРѕРІРѕРіРѕ пространства имен требуется наличие специальной организации, регистрирующей имена, РґР° Рё сама процедура выдачи имени РїРѕРєР° РЅРµ вполне очевидна. Например, какое РёРјСЏ будет правильнее зарегистрировать РІ Справочнике – официальное Piter Join Stock Company или более известное Piter? Рђ Рє какой стране отнести транснациональную компанию? Однако выход РёР· этой ситуации было предложено искать РІ использовании уже существующей инфраструктуры регистрации доменных имен Рё введении РЅРѕРІРѕРіРѕ класса объектов РІ схему Справочника – domainComponent СЃ РѕРґРЅРёРј обязательным атрибутом dc, РІ котором содержится часть доменного имени. РўРѕРіРґР° РІРёРґ DIT изменится РЅР° тот, что изображен РЅР° СЂРёСЃ. 3.

Рис.3 К вопросу о возможности интеграции DIT и DNS

В этом случае уникальные имена записей в DIT будут строиться не из набора атрибутов c, o, ou, а из последовательности атрибутов dc по пути от корня иерархии к объекту. Атрибуты же, определяющие страну и организацию, будут играть второстепенную роль. Таким образом, верхняя часть иерархии Справочника будет унаследована от DNS, а сам Справочник явится надстройкой над DNS. Трудно сказать, сможет ли когда-нибудь такая служба полностью вытеснить DNS, но подобная организация DIT может оказаться полезной для управления конфигурационной информацией о домене, которая бы просто загружалась из Справочника в DNS-сервер с помощью протокола передачи зоны (Zone Transfer Protocol).

Несмотря РЅР° РІСЃРµ сложности, развитие справочного сервиса РЅРµ останавливается. Пользу РѕС‚ применения Справочника можно получить РЅРµ только РІ масштабе всей Сети, РЅРѕ Рё РІ локальных сетях предприятий. РћРЅ позволяет реализовать хорошо масштабируемый единый механизм аутентификации пользователей локальных сервисов, Р±СѓРґСЊ то доступ Рє данным разнородных СУБД предприятия, Рє почте, Рє интранет-серверам или РґСЂСѓРіРёРј серверам приложений. Благодаря справочнику образуется однородная среда, РІ которой пользователю достаточно всего лишь раз пройти процедуру аутентификации, чтобы получить доступ РєРѕ всем ресурсам, работать СЃ которыми РѕРЅ имеет право согласно локальным политикам безопасности. Из РґСЂСѓРіРёС… преимуществ, которые дает применение Справочника, можно назвать, например, простоту управления маршрутизацией почты Рё единое управление конфигурационной информацией рабочих станций локальной сети6. Р’СЃРµ это подвигло РјРЅРѕРіРёС… производителей выпустить РЅР° рынок СЃРІРѕРё реализации LDAP-серверов. Среди РЅРёС… Рё Netscape Directory Server, Рё Novell NDS, Рё, конечно же, Microsoft Active Directory. Сообщество Open Source также обзавелось своей реализацией – OpenLDAP.

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

Дмитрий Рожков,
rojkov@piter.com

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

2 Встречающийся в русскоязычной литературе термин "служба каталогов" мне нравится меньше, потому что он не подчеркивает справочной сути описываемой технологии.

3 То есть являются экземплярами объектов определенного класса.

4 В качестве RDN можно использовать также комбинацию атрибутов.

5 РћСЃРЅРѕРІРѕР№ функционирования X.500, РїРѕ замыслу его создателей, должен был стать стек протоколов РІ модели OSI. Стек OSI – это РЅРµ просто абстрактная семиуровневая модель, которую принято изображать РЅР° первых страницах всех учебников РїРѕ сетевым технологиям. Существует множество реализаций этого стека, которые РїРѕ СЂСЏРґСѓ объективных причин так Рё остались невостребованными.

6 РўРѕ есть локальный справочник X.500 – это потенциальная замена системам, подобным NIS.

Полезные ссылки

www.applmat.ru/metacomputing/ism99.html – использование службы директорий LDAP для предоставления метаинформации РІ глобальных вычислительных сетях.

www.umich.edu/~dirsvcs/ldap/doc – документация РЅР° сайте университета штата Мичиган.

www.itu.org – сайт Международного телекоммуникационного СЃРѕСЋР·Р°.

www.netscape.com/directory/v4.0/faq.html – FAQ РїРѕ продуктам Netscape.

www.openldap.org – сайт проекта OpenLDAP.

www.dante.net/nameflow – NameFLOW Directory Service.

Несколько хороших статей:

www.osp.ru/lan/2001/05/038.htm – "LDAP РІ середине пути".

www.osp.ru/nets/2000/09/072.htm – "Распутывая клубок LDAP".

www.osp.ru/lan/1999/10/009.htm – "Каталоги Рё Internet".

Модель каталогов

Модель каталогов (directory model) описывает, каким образом Справочник хранит информацию Рё как пользователи получают доступ Рє информации Справочника. Модель состоит РёР· РґРІСѓС… компонентов: пользовательского агента Справочника – DUA (Directory User Agent), запрашивающего Справочник РѕС‚ имени пользователя, Рё системного агента Справочника – DSA (Directory System Agent), который обеспечивает хранение некоторой части DIB Рё РІ то же время может являться точкой доступа Рє Справочнику для DUA. Каждому DSA делегируется СЃРІРѕСЏ область ответственности Р·Р° хранение той или РёРЅРѕР№ ветви DIT. Например, DSA1 может хранить записи, находящиеся ниже узла ou=Sales, o=Piter, c=ru, Р° DSA2 – отвечать Р·Р° листья РЅР° ветке ou=Stores, o=Piter, c=ru. И администрировать РёС… Р±СѓРґСѓС‚ разные люди. РџСЂРё этом обязательно будет существовать DSA, обслуживающий корень дерева. Р’СЃРµ это очень похоже РЅР° то, как работают серверы DNS.

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

В этом случае возможны два варианта развития событий:

• DSA возвращает DUA ссылку РЅР° вышестоящий DSA, который может либо вернуть требуемые данные, если этот DSA компетентен РІ данной области DIT, либо вернуть ссылку РЅР° следующий DSA – вышестоящий или подчиненный;
• DSA сам делает запросы Рє РґСЂСѓРіРёРј DSA РїРѕ цепочке Рё возвращает результат DUA.

Таким образом, с точки зрения пользователя доступ к данным осуществляется прозрачно.

Наряду СЃ обеспечением децентрализации для повышения производительности Рё надежности работы Справочника рекомендации X.500 предусматривают возможность репликации данных СЃ РѕРґРЅРѕРіРѕ DSA РЅР° РґСЂСѓРіРѕР№ Рё синхронизации реплик, Р° также возможность кэширования. Для реализации всех этих возможностей был создан протокол доступа Рє Справочнику – DAP (Directory Access Protocol). DAP – это язык, РЅР° котором DSA общаются между СЃРѕР±РѕР№ (РЅР° самом деле X.500 определяет целый набор протоколов, РІ котором роль DAP сводится Рє взаимодействию DSA СЃ DUA, РЅРѕ почему-то этот факт РЅРµ всегда находит отражение РІ соответствующей литературе). Однако, как показал опыт, этот протокол очень ресурсоемкий Рё трудно реализуемый, поэтому РІ университете штата Мичиган был разработан его облегченный вариант – LDAP (Lightweight Directory Access Protocol), или, как его еще РёРЅРѕРіРґР° называют, "DAP РЅР° диете". РћСЃРЅРѕРІРЅРѕРµ его предназначение – предоставление стандартного интерфейса Рє данным, хранящимся РІ DSA. РќРѕ развитие LDAP продолжается, Рё постепенно РѕРЅ приобретает дополнительную функциональность.

Модель безопасности

Модель безопасности определяет два типа безопасного доступа DUA к данным Справочника: простая аутентификация по паролю и сильная аутентификация, в основе которой лежит использование асимметричных ключей. Последний способ используется DSA для аутентификации друг друга для исключения атак типа "man-in-the-middle" и описан в рекомендациях X.509. Кроме того, могут быть использованы так называемые списки управления доступом для определения прав доступа к тем или иным атрибутам записей. Например, атрибут userPassword не должен быть доступен для чтения и тем более для записи посторонним пользователям.

#5 (68) май 2002 http://www.iworld.ru/magazine/index.phtml?do=show_number&m=94701987

Журнал "Мир Internet" http://www.iworld.ru/