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

 

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

LDAP – Lightweight Directory Access Protocol
Введение в LDAP
История LDAP
CCITT (Consultative Committee for International Telegraphy and Telephony) разработал серию рекомендаций для создания так называемого сервиса Директории или Каталога. Каталог является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информации о различных субъектах, таких как пользователи, устройства и т.п. Эта распределенная база данных называется Информационной Базой Каталога (Directory Information Base – DIB). Информация включает имя субъекта, а также различные атрибуты, характеризующие этот субъект. Данные рекомендации носят название стандарта Х.500. Первоначально LDAP начал развиваться как программный продукт переднего плана (front end) для Каталога Х.500.
LDAP предоставляет большинство возможностей Х.500 при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции. LDAP, в отличие от Х.500, использует стек ТСР, а не OSI.
Следует заметить, что базовые операции протокола могут быть отображены на подмножество сервисов Каталога Х.500. Однако не существует отображения один-к-одному между операциями протокола LDAP и операциями протокола DAP (Directory Access Protocol) стандарта Х.500.
Первая реализация LDAP написана в Мичиганском университете. Большинство ранних реализаций LDAP основано на ней.
Что такое LDAP
LDAP (Lightweight Directory Access Protocol) – это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.
Эта информация представляет собой данные, хранящиеся в атрибутах. При этом предполагается, что такие данные чаще читаются, чем модифицируются. LDAP основан на клиент-серверной модели взаимодействия.
Общая модель данного протокола состоит в том, что клиент выполняет операции протокола на серверах. Клиент передает запрос, описывающий операцию, которая должна быть выполнена сервером. Сервер выполняет необходимые операции в Каталоге. После завершения операции (операций) сервер возвращает клиенту ответ, содержащий результаты или ошибки.
Заметим, что хотя требуется, чтобы серверы возвращали ответы всякий раз, когда такие ответы определены в протоколе, не существует требования синхронного поведения клиентов или серверов. Запросы и ответы для нескольких операций могут пересылаться между клиентом и сервером в любом порядке, однако клиенты должны получить ответ на каждый свой запрос.
Информация на сервере LDAP представляет собой совокупность записей, которые содержат набор атрибутов и сгруппированы в древовидную иерархическую структуру.
Запись идентифицируется глобально уникальным именем (Distinguished Name – DN) – подобно имени домена в структуре DNS.
Каталог является специализированной базой данных, которая может использоваться в повседневной жизни – телефонная книга, программа передач и т.п. Предполагается, что данные Каталога достаточно статичны. Классическим примером подобной специализированной базы данных является сервис DNS.
Преимущества LDAP
Основные причины роста популярности LDAP связаны с тем, что:

  • LDAP имеет стандартную схему хранения информации в отличие от реляционных баз данных, когда в каждом случае определяется своя схема хранения в терминах таблиц и столбцов. Поэтому в LDAP нет специфичного для каждого Каталога и для каждого приложения управления – нет так называемой «проблемы N+1 Каталога». Для всех серверов LDAP используется единая схема хранения, единый способ именования хранимых объектов и единый протокол доступа.
  • LDAP позволяет быстро отыскивать необходимые данные, поскольку ориентирован в большей степени на чтение и поиск информации, чем на модификацию.
  • LDAP не обязательно должен быть ограничен конкретным сервером, есть возможность организовывать распределенные системы из нескольких серверов. В LDAP предусмотрена возможность создавать ссылки между различными серверами LDAP, что обеспечивает возможность поиска сразу на нескольких серверах LDAP.
  • Как протокол LDAP, так и структура Каталога LDAP организованы в соответствии со стандартами, в результате чего можно единообразно использовать реализации LDAP различных производителей.
  • Еще одно важное назначение LDAP – хранение всей информации, относящейся к PKI, а именно сертификатов, CRL и т.п.

