 |
  |
|||
 |
 |
 |
||
 |
|
 |
||
Издатель: Algorithm Online При поддержке ORACLE в России  Техническая поддержка  официальный дистрибутор ORACLE |
|
|
Введение в службы каталогов и протокол LDAP1 июня 2000 г.
Келли Вайсет Протокол LDAP (Lightweight Directory Access Protocol)- упрощенный протокол доступа к каталогу дает разработчикам и АБД преимущества служб каталога (Directory Services) – стандарта отрасли. Так что же это такое – служба каталога? Oracle Magazine, no.2, 2000 Поговорим о каталогах безотносительно к информационным технологиям. Каталоги – это неотъемлемый элемент современной жизни. Вы читаете каталог у входа в торговый ряд, узнавая о расположении каждого магазина, товарах и услугах, которые он предлагает; вы читаете этот или другой каталог, уже находясь в одном из магазинов. Вместе с телефонными справочниками такие каталоги помогают людям найти, то, что они ищут: специализированный магазин, отдел спортивных товаров или адрес ближайшего ресторана итальянской кухни. Без каталогов нам было бы, по меньшей мере, неудобно. Но каталоги также необходимы для сетецентричной, распределенной обработки данных. Специализированная база данных, которая хранит информацию об объектах некоторой сети, например, о пользователям, принтерах, базах данных, файлах, – это каталог, который позволяет людям находить других людей и ресурсы, связанные с этой сетью. Информация в каталоге может описывать любой ресурс, которым компании хотят управлять: служащие, конференц-залы, партнеры по электронному бизнесу или совместно используемые сетевые ресурсы, такие как, например, принтеры. К сожалению, исторически сетевые приложения использовали либо жестко закодированные механизмы реализации каталогов (the /etc/printcap file на рабочей UNIX-станции – пример такого подхода), либо каталоги “закрытой” архитектуры, недоступные для использования другими приложениями. Например, адресная книга системы электронной почты, разработанной для использования в локальной сети, помогает пользователям адресовать свои письма, но эта книга не поможет им определить расположение ближайшего цветного принтера. Аналогично, каждый экземпляр СУБД Oracle типичной вычислительной системы имеет свой собственный каталог имен пользователей. С одной стороны, отсутствие служб каталога создает проблемы для разработчиков, которые должны придумывать какие-то механизмы управления для пользователей, которые хотят использовать их приложение. С другой стороны, множество несовместимых служб каталогов тоже не выручает, ибо их API, как правило, закрытой архитектуры и не раскрываются. И такое множество служб каталогов является обузой для сетевых и системных администраторов, которые должны управляться с многочисленными сетевыми объектами, которые расположены в различных местах. Например, когда компания "Acme Widgets" нанимает программиста со знанием Java, это событие вызывает серию административных процессов для обеспечения нового программиста доступом к сетеывм ресурсам и необходимыми учетными записями (account – бюджет, счет). Администраторы сети, базы данных и операционной системы должны создать идентификацию нового пользователя в этой сети, создать новую учетную запись электронной почты, ввести информацию о новом пользователе в базу данных о персонале и установить все приложения, которые этому программисту нужны, такие скажем, как пользовательские счета для работы с базами данных этапов разработки, тестирования и эксплуатации. (Спустя шесть месяцев, когда программист уйдет , администраторы должны будут “повторить” весь этот процесс, но уже для ликвидации всех учетных записей уволившегося сотрудника). Далее, вполне возможно, что избыточная информация об этом программисте не будет синхронизирована по всем используемым системам. То, что ряд людей вводят информацию о программисте в эти системы, повышает вероятность ошибки. Любой вид электронного бизнеса сталкивается с аналогичными проблемами управления информацией о пользователях при предоставлении деловым партнерам доступа к своим корпоративным данным и приложениям. Эти сложности подчеркивают важность использования служб каталогов, построенных на стандартах, и протокола, основанного на стандарте, признанном отраслью, для доступа к этим службам. Таким протоколом в Интернете становится протокол Lightwieght Directory Access Protocal - LDAP. (LDAP – это подмножество протокола X.500, отсюда “упрощенный” в определении LDAP. – Прим. переводчика.) Используя LDAP, разработчики, которые хотят интегрировать каталог в свои приложения, могут использовать стандартные протокол и API. Создатели LDAP опубликовали спецификации использования API на языке программирования C (RFC 1823) и аналогичные спецификации для языка программирования Java рассматриваются в Internet Engineering Task Force (IETF; draft-ietf-ldapext-ldap-java-api-08.txt). Разработчики могут использовать любой существующий каталог, соответствующий стандарту, применяя открытые API и протокол, и множество приложений могут получать доступ к любой службе этого каталога, используя открытый протокол. Первый раз определенный в марте 1995 года, как RFC 1755, LDAP в настоящее время переживает третью итерацию определения, как LDAPv3, RFC 2251 (December 1997; Wahl, Howes, Kille). IETF—это тот самый комитет по стандартам, который ответственен за стандартизацию таких основных протоколов Интернет, как TCP/IP, DNS и HTTP. Он же определяет и процесс спецификации LDAP. Первоначально разработанный только для спецификации доступа клиентов к каталогу служб X.500 Международной организации стандартов (ISO), протокол LDAP в настоящее время также специфицирует службу каталога, протокол доступа, пространство имен (namespace) и правила взаимодействия серверов согласно модели X.500. Иначе говоря, вам больше не нужен полнофункциональный каталог служб X.500 для применения LDAP; вы можете использовать любой каталог, совместимый с LDAP, по своему усмотрению. Основные компоненты. Служба каталога – это программный процесс, который “прослушивает” запросы клиентов (Web-браузеры, клиенты электронной почты, программы управления и т.д.) и обрабатывает эти запросы, обращаясь к информационной базе каталога (directory information base, DIB), или же перенаправляет их к другой службе каталога (referrals), а затем возвращает результаты авторам запросов. Компоненты службы каталога, совместимой с LDAP, практически полностью соответствуют модели X.500 ISO. Записью каталога является информация, собранная об объекте. Вы должны определить объекты как члены некоторого класса объектов, который моделирует объекты реального мира – человека или принтера, например. Когда архитектор каталога определяет структуру записи каталога, он (или она) связывает с ней один или несколько классов объектов. Различные классы объектов состоят из различных атрибутов (элементов информации). Например, атрибуты записи о служащем могут включать название работы, адрес электронной почты и номер телефона. Спецификации LDAP требуют, чтобы для различных объектов вы определили свой набор атрибутов. Например, если вы решили, что класс объектов “organizationalPerson" будет определять некоторый выделенный набор членов вашего каталога, вы должны специфицировать значения для таких атрибутов как commonName (cn) и surName (sn) каждой записи. Кроме того, каждая запись должна иметь уникальное значение для атрибута distinguishedName (dn), который однозначно определяет каждую запись этого типа. Спецификации LDAP позволяют вам расширять классы объектов так, как программисты, использующие язык Java, создают новые классы, расширяя существующие классы. Аналогично архитекторы каталогов могут создавать новые классы объектов из существующих классов объектов. Эти новые объекты наследуют основные атрибуты исходного класса, которые позволяют данной реализации службы каталога эффективно моделировать потребности и функции организации. Конфигурирование службы каталога включает отображение структуры организации для всех типов записей. Это называется пространство имен (namespace), или в терминологии X.500 “информационное дерево каталога” (directory-information tree (DIT)). Идея, лежащая в основе структуры именования X.500 (и LDAP), заключалась в том, что позволить всем пространствам имен в мире однажды объединиться или “общаться” без препятствий. Расположение некоторой записи в данном DIT четко отличает ее от других записей на других узлах того же самого дерева или других деревьев. Например, запись о Ларри Эллисоне, АБД в Германии, отлична от записи о Ларри Эллисоне, руководителе (CEO) в США. Информация о том, как данные организованы в каталоге, - это метаданные, такие как классы объектов, атрибуты, правила соответствия (matching rules) и синтаксис – все это включается в схему каталога (IETF, в котором корпорация Oracle является ведущим участником, активно работает над определениями этой схемы , которые позволят службам каталогов различных организаций лучше работать совместно.) Oracle и службы каталогов Oracle Internet Directory, каталог для Интернет, предложенный корпорацией Oracle, совместим с LDAP версии 3 и соединяет технологии баз данных Oracle с гибкостью стандарта LDAP. Oracle Internet Directory тесно интегрирован с программами управления средой Oracle, тем самым становясь предпочитаемым выбором для каталогов систем масштаба предприятия, использующих программное обеспечение Oracle. Oracle Internet Directory использует Oracle8i Database Server для хранения объектов каталога. Эта служба каталогов совместима с LDAP и выполняется как приложение на промежуточном или третьем звене (в рамках трехзвенной архитектуры). Когда вы устанавливаете и конфигурируете Oracle Internet Directory, вы создаете классы объектов для моделирования вашей организации. В случае внедрения приложения электронного бизнеса, которое предоставляет вашим поставщикам доступ к вашим истемам, обслуживающим приобретение и складирование товаров, вы должны создать класс объектов, называемый partnerPerson, который описывает служащих из компаний-партнеров вашей компании. Так как служба каталога может обеспечить централизованный способ ведения полномочий, привилегий и других прав пользователей, вы можете также хранить полномочия безопасности для своих деловых партнеров в этом же каталоге. Применение каталога, что является промышленным стандартом, решает многие проблемы, но одиночный каталог не всегда подойдет организациям, у которых уже есть ряд каталогов с информацией о многочисленных пользователях. Поэтому, помимо работы с LDAP, корпорация Oracle активно развивает дополнительный способ решения проблем служб каталога –метакаталоги. Метакатолог – это централизованный каталог, который обеспечивает межсетевые коммуникации в рамках компании, объединяя информацию о системах управления ресурсами предприятия (ERP-системы), приложениях баз данных, системах передачи сообщений и сетевых операционных системах в едином репозитории. Что впереди? В ноябре 1999 года, корпорация Oracle объявила о соглашении с Siemens Information and Communications Products, подразделением коммпании Siemens (http://www.siemens.de/), по которому будет разработан метакаталог, совместимый со стандартами LDAP и XML, на основе Oracle Internet Directory и технологии метакаталога DirX компании Siemens. Корпорация Oracle, один из лидеров на арене LDAP, особенно в деятельности рабочих групп IETF по репликации и схемам. Корпорация Oracle также работает с другими лидерами отрасли, например, с компанией Novell, в комитете по стандартизации LDAP по расширению спецификаций этого протокола, чтобы обеспечить большую степень взаимодействия служб каталогов предприятий. Действуя в этом направлении, корпорация Oracle (в сотрудничестве с Novell и другими компаниями) создала в октябре 1999 года Directory Interoperability Forum (http://www.directoryforum.org/) – форум по обсуждению проблем взаимодействия каталогов - чтобы обеспечить большую степень взаимодействия служб каталогов предприятий. Службы каталогов относятся к основным службам сетевой инфраструктуры, которые необходимы для электронного бизнеса. В данном введении дан обзор технологий служб каталогов и инициатив, предлагаемых на этом рынке. Две основные рабочие группы IETF – это LDAP Duplication/Replication/ Update Protocols (ldup) (по репликации, корректировке и дублированию информации) и LDAP Extension (ldapext) (по расширению LDAP). В этих группах разработано несколько десятков проектов документов, чтобы соответствовать различным требованиям, предъявляемым службам каталогов для Интернет, включая требования к информации о репликации, схемах и каталогам. Цель всех этих инициатив одна – обеспечить легкий поиск организациям и индивидуальным пользователям друг друга – и хороший ужин с пиццей – через Интернет. Полное введение в тематику LDAP, включая описания случаев его практического применения, смотрите: 
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Письмо в редакцию