DeepEdit!

Теперь вы знаете, какого вида информация хранится в каталоге LDAP и как организовано ее именование. Посмотрим, что можно делать с этой информацией. Фактически вам доступны девять операций трех типов: ■   Операции опроса: search, compare '

Операции обновления: add, delete, modify, modify RDN

Операции аутентификации: bind, unbind, abandon

Операции опроса позволяют проводить поиск в структуре каталога LDAP и извлекать информацию. Операция search используется для поиска информации в определенной области дерева каталога на основе критерия отбора, иначе называемого фильтром поиска. Эта операция возвращает набор атрибутов (со значениями или без) для каждой записи, удовлетворяющей условию фильтрации. Клиент может указать, сколько времени он готов ожидать результатов поиска, а также ограничить размер или количество выводимых записей.

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

Операция modify используется для изменения атрибутов и значений существующей записи, а также для добавления или удаления атрибутов и значений. С помощью операции delete можно удалить существующую запись. Для изменения имени записи используется операция modify RDN. Операции bind и unbind, относящиеся к аутентификации, выполняют

основную работу по защите информации в каталоге. Операция bind позволяет проверить, является ли клиент тем, за кого он себя выдает. Для этого клиент указывает DN и пароль, передаваемый открытым текстом. Интересно отметить, что серверу не нужно подтверждать свою аутентичность перед клиентом. Если аутентификация не требуется, то клиенту достаточно указать NULL вместо DN и пароля. Операция unbind используется для завершения сеанса работы с каталогом. Операция abandon позволяет отменять любую операцию, находящуюся в стадии выполнения. Это очень полезно, если, например, операция поиска слишком затянулась. В LDAP версии 3 реализованы более надежные методы защиты, в том числе двухсторонняя аутентификация, при которой сервер также обязан подтверждать свою аутентичность перед клиентом.

Как можно предположить по наличию операций bind и unbind в функциональной модели, система безопасности основана на идентификации

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

Когда LDAP использовался в качестве клиентской части Х.500, предполагалось, что за обработку всех запросов клиента и возврат окончательных результатов (или сообщений об ошибках) будет отвечать сервер каталога Х.500. Если сервер не мог удовлетворить запрос, он связывался с другими серверами, опрашивая их от имени клиента. Это называлось сцеплением (chaining). Клиент ничего не знал о том, что в получение результатов его запроса вовлекался другой сервер.

Модель сцепления оказалась слишком негибкой, чтобы эффективно работать в Интернете. По этой причине была разработана новая модель, получившая название справочной модели (referral model). Она упрощает развертывание серверов каталогов LDAP в сильно распределенной и неоднородной среде, которой является Интернет. В соответствии с этой моделью, если сервер каталога LDAP не содержит запрашиваемой информации, он может направить клиента к другому серверу LDAP.

Теперь, когда у вас есть некоторое представление об истории и моделях LDAP, посмотрим, как корпорация Oracle реализовала эту технологию в своих базах данных.