LDAP vs базы данных
Сравним два наиболее популярных на сегодня способа хранения информации, реляционные базы данных и серверы LDAP, по следующим характеристикам:

  • Соотношение чтение-записьLDAP, в отличие от реляционных баз данных, оптимизирован для чтения.
  • Расширяемостьсхемы LDAP легче изменить в процессе функционирования, чем схемы баз данных.
  • Распределенность – данные LDAP могут располагаться на нескольких серверах, поиск на которых может осуществляться с использованием одной команды. В результате можно создавать конфигурации серверов LDAP, оптимально расположенные в зависимости от того, где требуется та или иная информация, одновременно обеспечивая возможность поиска всей информации, хранящейся на всех серверах LDAP. Тем самым достигается более высокая степень распределенности по сравнению с реляционными базами данных.
  • Репликация – данные LDAP могут храниться на нескольких серверах, при этом существует возможность использования различных способов синхронизации информации.
  • Применение данныхLDAP разработан для возможности использования хранимых данных разными приложениями, базы данных разрабатываются для одного приложения.
  • Сложность взаимосвязей между объектами – объекты баз данных имеют более сложные взаимосвязи, чем записи LDAP.
  • Транзакции – в LDAP транзакции проще, обычно изменяется одна запись, транзакции в базах данных более сложные.
  • Тип хранимой информацииLDAP хранит информацию в атрибутах.
  • Способ именованияLDAP представляет собой иерархию. Имя объекта определяется путем в дереве иерархии, аналогично именованию файлов в обычных файловых системах.
  • Схемысхемы реляционных баз данных полностью определяются разработчиком соответствующей базы данных, LDAP имеет стандартные схемы, включая схему ядра (core), общую для любой Каталога. Этим достигается большая интероперабельность по сравнению с базами данных.
  • Стандарты – использование стандартных схем хранения информации и стандартного протокола доступа является преимуществом LDAP по сравнению с базами данных, так как в этом случае клиенты LDAP могут общаться с любым сервером LDAP, а клиенты баз данных могут взаимодействовать только с базой данных, для которой они разработаны.
  • Возможность отката при неудачных операциях – реляционные базы данных имеют более гибкие возможности отката, следовательно, они больше подходят для модификации информации, чем LDAP. Для динамических объектов возможностей LDAP недостаточно.

Принципы развертывания серверов LDAP
При развертывании серверов LDAP необходимо выполнить следующие задачи:

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

 

Модели LDAP

Основными моделями LDAP, которые определяют характеристики сервиса, являются:

  • Информационная модель – определяет типы данных, хранящихся в Каталоге, их взаимосвязи и способы обращения к ним (именование).
  • Функциональная модель – определяет операции в протоколе LDAP.
  • Модель безопасности – определяет способы и методы защиты хранящейся в Каталоге информации.
  • Распределенное множество серверов LDAP – определяет способы взаимодействия серверов LDAP и возможность поиска информации на нескольких серверах LDAP.
Информационная модель

Рассмотрим информационную модель Каталога LDAP.
Каталог, как определено в стандарте Х.500, есть набор открытых систем, взаимодействующих для предоставления сервисов Каталога. Информация, хранящаяся в Каталоге, называется Информационной Базой Каталога (Directory Information Base – DIB). Пользователь Каталога, который может быть как человеком, так и машиной, получает доступ к Каталогу посредством клиента. Клиент от имени пользователя Каталога взаимодействует с одним или более серверами. Сервер хранит фрагмент DIB.
DIB содержит два типа информации:

  1. Пользовательская информация – информация, предоставляемая пользователям и, быть может, изменяемая ими.
  2. Административная и функциональная информация – информация, используемая для администрирования и/или функционирования Каталога.

Функция Каталога состоит в том, чтобы хранить информацию об объектах и предоставлять к ней доступ. Объектом может быть все, что может быть идентифицировано (поименовано).
Класс объекта есть идентифицированное семейство объектов, которые имеют общие характеристики. Каждый объект принадлежит, по крайней мере, одному классу. Класс объекта может быть подклассом других классов объектов, в этом случае члены первого класса (подкласса) также считаются членами второго класса (суперкласса). Цепочка подклассов может быть произвольной длины.
Запись Каталога – это поименованный набор информации. Она является основной единицей информации, хранящейся в Каталоге. Существует несколько видов записей Каталога.
Запись объекта представляет конкретный объект. Запись alias обеспечивает альтернативное именование того же самого объекта.
Множество записей, представленных в DIT, организовано иерархически в структуру дерева, известную как Информационное Дерево Каталога – Directory Information Tree (DIT).
Сначала мы рассмотрим DIT, затем обсудим именование записей, структуру записей, классы объектов, описания атрибутов и записи alias’ов.

