Инфраструктура Открытого Ключа (часть 2)

Распределенное множество серверов LDAP

Протокол LDAP предполагает, что существует один или несколько серверов, которые сообща предоставляют доступ к Информационному Дереву Каталога (DIT).

Разработка топологии

Дерево Каталога может быть распределено по нескольким физическим серверам.

При определении топологии важно учитывать:

• Возрастание выполнения.
• Возрастание доступности.
• Лучшее управление Каталогом.
• Возможность хранения большего числа записей, чем на одном сервере.

При использовании подобной топологии пользователи видят один большой Каталог, а каждому серверу делегируется некоторая его часть.

Данная структура во многом аналогична DNS.

Referrals

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

• Клиент запрашивает информацию.
• Сервер 1 возвращает referral на сервер 2.
• Клиент повторно посылает запрос на сервер 2.
• Сервер 2 возвращает информацию клиенту.

Код результата поиска referral указывает, что сервер, с которым осуществляется соединение, не содержит целевой записи для запроса. Поле referral представлено в LDAPResult, если значение поля LDAPResult.resultCode есть referral, и отсутствует с остальными кодами результата. Оно содержит одну или более ссылок на один или более серверов или сервисов, которые могут быть доступны посредством LDAP или других протоколов. Referrals могут быть возвращены в ответе для любого запроса операции (исключая unbind и abandon, которые не имеют ответа). По крайней мере, один URL должен быть представлен в Referral.

В операции поиска после размещения baseObject и вычисления записи referral не возвращается. Вместо этого возвращаются коммуникационные ссылки, когда область поиска охватывает несколько именованных контекстов, и несколько различных серверов должны контактировать для выполнения операции.

Referral ::= SEQUENCE OF LDAPURL
    -- один или более
LDAPURL ::= LDAPString
/* ограничено символами, 
   которые допустимы в URLs */

Если клиент продолжает выполнение операции, он должен следовать по referral для соединения с серверами. Если присутствует несколько URLs, клиент предполагает, что для дальнейшего выполнения операции может использоваться любой URL.

URLs для серверов, реализующих протокол LDAP, написаны в соответствии с определением DN. Если на alias ссылок нет, то часть <dn> URL должна присутствовать с новым именем целевого объекта. Если часть <dn> присутствует, клиент должен использовать данное имя в своих следующих запросах для продолжения операции, и если оно не представлено, клиент будет задействовать то же самое имя, что и в начальном запросе. Некоторые серверы (например, участвующие в распределенном индексировании) могут предоставить различные фильтры в referral для операции поиска. Если часть фильтра в URL присутствует в LDAPURL, клиент должен использовать этот фильтр в своем следующем запросе при продолжении поиска, и если он не присутствует, клиент должен применять тот же фильтр, что использовал для данного запроса. Другие аспекты нового запроса могут быть теми же самыми или отличаться от запроса, в котором был создан referral.

Рис. 14.2. Каждый сервер должен содержать определенное поддерево

Рис. 14.3. Поиск с использованием Referrals

Заметим, что символы UTF-8, появляющиеся в DN или фильтре поиска, могут быть не разрешены для URLs (например, пробелы) и должны быть вырезаны с использованием метода, определенного для преобразования URLs.

Контекст корневого именования и данные сервера

Контекст корневого именования является записью верхнего уровня для серверов. Некоторые серверы могут иметь несколько контекстов корневого именования.

Сервер LDAP должен предоставлять информацию о самом себе, а также информацию, специфичную для каждого сервера. Это представлено как группа атрибутов, размещенная в корневом DSE (DSA-специфичная запись ), которая поименована LDAPDN нулевой длины. Эти атрибуты восстанавливаемы, являются предметом управления доступа и различных ограничений, если клиент выполнил поиск базового объекта для корня с фильтром ( objectClass=* ), запрашивая возвращаемые атрибуты. Следует заметить, что корневые атрибуты DSE являются функциональными, и, подобно другим функциональным атрибутам, не возвращаются для запросов поиска, пока не будут запрошены по имени.

Корневой DSE не должен включаться, если клиент выполнил поиск по поддереву, начиная с корня.

Серверы могут позволять клиентам модифицировать соответствующие атрибуты корневого DSE.

Определены следующие атрибуты корневого DSE.

• altServer: атрибут перечисляет URLs, указывающие на альтернативные серверы, с которыми можно соединяться, когда данный сервер недоступен. Если сервер не знает никаких других серверов, которые можно использовать, данный атрибут должен отсутствовать. Клиенты могут кэшировать данную информацию в случае, если их сервер в дальнейшем может оказаться недоступным.
• namingContexts: атрибут перечисляет префиксы контекста сервера. Если сервер является сервером первого уровня, он должен указать пустую строку (корень DIT ). Данный атрибут позволяет клиенту выбрать соответствующие базовые объекты для поиска, когда он соединяется с сервером.
• supportedControl: атрибут перечисляет идентификаторы объектов, определяющие способы управления запросом, поддерживаемые сервером. Если сервер не поддерживает никаких управлений запросом, данный атрибут отсутствует.
• supportedExtension: атрибут перечисляет идентификаторы объектов, определяющих расширенные операции, поддерживаемые сервером. Если сервер не поддерживает никаких расширенных операций, данный атрибут отсутствует. Расширенная операция включает в себя ExtendedRequest, возможно, и другие блоки данных, определенные расширением, и ExtendedResponse.
• supportedLDAPVersion: атрибут перечисляет версии LDAP, которые поддерживает сервер.
• supportedSASLMechanisms: атрибут перечисляет механизмы SASL, которые распознает сервер. Содержимое данного атрибута может зависеть от текущего состояния сессии. Если сервер не поддерживает никаких механизмов SASL, то данный атрибут не должен присутствовать.

Значения этих атрибутов могут зависеть от конкретной сессии и от других факторов. Например, сервер, поддерживающий механизм SASL EXTERNAL, когда идентификация клиента установлена на нижнем уровне, должен перечислить только EXTERNAL.

Корневой DSE может также включать атрибут subschemaSubentry. Если это так, то он указывает на запись подсхемы, управляющую атрибутами корневого DSE. Клиент не должен предполагать, что запись подсхемы, управляющая корневым DSE, управляет также и любой записью, хранящейся на сервере.

Репликация

Репликация является методом, обеспечивающим хранение копии данных Каталога на нескольких серверах.

При использовании репликации происходит увеличение:

• Надежности – если с одной копией что-то случилось.
• Доступности – легче найти доступный сервер.
• Выполнения – можно использовать ближайший сервер.
• Скорости – можно сделать больше запросов в качестве добавленных репликаций.

При использовании репликации может появиться временная несогласованность, но при этом уничтожается единственная точка сбоя.