DeepEdit!

Операции LDAP, хранение информации в каталоге и методы работы с ним полностью описываются четырьмя базовыми моделями. К ним относятся:

•        Информационная модель. Определяет возможные типы хранимых данных.

Модель именования. Определяет, как могут быть организованы данные в каталоге LDAP и как на них ссылаться.

Функциональная модель. Описывает, что можно делать с данными, как к ним обращаться и как их обновлять.

•        Модель безопасности. Определяет методы защиты данных в каталоге LDAP от несанкционированного доступа.

Рассмотрим каждую из этих моделей, чтобы лучше понять устройство и работу сервера каталога LDAP. Информационная модель Как можно описать человека? Обычно говорят о том, мужчина это или женщина, высокий он или низкий, толстый или худой, какой у него цвет глаз и волос.

Если вы захотите использовать каталог для хранения описаний своих друзей, то каждое такое описание будет представлено одной строкой (row), называемой также записью (entry). Записи состоят из атрибутов (attributes), таких, как рост, вес, цвет волос, цвет глаз и пол. С каждым атрибутом связываются определенные правила. Наборы этих правил называются типами. Например, атрибут для цвета глаз может иметь тип символьной строки и называться eyeColor. С каждым типом связываются значения. Атрибут eyeColor, имеющий тип символьной строки, может принимать значения голубой, серый, черный, карий, фиалковый и т.д. Собственно говоря, это и есть информационная модель, определяющая структуру записи сервера каталога LDAP. Рассмотрим эту модель подробнее.

Информационная модель LDAP определяет, какие виды информации

могут храниться на сервере каталога. Центральным понятием этой модели является понятие записи. Как правило, записи связаны с объектами реального мира — людьми, организациями, принтерами, адресами и т.д., однако наличие такой связи не является обязательным требованием. Вы уже знаете, что записи состоят из атрибутов, содержащих информацию об объекте, и что каждый атрибут имеет тип, определяющий множество допустимых значений. На рис. 5.1 показана общая структура записи LDAP. Для большей наглядности рядом показано, как будет выглядеть запись в случае конкретного атрибута eyeColor.

Остановимся на типе атрибута. Синтаксис типа определяет, какую информацию допускается хранить в области значений и как будут трактоваться значения при выполнении поиска или других операций над каталогом. Возьмем для примера атрибут commonName (общее имя), обозначаемый как "сп". Он имеет синтаксис caselgnoreString. Это говорит о том, что значения должны быть символьными строками, причем регистр символов при сравнениях игнорируется, то есть строки "JONES", "Jones" и ']ones" считаются одинаковыми. Атрибут todayDate имеет идентичный синтаксис, но здесь игнорируются дефисы или пробелы в датах, в результате чего даты 10-02-2000 и 10022000 будут рассматриваться как одинаковые.

Атрибуты могут иметь ограничения на размер, состав, количество аргументов и т.д. Например, атрибут для хранения номера кредитной карты может допускать ввод только одного значения, а атрибут, содержащий текст документа, может иметь ограничение на максимальное количество
символов, чтобы ограничить пространство, занимаемое документами. Для определения обязательных или допустимых атрибутов в масштабах сервера используются смысловые правила (content rules). Вместо использования смысловых правил можно указывать в каждой записи

специальный атрибут с именем objectClass, который определяет тип записи и тем самым задает обязательные и необязательные атрибуты. Например, для записи PERSON атрибут objectClass может требовать

наличия атрибутов sn (surname - фамилия) и cn (common name), а также других. В базе данных эквивалентом такой структуры служит схема. Чтобы изменить текущую схему для структуры LDAP, к записи добавляются новые объектные классы.

Каждая запись имеет специальный объектный класс, называемый структурным (structural) объектным классом. Он определяет тип записи и не может быть изменен. Остальные объектные классы называются вспомогательными (auxiliary). Их можно добавлять и удалять в соответствии с установленными правилами доступа. Версия 3 стандарта LDAP содержит специальный объектный класс с именем extensibleObject, который замещает любые, текущие правила схемы. Зачем это нужно? Дело в том, что иногда определение нового правила схемы и информирование клиентов и серверов об этом изменении сопряжено с большими затратами ресурсов. В таких случаях гораздо удобнее и дешевле просто замещать правила

схемы, добавляя или удаляя атрибуты по мере необходимости. Усовершенствования в LDAP версии 3

LDAP версии 3 был утвержден IETF в декабре 1997 года как стандарт Интернета. Новый стандарт содержал ряд усовершенствований, благодаря        Oracle смогла реализовать в своем Интернет-каталоге: 

•Поддержку наборов символов любого из языков, существующих в мире.

•Глобальное развертывание информационного дерева каталога (Directory Information Tree) на множественных серверах LDAP с использованием механизма ссылок (он кратко объясняется в разделе "Ссылки LDAP").

•        Поддержку стандартных протоколов SASL (Simple Authentication and Security Layer) и TLS (Transport Layer Security), служащих универсальным расширяемым средством защиты данных в протоколе LDAP; ' MKI  I >' • ■ ■   . ■ ■

•Возможность расширения существующих операций LDAP с помощью так называемых механизмов controls.

•        Публикацию информации, пригодной для использования другими серверами и клиентами LDAP.