DIB является композицией множества записей, организованных иерархически в структуру дерева, известную как информационное дерево Каталога (Directory Information Tree – DIT). Вершинами дерева являются записи.
Дуги между вершинами определяют отношения между записями. Если существует дуга от Х к Y, то запись Х является родителем Y, и Y непосредственно подчиняется Х. Вышестоящими записями являются записи непосредственного родителя и его родителей. Подчиненными записями являются все записи, непосредственно подчиненные данной, и все их подчиненные.
В данном случае dc=msu и cn=oit – примеры записей. Запись dc=msu является родителем для записи dc=cmc, запись dc=cmc является подчиненной для записи dc=msu.

LDAP определяет иерархическую структуру данных, называемую DIT. Дерево Каталога в чем-то подобно файловой системе. Отличие от файловой системы состоит в следующем:

  1. Каждая запись в LDAP может как содержать данные, так и служить контейнером, т.е. содержать поддерево. В файловой системе каждая запись является либо файлом, либо Каталогом, но не тем и другим одновременно.
  2. Уникальные имена LDAP читаются от данной точки к корневой точке, в файловой системе наоборот, от корневой точки к данной.

Каждая запись поименована относительно своей непосредственной вышестоящей записи. Данное относительное имя, известное как ее Relative Distinguished Name (RDN) является композицией неупорядоченного множества одного или более выражений значений атрибутов – attribute value assertions (AVA) – состоящих из описания атрибута и его значения. Эти AVAs выбраны из атрибутов записи.
RDN записи должно быть уникальным среди всех непосредственных подчиненных вышестоящей записи.
Приведем примеры RDNs:

UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores

Последний вариант является примером RDN с несколькими значениями. Это означает, что RDN составлено из нескольких AVAs.
Принципы именования следующие:

  • Все записи должны иметь имена.
  • Имена не должны допускать конфликтов, т.е. все потомки некоторого родителя должны иметь уникальные имена (желательно, чтобы имена были информативными, хотя, естественно, понятие информативности является неформальным, и стандартом не определяется).
Полные уникальные имена

Полное имя записи, известное как Distinguished Name (DN), является конкатенацией ее RDN и DN ее родителя. DN уникально определяет запись в дереве.
Приведем примеры DNs:

UID=nobody@example.com,
    DC=example,DC=com
cn=oit,ou=laboratories,
    dc=cmc,dc=msu,c=ru

В LDAPv3 для представления уникального имени (DN) используется строка UTF-8.
Построение начинается с последнего элемента путем присоединения с помощью запятой каждого следующего уровня.
Уникальные имена имеют две части.

  • Левая часть называется относительным уникальным именем (RDN).
  • Оставшаяся часть является базовым уникальным именем.

В приведенном выше примере RDN есть cn=oit.
Базовое уникальное имя есть ou=laboratories,dc=cmc,c=msu.
Для каждого базового DN каждый RDN является уникальным. Это гарантирует, что никакие две записи не имеют один и тот же DN.

Запись LDAP

Основные свойства записи:

  • Записи составлены из атрибутов.
  • Атрибут состоит из типа и одного или более значений.
  • Значение является содержательной информацией в текстовом формате.
  • Атрибуты имеют синтаксис, который определяется типом данной записи.

Запись состоит из множества атрибутов, хранящих информацию об объекте. Некоторые атрибуты хранят пользовательскую информацию и называются пользовательскими атрибутами. Другие атрибуты хранят функциональную и/или административную информацию и называются функциональными атрибутами.
Атрибут состоит из описания атрибута (тип атрибута и ноль или более опций) и одного или более связанных с ним значений. На атрибут часто ссылаются с помощью его описания. Например, атрибут givenName является атрибутом, состоящим из описания атрибута givenName (тип атрибута givenName и ноль опций) и одного или более связанных с ним значений.
Тип атрибута определяет, может ли атрибут иметь несколько значений, синтаксис и правила соответствия, используемые при создании и сравнении значений данного атрибута, и другие функции. Никакие два значения атрибута в одной записи не могут быть эквивалентны.
Два значения считаются эквивалентными, если эквивалентность выполняется в соответствии с правилами эквивалентности данного типа атрибута. Если тип атрибута определяется без правила эквивалентности, два значения являются эквивалентными тогда и только тогда, когда они идентичны.
Например, атрибут givenName может иметь более одного значения, эти значения должны быть Directory Strings и они нечувствительны к регистру. Поэтому атрибут givenName не может иметь одновременно значения John и JOHN, так как согласно правилу эквивалентности данного типа атрибута это эквивалентные значения.

Атрибуты

Атрибут состоит из описания атрибута и одного или более значений данного атрибута.

Attribute ::=  SEQUENCE { 
  type AttributeDescription, 
  vals SET OF AttributeValue 
} 

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

Описания атрибута

Описание атрибута состоит из типа атрибута и множества из нуля или более опций атрибута.

attributedescription =
    attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar

где <attributetype> определяет тип атрибута, и каждая <option> определяет опцию атрибута. И <attributetype>, и <option> нечувствительны к регистру. Порядок, в котором появляются <option>s, несущественен. Это означает, что любые два <attributedescription>s, которые состоят из одного и того же <attributetype> и одного и того же множества <option>s, являются эквивалентными.
Примеры допустимых описаний атрибутов:

2.5.4.0
cn;lang-de;lang-en
owner

Все атрибуты записи должны иметь различные описания атрибутов.

Типы атрибутов

Тип атрибута определяет, может ли атрибут иметь несколько значений, как используются правила синтаксиса и соответствия при создании и сравнении значений данного атрибута, а также некоторые другие параметры.
Тип атрибута указывает, является атрибут пользовательским или функциональным. Если атрибут является функциональным, тип атрибута определяет его функциональное использование и указывает, может ли данный атрибут модифицироваться пользователем.
Тип атрибута (подтип) может быть получен из другого типа атрибута (прямого супертипа). Подтип наследует правила соответствия и синтаксис. Тип атрибута не может быть подтипом атрибута для другого применения, т.е. атрибут пользовательского подтипа не может быть атрибутом функционального супертипа.
Каждый тип атрибута определяется идентификатором объекта (OID) и (необязательно) одним или более короткими именами (дескрипторами).

Опции атрибутов

Спецификация LDAP определяет один вид опций атрибутов: тегированные опции. Атрибуты, хранящиеся в Каталоге, могут иметь описания атрибутов с любым числом тегированных опций.
Описание атрибута с N тегированными опциями считается непосредственным подтипом всех описаний атрибута того же самого типа атрибута. Если тип атрибута имеет супертип, то описание атрибута также считается непосредственным подтипом (описания) атрибута супертипа и N тегированных опций. Это означает, что cn; lang-de; lang-en считается непосредственным подтипом cn; lang-de и cn; lang-en и name; lang-de; lang-en (cn является подтипом name).

Значение атрибута

Значения атрибута соответствуют синтаксису, определенному для атрибута.
Когда атрибут используется для именования записи, одно и только одно значение выбранного атрибута присутствует в RDN. Это значение определяется как уникальное.
Поле типа AttributeValue является OCTET STRING, содержащей тип данных значения атрибута. Значение представлено в соответствии с определением представления для LDAP. Определение представления для LDAP для различных синтаксисов и атрибутов определяется при определении Синтаксиса.

AttributeValue ::= OCTET STRING 

Заметим, что ограничение на размер данного представления не определено; таким образом, значения могут включать мегабайтные атрибуты (например, фотографии).
Атрибуты могут быть определены как имеющие произвольный и непечатный синтаксис. Реализации не должны показывать или пытаться представить как ASN.1 значение, если его синтаксис неизвестен. Реализация может попытаться восстановить подсхему исходного участника или восстановить из него значения attributeTypes.
Таким образом, атрибуты имеют:

  1. Имя – уникальный идентификатор, нечувcтвительный к регистру.
  2. Идентификатор объекта (OID) – последовательность целых, разделенных точками.
  • Синтаксис атрибута, который определяет:
    • тип данных, хранящихся в атрибуте: целые, строки и т.п;
    • как выполняется сравнение.
  1. Может ли атрибут иметь несколько значений или только единственное значение.

Примеры имен атрибутов:
uid – User id
cn – Common Name
sn – Surname
l – Location
ou – Организационная единица
o – Организация
dc – Domain Component
st – Штат
c – Страна

Атрибуты функционирования

Атрибуты функционирования имеют следующие характеристики:

  1. Атрибуты используются сервером и пользователю обычно недоступны.
  2. Множество атрибутов функционирования зависит от разработчиков Каталога.
  3. Обычно это отметки времени, управление доступом сервера, административная информация, дата последнего изменения и т.д.
Aliases

Записи аliases имеют следующие свойства:

  1. Используются для ссылки одной записи на другую.
  2. Позволяют иметь структуру, которая не является иерархической.
  3. Аналогичны использованию символьных ссылок в файловой системе UNIX.
  4. Не все серверы LDAP поддерживают aliases.
  5. Создаются с помощью:
    • записи с классом объекта alias'а;
    • атрибут, называемый aliasedObjectName, который указывает на DN alias'а.
    Схема

    Схема Каталога обладает следующими свойствами:

    1. Представляет собой множество правил, которые описывают хранимые данные.
    2. Предназначена для поддержки согласованности и качества данных.
    3. Снижает дублирование данных.
    4. Гарантирует, что приложения имеют согласованный интерфейс к данным.
    5. Атрибут класса объекта определяет правила схемы, которым должна удовлетворять запись.
    6. Схема содержит следующую информацию:
      • необходимые атрибуты;
      • допустимые атрибуты;
      • как сравнивать атрибуты;
      • предел хранимых атрибутов, например ограничение на целые и т.п;
      • ограничение на хранение информации, например запрет дубликатов и т.п.

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

    1. Предотвращение создания подчиненных записей от неправильного класса объекта (например, country как подчиненная person).
    2. Предотвращение добавления типов атрибута к записи, не соответствующей классу объекта (например, serial number к записи person).
    3. Предотвращение добавления значения атрибута, синтаксис которого не соответствует тому, который определен для типа атрибута (например, printable string к bit string).

    Формально Схема Каталога состоит из множества:

    1. Определений форм имени, которые характеризуют взаимоотношения именования для структурных классов объектов.
    2. Определений Правил Структуры DIT, описывающих имена, которые могут иметь записи, и способы взаимоотношений записей в DIT.
    3. Определений Правил Содержания DIT, которые расширяют спецификацию возможных принадлежащих записям атрибутов указанием структурных классов объектов для записей.
    4. Определений Классов Объектов, описывающих базовое множество обязательных и необязательных атрибутов, которые должны и могут присутствовать в записи данного класса, и которые указывают род определяемого класса объекта.
    5. Определений Типов Атрибутов, указывающих идентификатор объекта для атрибута, его синтаксис, связанные с ним правила соответствия, является он функциональным или пользовательским атрибутом, может ли он иметь несколько значений и происходит ли от другого атрибута.
    6. Определений Правил Соответствия.
    7. Определений синтаксиса LDAP, которые определяют правила представления, используемые в LDAP.
    Расширение схемы

    Расширение схем выполняется в определенной последовательности:

    1. Получить идентификатор объекта (OID).
    2. Выбрать префикс имени.
    3. Создать файл локальной схемы.
    4. Определить типы атрибутов пользователя (если необходимо).
    5. Определить классы объектов пользователя.
    Класс объекта

    Класс объекта есть идентифицированное семейство объектов, которые имеют общие характеристики.
    Основные свойства классов объектов:

    1. Классы используются для группирования информации.
    2. Классы обеспечивают следующие возможности:
      • определяют необходимые атрибуты;
      • определяют допустимые атрибуты;
      • обеспечивают легкий способ группирования информации.
    3. Записи могут иметь несколько классов объектов. Необходимые и допустимые атрибуты при этом являются объединением атрибутов каждого класса.
    4. Классы также предназначены для управления функционированием Каталога.

    Класс объекта (подкласс) может быть получен из другого класса объекта (суперкласса), который в свою очередь может быть получен из более общего класса объекта. Для структурных классов объектов данный процесс завершается на самом общем классе объекта, называемом top. Упорядоченное множество суперклассов от наиболее общего класса объекта до данного класса объекта называется цепочкой суперклассов.
    Каждый класс объекта определяет множество атрибутов, которые должны присутствовать в записях, принадлежащих классу, и множество атрибутов, которые могут присутствовать в этих записях. Класс, как и запись, должен удовлетворять требованиям каждого суперкласса, которому он принадлежит. Это говорит о том, что класс объекта наследует множества допустимых и необходимых атрибутов от своих суперклассов.
    Каждый класс объекта определяется как один из трех видов классов объектов: Abstract, Structural или Auxiliary.
    Каждый класс объекта идентифицируется своим идентификатором объекта (OID) и (необязательно) одним или более короткими именами (дескрипторами).

    Абстрактные классы объектов

    Абстрактный (Abstract) класс объекта, как следует из его названия, предоставляет основу для характеристик, с помощью которой другие классы объектов могут быть определены как наследуемые. Запись не может принадлежать абстрактному классу объекта, если она не принадлежит структурному или вспомогательному классу, который наследуется от данного абстрактного класса.
    Абстрактные классы объектов не могут происходить от структурных или вспомогательных классов объектов.
    Все структурные классы объектов получены (прямо или косвенно) от top абстрактного класса объекта. Вспомогательные классы объектов необязательно получены от top.

    Структурные классы объектов

    Каждый структурный класс (Structural) объекта является (прямым или косвенным) подклассом top абстрактного класса объекта.
    Структурные классы объектов не могут быть подклассом вспомогательных классов объектов.
    Говорится, что каждая запись принадлежит своему структурному классу объекта, а также всем классам в ее цепочке структурных классов объектов, которая всегда включает top.

    Вспомогательные классы объектов

    Вспомогательные классы (Auxiliary) объектов используются как дополнение характеристик записей. Обычно они применяются для расширения множества необходимых и допустимых атрибутов записи, а также могут использоваться для описания записей или классов записей.
    Вспомогательные классы объектов не могут быть подклассом структурных классов объектов.
    Запись может принадлежать любому подмножеству множества вспомогательных классов объектов.
    Множество вспомогательных классов объектов, которым принадлежит запись, может со временем изменяться.

    Наследование классов объектов

    Наследование классов объектов обладает следующими свойствами:

    • Классы объектов могут быть получены из других классов объектов.
    • В случае наследования происходит расширение атрибутов из других классов объектов.
    • Для структурных и абстрактных классов множественного наследования нет.
    • Для классов объектов нельзя перекрывать правила.
    • Существует специальный класс, называемый top – все структурные и абстрактные классы являются его расширением. Для данного класса необходимым атрибутом является только objectClass. Это гарантирует, что все записи имеют атрибут objectClass.
    Административная и функциональная информация Каталога

    Рассмотрим некоторые аспекты Административной и Функциональной Информационной модели LDAP. Некоторые реализации LDAP могут поддерживать и другие аспекты данной модели.

    Атрибут objectClass

    Каждая запись имеет атрибут objectClass. Атрибут objectClass определяет классы объекта записи, которые (наравне с другой информацией) используются вместе со схемой пользователя и системы для определения разрешенных атрибутов записи. Значения данного атрибута могут модифицироваться клиентами, но атрибут objectClass не может быть удален.

    Функциональные атрибуты

    Некоторые атрибуты, называемые функциональными, используются или поддерживаются серверами для административных и функциональных целей.
    К функциональным относятся атрибуты, поддерживаемые сервером (например, createTimeStamp), а также функциональные атрибуты, которые хранят значения, администрируемые пользователем (например, ditContentRules).
    Функциональные атрибуты обычно невидимы. Они не возвращаются в качестве результатов поиска, если явно не запрошены по имени.
    Записи могут содержать, помимо прочего, следующие функциональные атрибуты.

    • creatorsName: DN пользователя, добавившего данную запись в Каталог.
    • createTimestamp: время, когда данная запись была добавлена в Каталог.
    • modifiersName: DN пользователя, который последним модифицировал данную запись.
    • modifiersTimestamp: время, когда данная запись была последний раз изменена.

    Серверы должны поддерживать creatorsName, createTimestamp, modifiersName и modifiersTimestamp для всех записей в DIT.

    Синтаксисы

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

    Правило присваивания значения атрибута

    Определение типа AttrubuteValueAssertion содержит описание атрибута и соответствующее правило присваивания значения для данного типа.

    AttributeValueAssertion ::= SEQUENCE { 
          attributeDesc
            AttributeDescription, 
          assertionValue
            AssertionValue 
    } 
    AssertionValue ::= OCTET STRING 

    Синтаксис AssertionValue зависит от контекста выполняемой операции LDAP. Например, синтаксис EQUALITY, соответствующий правилу для атрибута, используемого при выполнении операции Compare. Часто тот же самый синтаксис используется для значений типов атрибутов, но в некоторых случаях синтаксис присваивания отличается от синтаксиса значения.

    Правила соответствия

    Правила соответствия используются реализациями Каталога для сравнения значений атрибутов со значениями утверждения при выполнении операций Search и Compare. Они также используются для сравнения искомых уникальных имен с именем записи. При модификации записей правила сравнения применяются для идентификации значений, которые должны удаляться, и для предотвращения того, чтобы атрибут содержал два эквивалентных значения.
    Далее будут рассмотрены правила соответствия, необходимые для операции Каталога, или те, которые требуются для общего использования.
    Правило соответствия применяется к значениям атрибута посредством AttributeValueAssertion или MatchingRuleAssertion. Могут существовать определенные условия, при которых AttributeValueAssertion или MatchingRuleAssertion вычисляются как Undefined. Если утверждение не является Undefined, то результат утверждения есть результат применения выбранного правила соответствия. Правило соответствия вычисляется в TRUE и в некоторых случаях Undefined, как определено в описании правила соответствия, в противном случае оно вычисляется в FALSE.
    Каждое утверждение имеет определенное значение. Определение каждого правила соответствия специфицирует синтаксис для значения утверждения. Синтаксис значения утверждения обычно, но не обязательно, бывает тот же, что и синтаксис значений атрибутов, к которым правило соответствия может применяться.
    Определение каждого правила соответствия указывает синтаксисы атрибутов, к которым правило применяется, и условия, которым должны удовлетворять соответствующие типы атрибута.
    Описание каждого правила соответствия указывает, применимо ли правило в качестве правила эквивалентности (EQUALITY), правила упорядоченности (ORDERING) или правила подстрок (SUBSTR) в определении типа атрибута.
    Каждое правило соответствия уникально определяется идентификатором объекта. Определение правила соответствия в дальнейшем не должно изменяться. Если изменение все же необходимо, то определяется новое правило соответствия с другим идентификатором объекта.
    Серверы, которые реализуют extensibleMatch-фильтр, должны допускать использование перечисленных здесь правил соответствия в extensibleMatch-фильтре и применение правил соответствия со всеми известными серверу типами атрибутов, в которых синтаксис утверждения для правила соответствия является тем же самым, что и синтаксис значения атрибута.
    Серверы должны публиковать в атрибуте matchingRules определения правил соответствия, ссылаясь на значения атрибутов attributeTypes и matchingRuleUse в той же записи подсхемы. Могут быть опубликованы и другие правила соответствия в атрибуте matchingRules.
    Если сервер поддерживает extensibleMatch-фильтр, сервер может использовать атрибут matchingRuleUse для указания применимости (в extensibleMatch фильтре) выбранных правил соответствия к упомянутым типам атрибутов.

    Правила содержимого DIT

    Правило содержимого DIT есть правило управления содержимым записей конкретного структурного класса объекта.
    Для записей DIT конкретного структурного класса объекта правило содержимого DIT определяет, какие вспомогательные классы объектов для записей допустимы и какие дополнительные атрибуты (по типу) требуются, допустимы или недопустимы в записях.
    Список недопустимых атрибутов не может включать ни одного атрибута, указанного как обязательный в правиле, для структурного класса объекта или любого из допустимых вспомогательных классов объектов.
    Каждое правило содержимого идентифицируется OID, а также любыми короткими именами (дескрипторами) структурного класса объекта, к которому оно применено.
    Запись может принадлежать только вспомогательным классам объектов, перечисленным в правиле управления содержимым.
    Запись должна содержать все атрибуты, необходимые классам объектов, которым принадлежит запись, а также все атрибуты, которых требует правило управления содержимым.
    Запись может содержать любые незапрещенные атрибуты, допустимые классами объектов, которым принадлежит запись, а также все атрибуты, допустимые правилом управления содержимым.
    Запись не может включать никакие атрибуты, запрещенные правилом управления содержимым.
    Запись управляется (если присутствует и активна в подсхеме) правилом содержимого DIT, которое применяется к структурному классу объекта записи. Если неактивное правило присутствует для структурного класса объекта записи, содержимое записи управляется структурным классом объекта (и, возможно, другими аспектами схемы пользователя и системы).

    Правила структуры DIT и формы имени

    Следует определить, где записи объекта могут размещаться в DIT и как они могут именоваться, основываясь на структурном классе объекта.
    Правила структуры DIT есть правила управления структурой DIT посредством указания возможного старшинства отношений записи. Правило структуры устанавливает форму имени и, следовательно, структурный класс объекта, с помощью правил старшинства структур. Эти допустимые записи структурного класса объекта идентифицируются формой имени, существующей в DIT в качестве подчиненной записям, управляемым указанными правилами подчинения структуры.
    Форма имени специфицирует допустимые RDN для записей конкретного структурного класса объекта. Форма имени идентифицирует именованный класс объекта и один или более типов атрибута, используемых для именования. Формы имени являются элементарными частями спецификации, используемой в определении правил структуры DIT.
    Каждая форма имени определяет способ именования структурного класса объекта, множество необходимых типов атрибутов и множество допустимых типов атрибутов. Конкретный тип атрибута не может быть указан в обоих множествах одновременно.
    Записи, управляемые формой, должны быть именованы с использованием значения из каждого требуемого типа атрибута и нуля или более значений из допустимых типов атрибутов.
    Каждая форма имени идентифицируется OID и (необязательно) одним или более короткими именами (дескрипторами).

    Записи подсхемы

    Записи подсхемы используются для администрирования информации о схеме Каталога. Единственная запись подсхемы содержит все определения схемы, используемые записями в конкретной части дерева Каталога.
    Серверы должны предоставлять атрибуты createTimestamp и modifyTimestamp в записях подсхемы, чтобы разрешить клиентам поддерживать кэши информации схемы.
    Далее перечислены описания типов атрибутов для каждого типа атрибута определения схемы.

    • objectClasses – атрибут содержит определения классов объекта.
    • attributeTypes – атрибут содержит определения типов атрибутов.
    • matchingRules – атрибут содержит определения правил соответствия.
    • matchingRuleUse – атрибут содержит определения используемых правил соответствия.
    • ldapSyntaxes – атрибут содержит определения синтаксисов LDAP.
    • dITContentRules – атрибут перечисляет применяемые правила содержимого DIT.
    • dItStructureRules – атрибут перечисляет применяемые правила структуры DIT.
    • nameForms – атрибут перечисляет используемые формы имени.
    Класс объекта «extensibleObject»

    Вспомогательный класс объекта extensibleObject позволяет записям иметь любой тип атрибута. Множество допустимых атрибутов данного класса неявно является множеством всех пользовательских атрибутов.
    Обязательные атрибуты других классов объектов данной записи также должны присутствовать, а запрещенные атрибуты присутствовать не должны.
    Заметим, что не все серверы реализуют данный класс объекта, но и не все отвергают запросы на добавление записей, которые содержат данный класс объекта, или на модификацию записи по добавлению данного класса объекта.

    LDIF

    LDIF является форматом обмена данными и обладает следующими свойствами:

    • Представляет записи LDAP в виде текста.
    • Имеет читаемый формат.
    • Обеспечивает возможность легкой модификации данных.
    • Используется для изменений большого количества данных по следующему принципу: – сделать дамп БД, выполнить скрипт, импортировать обратно.
    • обеспечивает возможность архивации данных и передачи данных в другие системы.

    Пример LDIF:

    dn: uid=olga, ou=people,
    dc=cmc, dc=msu
    uid: olga
    Распределенное множество серверов 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.
    Заметим, что символы 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, управляет также и любой записью, хранящейся на сервере.

    Репликация

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

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

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

     

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика